Log in

No account? Create an account

Previous Entry Share Next Entry
Fun with confined users - Version II
Earlier post came from scribefire and was some how corrupted.  So lets try again.

Jeremy Allison recently asked me in an email:

"Couldn't we set up a mode where any content owned by a user, or downloaded by a user, was flagged as not executable. This means no scripts, downloaded binaries, downloaded libraries, java or perl programs etc. would be able to be executed by the logged in user. All files in any directory writeable by the user would be implicitly non-executable.

The only allowed executable content would be that which was owned by the system (ie. no one running a web browser or application that downloads runnable binaries would be able to execute them)

The system could be set into two modes, "programmer" mode, where these restrictions were removed, and "user" mode where the desktop becomes safer for web browsers, which would be the default mode for most "normal" users.

This doesn't protect users from javascript, which runs in the context of the browser, or script content that is fed directly into an interpreter program without being saved into a file with the 'x' bit set (which may actually be the majority of malware these days, I'm not sure). It also obviously doesn't protect against application bugs, and would disallow program plug-ins that are not installed via the "sudo" mechanism.


All I got to say is:

Its in there!

SELinux confined users can do this. Setup an account as a staff_u or user_u user and turn off the
allow_user_exec_content/allow_staff_exec_content you get this behaviour.

xguest_u gets this by default.

Steps to try this out.

# semanage login -a -s staff_u -rs0-s0:c0.c1023 USERNAME
# setsebool -P allow_staff_exec_content 0

Now login to USERNAME.

> id -Z
getsebool -a | grep staff
allow_staff_exec_content --> off
> getenforce
> ls -lZ ~/virus
-rwxrwxr-x. dwalsh dwalsh staff_u:object_r:user_home_t:s0 /home/devel/dwalsh/virus
bash: /home/devel/dwalsh/virus: Permission denied

# setenforce 0
Hey wait a minute, this is not Windows!!!

  • 1

I think there *may* be a bug here.

I was looking at this but i *think* i can currently go around this:

$ sesearch --allow -SC -s staff_t -t user_home_type -c file -p execute
Found 2 semantic av rules:
allow staff_usertype nsplugin_rw_t : file { ioctl read getattr lock execute execute_no_trans open } ;
ET allow staff_usertype user_home_type : file { ioctl read getattr execute execute_no_trans open } ; [ allow_staff_exec_content ]

So: nsplugin_rw_t seems executable unconditionally.

from nsplugin.te:

type nsplugin_rw_t;

.. This seems weird to me:

$ semanage fcontext -l | grep nsplugin_rw_t
/usr/lib(64)?/mozilla/plugins-wrapped(/.*)? all files system_u:object_r:nsplugin_rw_t:s0

So content in /usr/lib(64)?/mozilla/plugins-wrapped is user_home_content !?

Ok no problem so far (because that makes it conditionally executable), but:

from nplugin.if (nsplugin_role_notrans):

can_exec($2, nsplugin_rw_t)

.. This makes it unconditionally executable.

So how to go around this:

chcon -t nsplugin_rw_t ~/virus

Also i think it should noted that this functionality is limited.
For example, i *think* a perl script could still be executed by running it via the perl executable "perl ~/virus".

I think the problem is nsplugin_rw_t should not be a user_home_type.

I will submit changes to F1[2-5] and RHEL6

how to create new confined user

I don't want to use any existing SELinux users - Is it possible to create new confined user (say myuser_u) and allow him only limited binaries file?

Yes you can write policy for a new confined user. You can use sepolgen or selinux-polgengui to get started writing policy.

Limiting binaries might be more difficult depending on the binaries. Rather then be concerned about the binaries, please state your use case in terms of which files a user can read/write, which network ports then can bind to or connect to.

Being able to execute /bin/cat is not a problem. Being able to /bin/cat /var/lib/TopSecret/Plans is a problem.

  • 1