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".

  • 1

Log in