Previous Entry Share Next Entry
Fun with confined users.
I was recently asked 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
if you use sh ~/virus it seems that you can launch "virus".

Yes sadly as was mentioned in the original email, we can not block interpreters and shells. This protects more against strictly executables.

  • 1

Log in

No account? Create an account