Description of an issue that i have.

I usually patch selinux-policy packages. recently i added 3 modules, 2 application domains: xchat, ut2004 and 1 user domain: myuserdomain

Both application domains get called in the user domains local policy.

I have added a boolean to both application domains per-role-template: domain_confine_$1 which will let authority toggle whether the user domain should transition to the application domain or not.

One day i was using an confined xchat instance and in that same session (in another role and as another user) i updated my system and updated to a new upstream selinux-policy. This upstream policy does not include my custom modules.

And so my XChat instance instantly crashed. After upgrading the selinux-policy to my custom version i noticed that my xchat boolean had disapeared! However; my ut2004 boolean was still there.

I have tried uninstalling my modules, reverting to older upstream selinux-policies and reinstalling. The boolean is no longer there...

At the moment i am considering renaming my xchat policy and its declaration.
I would like to hear suggestions and comments

How SELinux detects bugs

Usually we read the stories about how SELinux prevents malicious activity. This article highlights the use of SELinux even if it is not enforcing. Thus not so much preventing malicious activity but detecting malicious activity.

I am using Fedora9. Since it is still in the first stage and very much a construction site, i had to set SELinux to permissive. This was because X "Spawned to fast¨ and so i could not load a graphical desktop session with SELinux enforced.

Some time later i received an update to the audit package, and after updating my firefox browser wouldnt start any more and so i decided to restart the system. after rebooting my computer, i was no longer able to load a graphical desktop session with SELinux in permissive!

/var/log/messages showed a lot of debug entries for GDM. which only told me that GDM wasnt able to load. So i went to runlevel3 since runlevel 5 did no longer work.

When i logged on as a normal user on TTY1, i was confronted with permission denied messages for /dev/null. After inspecting that location i noticed strange permissions set (400) and so i set it to 777 and rebooted.

After reboot i experienced exactly the same thing. Thats when i knew that something during the startup process messed it up.

So knowing it happend in the startup process i turned to dmesg.

And there it was: SELinux was auditing that it would have denied auditd access to set attributes on /dev/null if it was enforcing.

But it was not enforcing! And so it allowed the auditd domain the set 0400 to /dev/null. Fortunatly SELinux will still log would be denials, even in permissive.

If this was the only reason why my graphical desktop wouldnt load , than it should work with SELinux enforced. Since SELinux would not allow audit to mess with (setattr) /dev/null

And so just before i went to sleep i decided to just try and reboot with SELinux enabled..

..It worked! ...and in the mean time the "X server spawns to fast" issue with SELinux enforcing was also solved.

So thats how SELinux not only protects a system from bugs, but it is also a valuable tool for detection!

Exploring SECMARK

Some servers only accept labeled packets. This can be accomplished by setting the selinux allow_unlabeled_packets boolean off. If you want to connect to such a server than you will have to use properly labeled packets or else the packets will be denied. To label traffic on for example port 22:tcp for OpenSSH you should add a rule to the input and output chain in the mangle table of iptables:

/sbin/iptables -t mangle -A OUTPUT -o eth0 -p tcp --sport 22 -j SECMARK --selctx system_u:object_r:ssh_server_packet_t:s0

/sbin/iptables -t mangle -A INPUT -i eth0 -p tcp --dport 22 -j SECMARK --selctx system_u:object_r:ssh_server_packet_t:s0


This will shape the OpenSSH traffic and add the context needed to get packets accepted on the host:

type=AVC msg=audit(1197570945.629:636): avc: granted { send } for pid=1275 comm="sshd" saddr=10.0.0.101 src=22 daddr=10.0.0.100 dest=39769 netif=eth0 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ssh_server_packet_t:s0 tclass=packet

type=AVC msg=audit(1197572881.868:821): avc: granted { recv } for saddr=10.0.0.100 src=35697 daddr=10.0.0.101 dest=22 netif=eth0 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ssh_server_packet_t:s0 tclass=packet

It will not hurt to label your traffic this way for common daemons as correctly labeled traffic will always be accepted.

unlabeled packets will only be accepted if boolean allow_unlabeled_packets is set to on. This is the default setting.

Auditadm Role

The administrator should assume the appropriate role when performing a task. If the administrator wants to define what is being audited than he should assume the auditadm_r and execute auditctl. This will avoid unnecessary errors.

/etc/audit/audit.rules
The audit documentation directory can be found at:
/usr/share/doc/audit-*

MAC user vs. DAC user

In a previous article i mentioned that one shortcoming of traditional Linux security is that the kernel can not make a distinction between a subject that was executed by the system or a process that was started by a user. I also mentioned that the Discretionary access control model only knows two users: root and user.

The Mandatory access control model tackles these issues with the user field in the security context tuple. We can now create as many SELinux user groups as we like. The kernel can now know who or what started a process. Be it a subject initialized by any kind of user, or a system daemon. This attribute is used by the security server to enforce policy defined by the administrator that is based on: who owns the subject or object.

On systems running the traditional targeted policy, system services are assigned to the system_u SELinux user group, and users are assigned to the user_u SELinux user group.

Policy that also makes use of the second role field in the SELinux security context tuple, like Strict, MLS or recent versions of policy Targeted use additional SELinux user groups to further group types of user domains to allow the administrator to apply policy that is targeted to the owner of a process.

The administrator can create additional SELinux user groups, he can assign roles, and levels to these user groups. Tailor made policy for each user group can be defined and enforced.

Process is often referred to as subject, (user or application) domain or source

Why objects with incompatible types in tmp are not restored to a default type for that location

Traditionally the file contexts have explicitely excluded relabelling anything under /tmp. The reason for this is that if some highly classified data is in a file in /tmp it would not be appropriate to relabel it to a default label (of which incidentally there really isn't one for strict or MLS policies and even for targeted there is no single label that works in all situations). So a "fixfiles relabel" operation will offer to remove all files under /tmp

Thanks to rjc for letting me quote you in this article. You can view his blog at: http://etbe.coker.com.au/

Security contexts

SELinux enforces policy that is based on the relation of attributes of a subject to attributes of a object. These attributes are referred to as security contexts. Security contexts are a set of properties that are attached to objects and subjects. These property fields are: user, role, type, security level/security category. The combination of these fields is the security context.

Example of a simple security context:
user_u:role_r:type_t:s0

User Field:
This is the first of the four fields that make a security context. The user field has a SELinux user group. If a user is a member of the user_u user group than this field will be set to user_u. Processes that are started by the system will have a security context starting with the system_u field. Custom SELinux user groups can be created. For example if you want a user domain group to have access to specific roles than you can create a SELinux user group and define which roles this user domain should be able to transition to. On many SELinux systems, the default user_u group is not allowed to transition to any other role. User_u is reserved for unprivileged users.

Role Field:
This is the second of the four fields that make a security context. The SELinux role field has a SELinux role. Roles are only used by user domains and not by application domains. Therefore you will see a generic placeholder if you look at the role field in security contexts for objects. The role field for a user domain process may vary, as defined SELinux user groups are able to assume a new role. The role for a user domain that is member of the user_u SELinux user group may well be user_r. The role for a application domain is system_r. Security decisions based on this field are referred to as RBAC or role based access control.

Type Field.
This is the third of the four fields that make a security context. The SELinux type field has a SELinux type or domain. Types are assigned to objects, while domains are assigned to user domains and application domains. By default SELinux security is based on enforcing types. This is called TE or Type Enforcement. Access is determined on the relation of the source type field to the target type field. A Source is a domain and a Target is a type, because subjects operate on objects.

Security Level Field.
This is the last of the four fields that make a security context. The SELinux security level field has a security level. This field is, atleast at the moment, only used by multi level security policy used by government. But often support for MLS policy is enabled. If you do not use a specific MLS policy than you can disregard this field. With MLS policy, user domains get partitioned. This means that user domains operating on different security levels can not interact with each other. This is used to maximize integrity of data. On a default SELinux configuration with MLS enabled (but not necessarily a MLS policy loaded), this field may have a type of s0 which relates to the default security level 0 on which the system operates. This level is also referred to as SystemLow.

Multi level security also uses a model called multi category security. MCS will allow administrators to further confine user domains on that operate on security levels by using compartments.

For example: user_A operates on security level: 1 in compartment: office, while user_B also operates on security level :1 but in a different category: factory. Although both user domains operate on a same level, each user domain is also member of a different compartment. If a user is not a member of a compartment than access to objects in that category is denied, even when a user does operate on the same security level.

An example of a security context:
secret_u:user_r:user_t:s1:c0

This is a fictional user on a SELinux system with a MLS policy enforced. This user is part of the SELinux user group secret_u, the role of this user is a user role. This role has no privilege to change roles in a MLS invironment. The type field of this user domain is derived from the role field: user_t. This user operates on a non default security level 1 (called secret) and on that level this user domain has access to compartment c0. Where c0 could be office. This user operates on a secret security level in the office compartment of the security level.