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!
zaterdag 29 december 2007
donderdag 13 december 2007
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.
/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.
woensdag 5 december 2007
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-*
/etc/audit/audit.rules
The audit documentation directory can be found at:
/usr/share/doc/audit-*
dinsdag 20 november 2007
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
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
maandag 19 november 2007
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/
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.
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.
SELinux security
SELinux security relies on a mandatory access control model. It takes into consideration policy that is defined by the administrator.
- More knowledge and time is required for administration
- Objects on a system are abstracted in two classes, subjects and objects. Subjects are user domains and application domains. Objects are files named_pipes dirs lnk_files fifo_files etc
- Offers fine grained control of security
- Ability to restrict access from subject to objects on a lower level
- Mandatory Access Control disregards Discretionary Access Control
- More knowledge and time is required for administration
- Objects on a system are abstracted in two classes, subjects and objects. Subjects are user domains and application domains. Objects are files named_pipes dirs lnk_files fifo_files etc
- Offers fine grained control of security
- Ability to restrict access from subject to objects on a lower level
- Mandatory Access Control disregards Discretionary Access Control
Traditional Unix security
Traditional Unix security is based on a discretionary access control model. This discretionary access control model has properties that we must understand to be able to determine the advantages and disadvantages of this access control model and other access control models.
- It is to the discretion of the owner of the object to grant other users access to the object.
- Users are either root or user. The system can not see a difference between a process that was started by a user or executed by the system.
- Users could gain root privileges through objects that have setuid or setgid set. A process could escalate privileges.
- Access to objects are based on user identity.
- Access is liberal.
- It is to the discretion of the owner of the object to grant other users access to the object.
- Users are either root or user. The system can not see a difference between a process that was started by a user or executed by the system.
- Users could gain root privileges through objects that have setuid or setgid set. A process could escalate privileges.
- Access to objects are based on user identity.
- Access is liberal.
Documentation on domain specific booleans and security contexts
SELinux policy is based on a least privilege model. This means that by default, a user domain and a application domain have as little privileges possible over objects. Additional security contexts and tunable policies provide support for extra privileges that a user domain and application domain may require over objects.
Domain specific booleans and security contexts are documented and can be referenced on a system. For example the HTTPD policy has additional security contexts for objects that the HTTPD application domain may require extra privileges over. SELinux HTTPD policy also has additional tunable policies to provide additional functionality to the HTTPD application domain.
Domain specific booleans and security contexts are documented and can be referenced on a system. For example the HTTPD policy has additional security contexts for objects that the HTTPD application domain may require extra privileges over. SELinux HTTPD policy also has additional tunable policies to provide additional functionality to the HTTPD application domain.
We can query these application domain specific tunable policies and security contexts with man httpd_selinux
How to determine if our system supports SELinux
SELinux is compiled into the kernel and is supported via Logical Security Modules. To determine if our kernel is compiled with SELinux support we must first determine our running kernels' kernel-release.
Once we determined our currently running kernels' kernel-release, we can query the configuration file that was used to compile this kernel.
The config_security_selinux option is set to 'yes'. This means that SELinux support is compiled into this kernel. The config_security_selinux_disable option is also set to 'yes'. This means that SELinux is not enabled by default.
Or you could determine it the same way most people do: grep selinuxfs /proc/filesystems
To determine the current status of SELinux on our running system.
# uname -r
2.6.23.1-49.fc8
Once we determined our currently running kernels' kernel-release, we can query the configuration file that was used to compile this kernel.
# grep -i selinux /boot/config-2.6.23.1-49.fc8
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
The config_security_selinux option is set to 'yes'. This means that SELinux support is compiled into this kernel. The config_security_selinux_disable option is also set to 'yes'. This means that SELinux is not enabled by default.
Or you could determine it the same way most people do: grep selinuxfs /proc/filesystems
To determine the current status of SELinux on our running system.
# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 21
Policy from config file: targeted
Thanks to Method for letting me quote you in this article. You can view his blog here: http://securityblog.org/brindle/
Abonneren op:
Posts (Atom)