danwalsh's Journal
[Most Recent Entries]
[Calendar View]
[Friends]
Below are the 20 most recent journal entries recorded in
danwalsh's LiveJournal:
[ << Previous 20 ]
| Tuesday, May 13th, 2008 | | 8:51 am |
| | Friday, May 9th, 2008 | | 8:08 am |
Strict Policy is not Stricter then Targeted... I always remember reading an interview with Ken Thompson about regrets in the creation of Unix, and what would he do differently? He said would add an "e" to the creat() system call. Well looking back on SELinux I think the one of the biggest mistakes I made was calling the strict policy "strict". When Red Hat Enterprise Linux 4 came out we had targeted policy which supported 15 confined domains and the unconfined domain. While strict policy confined over 100 hundred domains including the user, and did not have the concept of the "unconfined" domain. As of Red Hat Enterprise Linux 5 strict policy is really no more strict then targeted. If you are running a server with out normal users logging in, targeted gives you the same security as strict policy. I was on the phone with a customer the other day who was setting up a web site and he was using strict policy on Red Hat Enterprise Linux 5. He was having problems getting sudo to run from a cgi script. When I asked him which policy he was running he told me strict. I informed him that in order to get support for strict policy you are supposed to have a special support contract with Red Hat. He told me that he was worried that targeted policy was not as secure a "strict". Arrrrrrrggggggg. They are the same, from an Apache point of view. Both Strict and Targeted policy in RHEL5 support around 200 confined domains. Pretty much all of system space is confined. Targeted policy is used by hundreds of thousands or machines, stict on maybe hundreds, so guess which one runs better? The two major differences in RHEL5 is strict policy confined logged in users, NOT ADMINS. If you have an server machine that only an admin is going to login to you do not want/need to use strict policy. Most admins are not confined, and will probably need to be able to execute setenforce 0 or install rpm packages, so attempting to confine them is somewhat fruitless As far as unconfined domains, The three most common on a targeted machine are - unconfined_t, default user login.
- java_t, mono_t, unconfined_execmem_t, are additional versions of the unconfined_t login
- initrc_t - default policy for services started by /etc/init.d/ scripts
- This allows any third party software that does not have a policy to run
- inetd_t - default policy for services run in /etc/xinetd/
- inetd_child_t is another form of this domain
If you want to make sure your machine is not running an unconfined domain you can check for these processes. Luckily Strict policy disappears with the advent of Fedora 9. In Fedora 9 you can run confined users and unconfined users at the same time. You you remove the unconfined.pp policy module, you will remove the ability to run unconfined domains. So I will not need to worry about policy "naming" in the Future. | | Saturday, April 26th, 2008 | | 6:13 am |
SELinux requirements for placement of pam modules in /etc/pam.d/* files
As people begin to use confined users, placement of pam_modules in the /etc/pam.d configuration files becomes critical.
# cat /etc/pam.d/gdm
#%PAM-1.0
auth [success=done ignore=ignore default=bad] pam_selinux_permit.so
auth required pam_env.so
auth substack system-auth
auth optional pam_gnome_keyring.so
account required pam_nologin.so
account include system-auth
password include system-auth
session required pam_selinux.so close
session required pam_loginuid.so
session optional pam_console.so
session required pam_selinux.so open
session optional pam_keyinit.so force revoke
session required pam_namespace.so
session optional pam_gnome_keyring.so auto_start
session include system-auth
There are three SELinux pam modules listed in the /etc/pam.d/gdm config file. pam_selinux_permit.so reads /etc/security/sepermit.conf looking for usernames, if found and SELinux is in enforcing mode the user can login without a password. pam_selinux_permit.so is used with the xguest package for kiosk users.
pam_selinux.so is the important module though. pam_selinux.so defines the SELinux user/context that gets assigned to you when you login. pam_selinux.so is called twice within the pam session once with the close parameter and once with the open. Pam session modules are called once when a new session is started/opened and once when the session is ended/closed. So the open parameter tells pam_selinux.so to only execute the open section of the pam_module when this module gets executed. The close indicates to pam_selinux.so only execute the close section of the module.
What does this really do?
pam_selinux.so open uses libselinux functions to setup the security context for all programs to be execed by the "login" process. If I setup a user to login as staff_u, pam_selinux.so open tells the kernel programs execed from the login program from this point forward will be execed as staff_u:staff_r:staff_t . pam_selinux.so close uses the libselinux functions to tell the kernel to go back to the default.. So all pam_modules called on the closing of the session will either run in the login's programs context (gdm_t) or will transition if policy is defined.
While this seems complicated, the important thing to understand is, if you want to add a pam_module that requires special (root) privileges and execs helper apps , it probably needs to be added before pam_selinux.so open, since pam_selinux.so open might be defining a confined user which is not be allowed to to execute the helper applications or the access the helper application requires. pam modules that exec applciations that can be executed by the user or requires knowledge of which SELinux context the user will get assigned need to be defined after pam_selinux open.
session optional pam_keyinit.so force revoke
session required pam_namespace.so
session optional pam_gnome_keyring.so auto_start
session include system-auth
These pam modules all do things that require Selinux user access, or use the context of the user to label objects.
pam_keyinit.so sets up the labeling of the keyring based on the SELinux user context. pam_namespace can mount directories based on the SELinux context pam_gnome_keyring.so executes commands that the user would be allowed to execute and system-auth can execute pam_kerberos, which creates files in /tmp or uses the kernel keyring and would require SELinux context.
session optional pam_console.so
pam_console on the other hand execs /sbin/pam_console_apply which is a privileged application that a confined user would not be allowed to execute, so it needs to be run before pam_selinux open.
If you are going to add a pam_module that would exec commands that the user would not be allowed to execute, for example pam_mount, it should be added before the pam_selinux.so open command. If you are adding a pam_module that execs command a user could execute, then you probably want these after the pam_selinux.so open line. | | Wednesday, April 23rd, 2008 | | 7:03 am |
Confining Users Continued. A couple of people have asked questions about yesterday's Post. The root account is still defaulted to unconfined_t. If you "ssh localhost -l root" and login, you will get an unconfined_t SELinux user and will be able to do all normal administrations. Similarly if you execute "ctl-alt-f1" to get a console login, you can get a root login, running as unconfined_t. I have experimented with setting up my login account with user_t, which would not have access to setuid applications. No access to su or sudo and force my self to "ssh localhost -l root" for administration. | | Tuesday, April 22nd, 2008 | | 10:08 am |
I need Guinea pigs... REPOSTING WITH SOME FIXESOne of the problems I face, is trying to convince people to use new security products. They say, "Sure just don't break anything". The problem is I need Guinea pigs to find out what I break. In the case of confining the user, I have a problem. I believe this can be a big security step forward, but how do I get people to use it, if it is not fully tested out? How do I test it out without getting people to use it? Now I have taken some involuntary test subjects like my wife, and set her up with a confined user account and worked with her to fix problems in xguest. I have also taken the Jonas Salk approach and tested on my self. I have been running as the staff_u user for the entire run of Rawhide since Fedora 8. So I am now beginning to Beg co-workers to try it out. As people start to install Fedora 9, I want them to try out confined users. The simplest user for an engineer to try is staff_u with a transition to unconfined_t when you become root. This is how I set this up. First you need to modify the SELinux user record to allow it to reach the unconfined_r. You also want to allow it to reach the system_r since you might be restarting services which need to run as system_r. The command is a little ugly but follow along # semanage user -m -R"staff_r unconfined_r system_r" staff_u This tells the system to modify the staff_u user and allow it to reach the staff_r, unconfined_r and system_r roles. Now we need to modify the login account to login as the staff_u SELinux user. We can either change the default, so all users by default will login as the staff_u user. # semanage login -m -s staff_u __default__ Or we can add a record just for my Linux user "dwalsh" # semanage login -a -s staff_u -r s0-s0:c0. c1023 dwalsh Finally I want to setup a sudo to allow me to transition from staff_t to unconfined_t when running commands using sudo. Add a record like to following using visudo dwalsh ALL=(ALL) TYPE=unconfined_t ROLE=unconfined_r ALL Now logout and log back in and you should be running as staff_u:staff_r:staff_t, Execute "sudo sh" and you should be running as staff_u:unconfined_r:unconfined_t. One caveat for this environment is currently userhelper apps will not work (system-config-*) when executed from staff_t, But you can run them from the sudo root account. What does this buy you? While running in staff_t you will not be allowed to run any setuid application that is not confined. So if somehow you were tricked into running a setuid app on your machine to become root, it will fail. You will automatically transition to nsplugin so your firefox will have confinement. The ONLY way to become root/unconfined_t is through sudo, which is a well studied application. If you run attempt to run su, you will be denied. So do I have any volunteers???? I am fixing a typo in the command above sorry about reposting.
Also if you want to reverse the changes listed above
You could execute
semanage login -d dwalsh
Will remove the record and put dwalsh back to the default.
# semanage login -m -s unconfined_u __default__
Would set the default logins to be unconfined_u (the default) | | Monday, April 21st, 2008 | | 8:53 am |
| | Thursday, April 17th, 2008 | | 8:32 am |
I think we are on the right track... Every so often you see an article like This_New_Vulnerability:_Dowds_Inhuman_Flash_Exploithttp://osnews.com/story/19639/This_New_Vulnerability:_Dowds_Inhuman_Flash_Exploit And you realize you are on the right track. Users are being trained to run more and more software off of web servers, and lets face it whether the code is Open Source or closed source the user has no idea what the software is doing on his machine. A couple of years ago, my 14 year old son came to a web site that offered "Dancing Bikini's on the Desktop", there are not two many 14 year old boys that could resist this offer. :^) Of course his machine was quickly infected. A couple of weeks ago I wrote about confining nsplugin with SELinux. NSPluginWrapper is a tool used to run Firefox Plugins in a separate process. In Fedora 9 we have the capability to confine it. SELinux would stop vulnerabilities described above in two ways, First the buffer overflows protextion of execmem, execheap, execstack would cause the vulnerabiltiy to blow up before the plugin could execute the hacker code, Then if if the vulnerabilty was able to get past the memory checks, SELinux would confine the plugin to only be allowed to do what plugins are supposed to do. It would not allow the plugin to connect to random ports, like the email port. The plugin would not be allowed to write to random places in the users home directory, it would not be allowed to grab data from sensitive directories like .ssh or .gpg. If you like to try it out, make sure you install nspluginwrapper, and turn on the allow_unconfined_nsplugin_transition boolean. # setsebool -P allow_unconfined_nsplugin_transition 1 This will allow the default login domain unconfined_t to transition to nsplugin_t when Firefox starts the plugin wrapper. To make this work well you will also need to relabel you homedir. # restorecon -R -v ~/ As we move forward I want to get to the point where we can turn these features on by default. But a lot of this technology is brand new and needs to get flushed out, problems like labeling of the home directory, or users wanting to run some random plugin that does something weird. We have a constant battle between "Usability" and Security. If we turn on features like nsplugin_t by default, we increase security, but if SELinux stops "Dancing Bikinis", I get the SELinux Sucks how do I turn it off... | | Thursday, April 10th, 2008 | | 8:54 am |
| | Saturday, April 5th, 2008 | | 11:18 am |
Dear Oracle, I would advise you that it is never a good idea to advise your customers to turn off a fundamental security software component of the operating system, so that your broken code can run. http://download.oracle.com/docs/cd/B28359_01/relnotes.111/b32001/toc.htmYou have written PHP scripts that require the use of executable memory, a chief mechanism for crackers to attack systems. In order to have your PHP to work, you advise your customers to turn off SELinux enforcing mode, I guess this is better then tell customers to just shut it off all together. If you investigated this at all you had two other options. 1. Fix your code, Read SELinux Memory Protection Tests , Uli has some good suggestions on how this can be done. 2. You could ship a policy package, which your customers could download to turn off the memory checking for apache while your coders fix their bugs, then only apache would be vulnerable, not the entire system. BTW You could generate the policy package by executing # grep http /var/log/audit/audit.log | audit2allow -M oraclebufferoverflowallow This will generate the oraclebufferoverflowallow.pp package. Which you can then ask your customers to download and install semodule -i oraclebufferoverflowallow.pp When you fix your bugs, they can execute semodule -r oraclebufferoverflowallow Your friend, Dan | | 7:08 am |
So does SELInux really stop any attacks?
Tresys corporation is tracking some of the known vulnerabilities in the past that SELinux has thwarted.
You can read about them at
http://tresys.com/selinux/
One key feature of SELinux is the confinement of executable memory. This tops applications from having memory that is both executable and writable at the same time. A lot of attacks on computer software involve a coding mistake in code that allows the writing of memory beyond the end of an allocated buffer, called a buffer overflow. So a cracker find a piece of code that allocates less space then the code can write. The cracker tricks the application to writing his data into the overflowed buffer. Finally he attempts to get the application to execute the buffer that he has just written. SELinux executable memory checks in the kernel prevent this.
While we have attempted to turn these checks on for the unconfined user in the past, we have had missed success, because of badly written applications breaking. But for almost all confined applications these checks are turned on. So if a vulnerability exists in a confined application that involves a buffer overflow, most likely SELinux will prevent it.
| | Monday, March 31st, 2008 | | 8:14 am |
I relabeled but SELinux is still blocked.
I have been travelling all over Europe last week and this, talking about SELinux,
But a couple of times the last week the question came up about why doesn't touch /.autorelabel; reboot fix the labels on all files on the machine.
Certain directories on the machine have a file context of <<none>> in the /etc/selinux/POLICYTYPE/contexts/file_contexts file.
This tells the tool that files could be labeled anything in this directory so tools like restorecon, setfiles, fixfiles just leave the contents alone.
If you grep the file
# grep -i None /etc/selinux/targeted/contexts/files/file_contexts | wc -l
34
You will see 34 matches. Most of these are lost+found directories , spool directories, /var/run and tmp directories.
The one that usually causes problems though is /tmp. As Iblogged before System tools should never use this directory, but sadly some still do. If a confined domain tries to access a mislabeled file in /tmp and gets an access denied, a relabel of the file system will not help.
We used to remove the contents of /tmp when a user touch /.autorelabe; reboot, but this was considered too dangerous. Some users consider /tmp more permanant then others. Personally I always run my system with a tmpfs file system on /tmp, that way all the garbage gets removed on reboot. Easiest thing to do when you see one of these AVC's on /tmp is just to remove the files from /tmp and restart the service. For example if I had a problem with xdm accessing some mislabeled files in /tmp, I would
# rm -rf /tmp/.??* /tmp/*
Then restart my gdm service
If people have a better idea for solving this problem, I am all ears. | | Tuesday, March 18th, 2008 | | 10:50 am |
Labeling of xen images
A place people sometimes trip with SELinux is the labeling of files. SELinux requires files to be labeled correctly in order to function. Discretionary Access Control has the same requirement in that file must have the correct permissions and ownership. If a file does not have the correct permissions it can not be read, written or executed. Similarly if a file is not labeled correctly SELinux will prevent read/write/execute as well as many other permissions and transitions.
xen and qemu virtuallization has this problem alot. SELinux requires that images used by xen be labeled xen_image_t, and images used by qemu/libvirt be labeled virt_image_t. virt_manager currently does not do this by default and it creates the images in the current directory by default, which I hope they change. However there are directories where the image files will automatically get the correct label.
Fox xen we have the labeling
/xen(/.*)? system_u:object_r:xen_image_t:s0
/var/lib/xen/images(/.*)? system_u:object_r:xen_image_t:s0
With /var/lib/xen/images the preferred location
If you don't have a /xen directory, you need to create it and then reset the labeling.
# mkdir /xen
# restorecon /xen
For qemu/libvirt we have the labeling
/var/lib/libvirt/images(/.*)? system_u:object_r:virt_image_t:s0
If you were to store the xen images somewhere else, you would need to set up the labeling to that place. SELinux uses regular expressions to map files to file context so at the end of the directory specification you need to add (/.*)? which tells SELinux to label everything labeled in the directory and its subdirectories xen_image_t.
# semanage fcontext -a -t xen_image_t 'PATHTOIMAGEDIR(/.*)?'
# restorecon -R -V PATHTOIMAGEDIR
Note: If you are creating a whole new directory structure, you make need to label the entire directory tree xen_image_t. SELinux requires that a confined domain be able to list all directories in the path of the image. New directories created in / get either labeled default_t or root_t, default_t directories are not usually allowed to be searched. If you create the image in a directory tree that xen or virt are not allowed to list, you might need to build some custom policy.
If you were to store your xen images in /myxen/images/
You would execute
# semanage fcontext -a -t xen_image_t '/myxen(/.*)?'
# restorecon -R -V /myxen
You would do the same for libvirt/qemu except use virt_image_t. | | Thursday, February 21st, 2008 | | 8:41 am |
user_u is now available in Rawhide/Fedora 9
I have written several blogs on the xguest and guest SELinux users. There are other types or SELinux users.
Today I want to describe the standard SELinux User. At Red Hat we have a distribution of RHEL that is given to all non engineers by the IS Department. Sales People, Support, Administration, Management are giving a version RHEL Boxes/Laptops without the Root Password. These are machines for people who do not want to administrate their own machines. The IT Department is in charge of updating the software on these boxes and maintaining the security, if users want to add software or modifiy their machines they have to contact the help desk for an update.
In the future these machines accounts should be setup to use the user_u SELinux user. user_u is a complete login user account, unlike xguest though it has full networking, so the user can connect to any network port. It does not have the ability to run setuid applications without a transition. Since the users of this machine have no reason to ever become root, they do not have the ability to run su, sudo, userhelper or any other application that requires setuid. This protects the user against most vulnerabilities in software which would allow a root attack.
If you have an setuid application that you want the user to be able to run, you can write policy to allow the user_u account to transition to a different domain to execute the code. For example, xlock uses pam to verify the users password. pam execs /sbin/unix_chkpwd a setuid application. Policy allows a transition from user_u:user_r:user_t -> user_u:user_r:chkpwd_t which can run as root.
Like xguest , the user_u account can be set to not allow execution of programs in the home directory or /tmp.
setsebool -P allow_user_exec_content=0
If you want to setup your system to try out the user account, you can execute the following command as root:
# semanage login -m -s user_u USERNAME
or
# usermod -Z user_u USERNAME
If you want to add a user with user_u, you can execute
useradd -Z user_u USERNAME
If you want all users on your system to default to user_u you would execute
# semanage login -m -s user_u __default__
Try it out... | | Wednesday, February 20th, 2008 | | 10:57 am |
xguest blocks word document from executing temporary files...
I belong to a Condo association and they sent out an Email with a .doc attachment to all owners. My wife downloaded the document onto her machine and called me to tell me that she was not able to read it. I saw the same document, and was able to read it so I suspected there was a problem with xguest. When I arrived home, I looked at the audit.log file and sure enough OpenOffice was being blocked by xguest policy.
I saw an avc that said, xguest_mozilla_t (firefox/openoffice) was not able to execute xguest_home_t or xguest_tmp_t. I thought this is strange, so I looked further. Turns out the doc file contained some kind of macros (I am guessing that is what they were) that OpenOffice gladly extracted into a tmp file and tried to execute. Now I have no idea what these macros were supposed to do, or what they did on my machine. But a tightly confined machine like xguest blocked the execution. It makes you step back and think about potential problems that can arise when a random Word Document can cause temporary files on your home dir to be executed.
You can toggle this behavior though the use of the boolean, allow_xguest_exec_content.
setsebool -P allow_xguest_exec_content=1
will allow xguest users to execute programs in thier home directories or on /tmp.
This is turned off by default. | | Monday, February 4th, 2008 | | 9:44 am |
Confining User Space My SELinux goal in Fedora 9 is to begin confining user space. Confinement of user space has to be optional, to make sure SELinux does not get a Black Eye for breaking some random application. | | Thursday, January 24th, 2008 | | 4:16 pm |
audit2why update It has been a while since I last posted. Sorry about that. I have a lot of information to post, so plan on blogging a lot in the future. We have just released a new version of audit2allow/audit2why to Rawhide for Fedora 9. | | Monday, November 26th, 2007 | | 8:32 am |
Customizing xguest policy.
Peter Harmsen sent me an email asking the following:
"
I have switched the user role of an existing account to xguest_u thus enabling kiosk mode for this specific user. Works like a charm, thanks. Now i only need to permit ssh access.
According to :
# grep ssh /var/log/audit/audit.log | audit2allow -R
require {
type xguest_t;
type devlog_t;
type guest_t;
class sock_file write;
}
#============= guest_t ==============
allow guest_t devlog_t:sock_file write;
#============= xguest_t ==============
corenet_tcp_connect_ssh_port(xguest_t)
How could i give the xguest user also ssh access in addition to web browsing with firefox?
"
My response was that he should create a policy module to add these allow rules by executing
# grep ssh /var/log/audit/audit.log | audit2allow -R -M myssh
# semodule -i myssh.pp
Peter responded that this worked perfectly.
I decided to examine this further.
I would have used:
auth_send_syslog_msgs(xguest_t)
Which allows the xguest_t and more specifically the ssh application to send syslog messages.
Adding:
corenet_tcp_connect_ssh_port(xguest_t)
Allows xguest_t and ssh to connect to ssh ports.
# semanage port -l | grep ssh
ssh_port_t tcp 22
I was somewhat surprised that Peter did not need to add:
corenet_all_recvfrom_unlabeled(xguest_t)
corenet_all_recvfrom_netlabel(xguest_t)
# These two lines allow support for labeled packets to flow across the machine.
corenet_tcp_sendrecv_all_if(xguest_t)
# Allows xguest to send/recv packets on all interfaces.
corenet_tcp_sendrecv_all_nodes(xguest_t)
# Allows xguest to send/recv packets too all nodes.
Investigating further, the xguest module includes the following interface:
auth_use_nsswitch(xguest_t)
This interface allows xguest_t to do translate UIDs to user names on machines using network logins. The command
# ls -l
requires this.
The auth_use_nsswitch interface adds allow rules for accessing DNS for resolving hostnames (dns_port_t) and allow rules for accessing LDAP (ldap_port_t). auth_use_nsswitch also can adds rules allowing access to NIS/YPBIND ports, but this is protected by the allow_ypbind boolean.
We policy developers should add a new boolean (use_ldap_auth?) to turn off ldap access for confined applications on machines that do not use LDAP password information.
What about minimal privilege?
Peter added connect access to ssh_port_t for any application that xguest runs. xguest_t uses minimal privilege to access httpd_port_t. When xguest_t tries to access the Internet, only firefox is allowed access, all other apps are denied. A more secure solution for Peter might have been to write a new policy for the /usr/bin/ssh command.
He could have labeled /usr/bin/ssh ssh_exec_t, and wrote policy to transition to xguest_t to ssh_t. ssh_t could be the only application that connects to ssh_port_t ports. Giving Peter true least privilege. No other applications run by xguest_t would be able to talk to port ssh_port_t. Problems? This adds a great deal of complexity.
Should Peter label /usr/bin/scp ssh_exec_t? stunnel?
If Peter labels scp ssh_exec_t, can it read xguest_home_t? xguest_tmp_t? Random files on his machine? If he copies file to his local machine, can it what to his home directory? (xguest_home_t)?
Working towards true Least privilege is a noble goal, but with potentially a large increase in complexity.
Depending on your security goals, SELinux gives you the flexibility to get the security you need. | | Tuesday, November 20th, 2007 | | 12:58 pm |
| | Saturday, November 17th, 2007 | | 5:52 am |
Breaking news on Xguest. When I first started talking about xguest, I talked about it as finally a policy I can use to control my Wife, well at least her Internet activities. It is a good thing she does not read my blog. Well this past week I updated her laptop to Fedora 8 (Great Distribution). And now she is officially logging in as a SELinux user XGuest. So far she has not noticed. Next goal my 75 year old father. :^)
| | Tuesday, November 13th, 2007 | | 7:42 am |
Samba Policy - Type Enforcement File In the previous entry I documented how to use Samba with SELinux. In this blog I will actually walk through the Samba SELinux policy. As you know Policy is made up of three files, File Context (FC) Type Enforcement (TE) and an Interface file (IF) Lets start by looking at the Type Enforcement File samba.te. It the src rpm this file is located at policy/modules/services/samba.te. This file contains all the rules uses to confine all of the domains (processes) in Samba. |
[ << Previous 20 ]
|
![[info]](http://p-stat.livejournal.com/img/userinfo.gif){kind=small}
danwalsh's journal