donderdag 18 juni 2009

SELinux lockdown

Sumaary of things that can be done to lock down SELinux in Fedora 11

1. Use confined users.

By default Fedora maps users to a unconfined user domain. This unconfined user domain was designed to be able to exempt users for most SELinux policy.

Using the unconfined user domain as a primary user environment is not a good idea for security. The same way root logins arent a good idea.

So use the semanage login () command to let new be mapped to a confined user domain of your choosing instead of unconfined_t. Which confined user domain to use depends on the properties of the user.

There are a few profiles to choose from. I map my new users to the guest_u SELinux user.

Guest_u is a unprivileged user that can only log in via SSH. This user has no access to network resources and to setuid/getuid. This user can be denied to execute in the user home space.

Xguest_u is similar to Guest_u except that Xguest cannot log in via SSH but can only login via XWindows.

User_u is similar to Xguest_u except that user_u can log in both via SSH and via XWindows. User_u also has access to network resources.

Staff_u is similar to user_u except that staff_u can use setuid and setgid programs. Staff_u can also stat all processes on the system and has some other minor privileges.

Sysadm_u is a confined root login. root log ins arent recommended so ill skip this user

Unconfined_u login is bad ;)

You can override de default mapping for new users if you use useradd -Z

So if you configured SELinux to map new users to guest_u seuser but want to add a specific user to another SELinux user group (for example add user joe to user_u): useradd -Z user_u joe

You can also change mappings later with the semanage login -m (modify) command

refer to: man useradd and man semanage

2. Configure pam_sepermit

So now were using confined user environment for all our users (except root which should not log on anyways except maybe via TTY in emergencies).

What if the system happens to be in permissive mode? If you run setenforce 0 then all SELinux AVC denials will be allowed (but logged). That means your confined users are no longer restricted by SELinux.

We can mitigate this by using /etc/security/sepermit.conf. You can add users and seusers there and then login will be denied if SELinux is in permissive mode.

For example: putting %user_u in sepermit.conf will disallow user_u seusers the login if getenforce returns: permissive. (try it out)

It should be noted that setenforce (permissive mode) is not recommended or even required anymore on Fedora 11. Fedora 10 instead introduced "permissive domains". The difference between permissive mode and permissive domains is that with permissive domains we can change the state of single processes (domains) to permissive instead of having to put the whole system into a permissive state.

So preferable use permissive domains if you need to troubleshoot some issues. the command semanage permissive -a enable permissive mode for a domain type and the command semanage permissive -d deletes the permissive domain for a domain type.

refer: man semanage

3. You can still use the unconfined user domain as a secundary user role for privileged users.

I will admit sometimes if you want to do some generic sysadmin task you just dont want to be restricted. Thats fine. You can still use the unconfined user environment as a secundary role.

For example. my primary user domain is staff_u as you know this seuser has access to setuid /setgid programs like sudo. I used the semanage user () command to map the unconfined user domain along with the system system domain to the staff_u seuser. Now staff_u can role transition to the unconfined user space if he want to do generic admining.

Just setup /etc/sudoers and of you go:

semanage user -m -L s0 -r s0-s0:c0.c1023 -R "staff_r system_r unconfined_r" -P user staff_u
echo "joe ALL=(ALL) TYPE=unconfined_t ROLE=unconfined_r ALL" >> /etc/sudoers

You do not have to explicitly define your default secundairy role in /etc/sudoers like the example above. You can also define your target role when you run the sudo command like so: sudo -t unconfined_t -r unconfined_r service httpd restart.

Note that only sudo support role transitions. su does not. if you use su (not recommended) then you also need the newrole program (yum list *newrole*)

Also note that besides the unconfined user domain there are other confined user domain designed to be secundairy privileged roles (roles specific to a task) for example the webadm_r role which lets root only manage the webserver. Try it out add the webadmin_r role to staff_u with semanage and use sudo to transition to the webadm environment.

refer: man sudo, man semanage, man su, man newrole

4. More about unconfined

Before F11 unconfined was a space for any process that needed to be unrestricted be it a program or a user. Both programs and users could be run in this unconfined space. During F11 the unconfined domain was split into a unconfined and unconfineduser domain.

What this means to us is that we can uninstall the unconfined domain now but still use the unconfineduser functionality (unconfined user domain) (or vice versa)

So how can this help us lock down SELinux? Well we can now uninstall the unconfined module with semodule -i unconfined so that no system services can run unconfined.

Just like users are by default mapped to a unconfined user environment in Fedora, system services that do not have SElinux policy defined are also automaticly executed in a unconfined environment. What it means is that you might install a system service that has no policy and it will run unstricted. This presents another gaping hole in your security. Because that service can potentially be used to go around selinux.

By uninstalling this unconfined module this can no longer happen. If you install a system service that does not have policy then it just wont run. Youd need to write policy for it first.

5. lock down your booleans

In Fedora some booleans are activated by default. booleans are "tunable policy". Rule that can be enabled on the fly by admin. The more rules are enabled the less fine grained your security becomes. So you need to remove as much policy as possible by toggling booleans on or off.

I say on or off because some booleans may add policy if you turn it on and other when you turn it off.

I cannot explain all booleans here but i will talk about some.

- the secure mode booleans have policy that allow admin to (off is befault. to lock down set to on):
-- put the system into permissive mode
-- inset kernel modules
-- load policy

- xserver object manager has policy that enables the xserver selinux extension (off by default, to lock down set to on)
This is a very powerful feature which lets the admin define selinux policy for X server. This feature (its policy) still has rough edges. If you arent afraid of selinux feel free to experiment and improve the XACE policy like i did)

- nsplugin booleans has policy that defines what access nsplugin has
nsplugin runs you browser plugins. these browser plugins are vulnerable to all kinds of threats.
You can diable network access for nsplugin and you can disable memory execution (execmem) for nsplugin.
if you decide to use unconfined user logins anyway (not recommended) then you can still configure nsplugin selinux security by setting a nsplugin boolean. Needless to say that confined users are subjected to a confined nsplugin by default.

- unconfined login booleanhas policy that allows unconfined logins (enabled by default: to lock down set to off)
Disable unconfined logins. if you use confined users like this guide encourages then disallow unconfined logins.

There are many other booleans. disable as many as possible. keep your configured as least privilege as possible. More rules means less security in general. So play with it and disable as many as possible without losing basic functionality.

refer: man semanage, man setsebool, man getsebool

6. sandbox.
If you decide you you do not want to operate in a restricted space by default. for example if you think your environment does not prefer it then you can still use SELinux in a discretionary way with the sandbox script.

sanbox lets unconfined users run command / programs in a confined space (sandbox) So it is to the discretion of a unconfined user to run a program restricted or unrestricted, unlike confined domains which are mandatory to users (they are mapped to users by admin)

refer: sandbox --help

7. Conclusion
map you users to confined users.
use the unconfined user domain as a secundary environment for superusers.
remove the unconfined module (or unconfineduser or both depending on your security requirements)
lock down you booleans as tight as possible
use permissive domain instead of permissive mode
use pam sepermit if you have confined users

Besides these ways to lock down your selinux enable system there are the basic thing you can do to keep security tight:

Geen opmerkingen: