|
|
| (5 intermediate revisions by one other user not shown) |
| Line 5: |
Line 5: |
| * Is SELinux enabled by default on Debian? If not, link to appropriate information (<http://wiki.debian.org/SELinux>) | | * Is SELinux enabled by default on Debian? If not, link to appropriate information (<http://wiki.debian.org/SELinux>) |
| * Is <code>system_u:object_r:httpd_sys_content_t</code> required for all SugarCRM files? | | * Is <code>system_u:object_r:httpd_sys_content_t</code> required for all SugarCRM files? |
| | * A section on setroubleshoot. |
| | * SELinux open permission: <http://james-morris.livejournal.com/31714.html> |
| | * Can users control where SELinux logs are written to? |
|
| |
|
| <pre>
| | [[Category:SELinux docs]] |
| (07:46:36 AM) domg472: chcon is not good
| |
| (07:46:51 AM) domg472: if you have access to semanage use semanage
| |
| (07:47:00 AM) domg472: it is persistent
| |
| (07:47:17 AM) domg472: after relabel it will be still there
| |
| (07:47:26 AM) domg472: unlike chcons
| |
| (07:47:37 AM) domg472: chcon is for unprivileged users
| |
| </pre>
| |
| | |
| Wiki feedback from domg472:
| |
| <pre>
| |
| Explain newrole versus sudo to: transition user domain.
| |
| | |
| in f10 selinux-policy-targeted newrole is no longer encouraged to be used for domain transitions.
| |
| in policy mls it is still used (but mls is not common)
| |
| | |
| sudo allows root privileges without actually knowing the root password.
| |
| | |
| su with newrole still requires a user to enter a root password to gain root privileges.
| |
| | |
| not needing a root password anymore is a big advantage!
| |
| | |
| ---
| |
| | |
| from the wiki:
| |
| SELinux and virtualization (relabeling images if images are not in /etc/xen/).
| |
| | |
| this is not a domain specific issue. customized types. the solution should be man virt_selinux
| |
| or man xen_selinux like man httpd_selinux. however there is no man xen_selinux yet etc.
| |
| this may no longer be an issue in fedora 10 , virt is working on a solution to be implemented in f10
| |
| | |
| ---
| |
| | |
| make sure to use proper selinux terminology consequent in an effort to keep it simple.
| |
| | |
| subject object, security context, domain types, file types, port types, security level, categories,
| |
| domain transition, executable file types, domain, application domain, user domain, init daemon,
| |
| classes, attributes, scontext, tcontext, access vector cache, type enforcement, multi level security,
| |
| multi category security.
| |
| | |
| ---
| |
| | |
| from the wiki:
| |
| Mounting:
| |
| | |
| • Do mount points need to be mnt_t?
| |
| | |
| boolean mount_any_file. this is also kind of a customized type issue.
| |
| use semanage boolean -l to list all booleans and their explanation. for example:
| |
| | |
| /usr/sbin/semanage boolean -l | grep mount
| |
| | |
| sh-3.2# /usr/sbin/semanage boolean -l | grep mount
| |
| allow_mount_anyfile -> off Allow the mount command to mount
| |
| any directory or file.
| |
| xguest_mount_media -> off Allow xguest users to mount removable media
| |
| | |
| consideration: you should consider to not mention get,setsebool.
| |
| semanage also provides this functionality. keep it simple
| |
| | |
| ---
| |
| | |
| from the wiki:
| |
| mislabeled files, relabeled but still problems, touch /.autorelabel (Dans journal).
| |
| aplain how touch /.autorelabel && reboot relates to fixfiles relabel
| |
| | |
| ---
| |
| | |
| different policies:
| |
| first there was strict and optional mls (for dod). strict was in fedora2. it was
| |
| introduced too soon. users were too restricted. targeted was introduced to avoid
| |
| restriction on users.unconfined domain is a domain exempted fro m most selinux policy.
| |
| unconfined is a property of targeted policy. targeted policy only targets a select group.
| |
| strict targets everything on a system. targeted plus multi category security (mcs) which
| |
| is a (poor) implementation of confidentiality(its discretionary users can chcat aslong
| |
| as they are member of the cat. mcs in policy mls is part of security level. in policy
| |
| mls, mcs is mandatory.mls is strict plus BLP, plus MCS, plus MLS. strict no longer
| |
| maintained, merged with targeted. (strict plus unconfined domain) if you remove the
| |
| unconfined domain then you use what use to be strict. at the moment there are two
| |
| selinux policy models maintained: policy targeted and policy-mls. mls aims to enforces confidentiality BLP.
| |
| </pre>
| |
| | |
| Suggestions from domg472:
| |
| <pre>
| |
| Basic access control models ( DAC , MAC ) ( not so basic MDAC )
| |
| | |
| explain discretionary
| |
| | |
| explain the dac model attributes: user group permission bits
| |
| | |
| explain why dac acl is not sufficient. example privilege escalation
| |
| | |
| explain the mac model attributes: security context
| |
| | |
| explain mandatory
| |
| | |
| explain that MAC is ACL layer on top of the DAC ACL layer
| |
| | |
| explain Type enforcement
| |
| | |
| explain Role Based AC
| |
| | |
| explain Multi Level Security
| |
| | |
| Explain Multi Category/Compartment Security
| |
| | |
| | |
| | |
| compare a selinux system to a submarine with compartments. if one compartment has a leak,
| |
| the water will be contained to that compartment and will not be able to spread ( escalate) . submarine will not sink
| |
| | |
| | |
| | |
| Security context / SELinux attributes
| |
| | |
| | |
| | |
| explain the security context tuple and how to read it (explain the fields)
| |
| | |
| explain user ( which SELinux user (group) created the object? )
| |
| | |
| explain type is the attribute for type enforcement (TE)
| |
| | |
| explain role is the attribute for role enforcement (RBAC)
| |
| | |
| explain security level is the attribute for security level enforcement (MLS)
| |
| | |
| explain categories/compartments is the attribute for security level enforcement or category/compartment enforcement (MLS or MCS)
| |
| | |
| | |
| | |
| Subjects and objects ( processes and "files" )
| |
| | |
| | |
| | |
| explain that everything in a system is a object
| |
| | |
| explain that even subjects in a system are represented as objects in proc mountpoint
| |
| | |
| explain subjects and objects
| |
| | |
| explain subjects are processes (ps auxZ)
| |
| | |
| explain objects are "files" (ls -alZ)
| |
| | |
| - file objects ( files , lnk files, dirs, fifo files, sock files etc)
| |
| | |
| - port objects
| |
| | |
| - interface objects
| |
| | |
| - node objects
| |
| | |
| - objects available by other programs ACE access control extension: XACE, sepostgesql, SEDBUS, mscd, etc.
| |
| | |
| - explain object is a class defined in kernel :process :file :tcp_socket
| |
| | |
| example of a class: process. example of a class: file
| |
| | |
| explain domain type is the attribute of a process ( user_t is (user) domain type/attribute of "user"
| |
| | |
| explain object type is the attribute of a object or "file". do not mistake files with file objects/file types. a "file" is
| |
| any object
| |
| | |
| explain that a object type can never be a scontext ( source context ) in a avc denail
| |
| | |
| explain that processes (subjects) generally operate on files (objects)
| |
| | |
| explain that processes (subjects) also operate on other processes (subjects) example: process ( sigchld ) if a user
| |
| processes spawns a program process.
| |
| | |
| explain that "files" ( objects ) do not operate. they get operated on by subjects ( processes )
| |
| | |
| explain permissions that define how to operate on subjects and objects ( classes ) are defined in the kernel and are attributes of classes
| |
| | |
| explain classes and their attributes are static defined in kernel:
| |
| | |
| - example of a file object class and its attributes:
| |
| | |
| + file read
| |
| | |
| + dir write
| |
| | |
| + lnk_file getattr
| |
| | |
| - example of a subject class and its attributes:
| |
| | |
| + process sigchld
| |
| | |
| - example of a object available by other programs ACL
| |
| | |
| + dbus send_msg
| |
| | |
| explain that although classes and their attributes are defined in the kernel, that one can assign "types" to
| |
| subjects and objects, and that one can define policy for these types can interact using the object classes
| |
| and their attributes supplied by the kernel.
| |
| | |
| | |
| | |
| example:
| |
| | |
| | |
| | |
| scontext/domain type/subject | tcontext/file type/object | "object" class | "object" permissions/attributes
| |
| | |
| ___________________________________________________________________________________________________________________________
| |
| | |
| user_t | user_home_t | dir | getattr
| |
| | |
| httpd_t | httpd_sys_content_ra_t | file | read
| |
| | |
| user_t | mozilla_t | process | sigchld
| |
| | |
| user_t | self | process | transition
| |
| | |
| mozilla_t | httpd_port_t | tcp_socket | connect
| |
| | |
| unconfined_t | cupsd_t | dbus | send_msg
| |
| | |
| | |
| | |
| | |
| | |
| How to find out if selinux is supported /enabled:
| |
| | |
| supported?: http://domg444.blogspot.com/2007/11/how-to-determine-if-our-system-supports.html
| |
| | |
| enabled?: getenforce /selinux/config sestatus
| |
| | |
| | |
| | |
| explain selinux framework and selinux policy. explain the selinux framework is responsible for enforcing policy.
| |
| | |
| explain the access vector cache.
| |
| | |
| perruse selinux packages ( rpm -ql ) and discuss important locations : /etc/selinux , /selinux
| |
| | |
| | |
| | |
| How to disable SELinux: i refer to dwalsh blog. some highlights selinux=0 , enforcing=0, setenforce 0,
| |
| system-config-selinux, semanage
| |
| | |
| | |
| | |
| system-config-selinux is a GUI for semanage. semanage is THE central managing point for SELinux administration:
| |
| | |
| label file objects ( semanage fcontect -a)
| |
| | |
| label port objects ( semanage port -a) etc
| |
| | |
| explain each optipn of semanage and system-config-selinux: label interfaces, set booleans, add , modify, delete selinux user (groups) and SELinux logins.
| |
| | |
| explain translation ( requires mcstransd )
| |
| | |
| explain what mcstransd does
| |
| | |
| explain what restorecond does
| |
| | |
| explain auditd connection to selinux ( explain ausearch /auctl )
| |
| | |
| | |
| | |
| show some pratical examples for managing users. add a unconfined user , add a confined user ,
| |
| add a staff users, assign mcs categories to user (ranges)
| |
| | |
| create custom selinux user groups
| |
| | |
| create custom selinux logins
| |
| | |
| | |
| | |
| explain booleans
| |
| | |
| explain customizable types
| |
| | |
| mention manual pages for targeted daemons.
| |
| | |
| | |
| | |
| explain audit2allow
| |
| | |
| explain audit2why
| |
| | |
| explain sesearch and how you can use this to make decisions
| |
| | |
| explain semodule, sestatus , restorecon , semanage, setenforce , getenforce
| |
| | |
| explain limitations of chcon
| |
| | |
| explain advantage of chcon
| |
| | |
| explain chcat
| |
| | |
| | |
| | |
| explain selinux-policy-devel ( /usr/share/selinux/devel/Makefile )
| |
| | |
| show example how to make a custom policy module
| |
| | |
| explain the limitations of a policy module package
| |
| | |
| explain the advantages of a policy module package
| |
| | |
| | |
| | |
| explain role base access control and derrived types.
| |
| | |
| | |
| | |
| explain star and selinux tar support (exmaples)
| |
| | |
| | |
| | |
| important: Possible problems caused from running in permissive mode, such as having permissions to mislabel files.
| |
| | |
| important: Copying Vs moving files.
| |
| | |
| | |
| | |
| explain avc denials field by field.
| |
| | |
| explain advantage and limitation of sealert/setroublehoot and how this relates to audit.
| |
| | |
| | |
| | |
| explain file_t, unlabeled_t
| |
| | |
| explain initrc_t
| |
| | |
| explain unconfined_t
| |
| | |
| explain sepolgen and gui
| |
| | |
| | |
| | |
| explain why /tmp will not be relabled: http://domg444.blogspot.com/2007/11/why-files-with-incompatible-types-in.html
| |
| | |
| | |
| | |
| read selinux by example book
| |
| | |
| | |
| | |
| explain the MLS vs TARGETED
| |
| | |
| explain mcs role in targetted versus mcs role in mls
| |
| </pre>
| |
| | |
| dependencies and selinux-policy by domg472:
| |
| <pre>
| |
| SELinux policy and dependencies.
| |
| | |
| A policy module has 3 files. Here is the explaination of the 3 files.
| |
| | |
| mydomain.te (.te) (type enforcement file) it has PRIVATE policy for the "mydomain" policy module.
| |
| | |
| mydomain.if (.if) (interface file) it has PUBLIC policy for the "mydomain" policy module.
| |
| | |
| mydomain.fc (.fc) (file context file) it has file contexts for the "mydomain" policy module.
| |
| | |
| The type enforcement file.
| |
| | |
| This file has private policy. Policy that is, in my example, related to "mydomain"
| |
| | |
| for example, you might find a rule like this in the mydomain.te file:
| |
| apache_read_user_content(mydomain_t)
| |
| | |
| This policy was provided by apache.if to "mydomain". You can look it up in the apache.if file.
| |
| It is really a template or interface with rules for how to read apaches user content.
| |
| We are using (instantiating) that interface that apache policy module provides in it's
| |
| apache.if file, in our mydomain.te file.
| |
| | |
| Let us refer to interfaces and templates as blocks of public policy. Public policy blocks
| |
| should be prefixed by the policy module name of the domain that facilitates it in it's .if (interface file).
| |
| | |
| for example, just by looking at the following interface call in mydomain.te i know:
| |
| 1. which module provided the interface 2. where to roughly find it. 3. where to find what
| |
| policy te interface provides. 4. which domain instantiates the block of public policy:
| |
| | |
| alsa_read_rw_config(mydomain_t)
| |
| | |
| 1. provided by the alsa policy module.
| |
| 2. can be found in alsa.if
| |
| 3. Summary: Read alsa writable config files
| |
| | |
| allow $1 alsa_etc_rw_t:dir list_dir_perms;
| |
| read_files_pattern($1,alsa_etc_rw_t,alsa_etc_rw_t)
| |
| read_lnk_files_pattern($1,alsa_etc_rw_t,alsa_etc_rw_t)
| |
| | |
| 4. this policy is instantiated by mydomain_t domain.
| |
| | |
| So you can easily from looking at a .te file know the modules dependencies by
| |
| parsing each called interface prefix. as each called interface is prefixed by the domain
| |
| that made it available in its interface file.
| |
| | |
| important note regarding public policy.
| |
| | |
| creating a quick policy module package(.pp) can be very handy for implementing
| |
| quick policy. but it is also limited.
| |
| | |
| to compile policy one need selinux-devel. it has development files for each module that
| |
| is used by the compiler to see if the policy that we want to compile is valid.
| |
| | |
| when you compile and install a seperate policy package with semodule -i mydomain.pp for example.
| |
| there will not be a devel package installed.
| |
| | |
| interfaces files are therefore rendered useless for seperate policy module packages. for the
| |
| reason that other modules will not be able too instantiate any public policy for that module.
| |
| | |
| the reason is that when you try to compile your module that has a call to a public policy block
| |
| of a module that was installed with semodule, the compiler will nnot find that interface/ template
| |
| in its devel files because non were installed!
| |
| | |
| This is important to know!
| |
| do you want to develop and implement much policy, then do not use policy module packages with
| |
| semodule but instead integrate your module into the selinux-policy source provided upstream,
| |
| rebuild it and reinstall it.
| |
| | |
| by rebuilding selinux-policy, a new selinux-policy-devel package is created. this selinux-policy-devel
| |
| package DOES include the public policy for the domain that you integrated and thus is usable as
| |
| opposed to using a .pp with semodule.
| |
| | |
| <http://domg472.blogspot.com/2008/05/how-to-create-integrate-and-rebuild.html>
| |
