Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SELinux support development thread #1

Open
swelljoe opened this issue Oct 26, 2017 · 6 comments
Open

SELinux support development thread #1

swelljoe opened this issue Oct 26, 2017 · 6 comments

Comments

@swelljoe
Copy link
Collaborator

@swelljoe swelljoe commented Oct 26, 2017

This is just a place for me to dump my notes about running Virtualmin with SELinux enabled (and for anyone else to contribute their own experimental results). It's possible, but still somewhat prone to mysterious failures for non-root user actions (i.e. domain owner users may still find themselves getting confusing permissions errors and will be unable to diagnose them without root-user assistance).

@swelljoe

This comment has been minimized.

Copy link
Collaborator Author

@swelljoe swelljoe commented Oct 26, 2017

Copied from a ticket on virtualmin.com:

I actually do test with SELinux enabled and run with it enabled full-time on a couple of my own servers as a learning experience, and I think it's mostly reasonable these days, but there are several booleans you have to switch to make it work.

The reason we disable it, and still recommend it be disabled, is that there's a huge variety of things (mostly outside of Virtualmin itself and not controlled by Virtualmin) that will fail in mysterious ways, and if they fail for a user other than root, they almost certainly won't even be able to figure out why. It really depends a lot on what you're doing.

I have a list of the booleans I've come up with so far. Lemme grab those...

OK, here's my notes on the subject, if you wanted to try it (but I can't recommend it for any system that'll be hosting other users...they will almost certainly run into weird errors and may not have any idea that it's SELinux causing it):

# ProFTPd
setsebool -P ftp_home_dir=1

# Compatibility for FTP clients that don't use ephemeral ports
setsebool -P ftpd_connect_all_unreserved=1

# FTP server runs as daemon rather than inetd mode (maybe systemd spawn, as well?)
setsebool -P ftpd_is_daemon=1

# See also: ftpd_selinux man page

# Apache bools: https://wiki.centos.org/TipsAndTricks/SelinuxBooleans

Sorry, this last bit is just a link, and I haven't sorted out exactly which bools are needed for the general case, but there will be quite a few httpd bools that need to be enabled that aren't default. I have a list of some of them somewhere, but it's not in my todo list for some reason. I guess I have some SELinux notes somewhere else. I'll try to dig those up. It's in my plans to make an install target that enables SELinux, but it probably won't be super soon; the problem is that if you setup SELinux to work really smoothly for all the use cases most people have for a Virtualmin system, you've probably opened it up too much to do any good. There really needs to be some awareness of what the system is used for, so that the booleans can be set appropriately.

But, the good news is that they are mostly booleans (just on/off switches) at this point. The first time I setup a Virtualmin system with SELinux it required a gazillion specific manually created rules. There's still gonna be a lot of them...maybe two dozen once all services are accounted for, but nothing like that first SELinux system.

I guess what I'm trying to say is that SELinux is probably actually usable enough to where we could roll it out for some users, and I've started adding support for it in Virtualmin-Config already (some bools get set during the relevant plugin), but I still have serious reservations about its usability. It's a terrifyingly complex system.

@chris001

This comment has been minimized.

Copy link

@chris001 chris001 commented Oct 27, 2017

SELinux would be amazing to get working fully on Virtualmin to help prevent users from hacking other users accounts on a shared server, currently possible against live internet servers, such the hack where they upload a PHP shell disguised with an image extension, then visiting the URL of the image, the web server executes it and the hacker gets the php shell which gives the ability to read privileged system security files /etc/passwd and /etc/shadow.

@swelljoe

This comment has been minimized.

Copy link
Collaborator Author

@swelljoe swelljoe commented Oct 27, 2017

such the hack where they upload a PHP shell disguised with an image extension, then visiting the URL of the image, the web server executes it and the hacker gets the php shell which gives the ability to read privileged system security files /etc/passwd and /etc/shadow.

No PHP script has the ability to run as root, even if the user isn't using suexec. PHP never runs as root and thus can't read /etc/shadow, unless other privilege escalation bugs are present, in the kernel or the root user of the server has a weak password, or the domain user account has sudo privileges and a weak password or sudo-without password. (And /etc/passwd doesn't matter; it doesn't have passwords.)

There are real threats that SELinux can prevent, but that's not one of them.

@chris001

This comment has been minimized.

Copy link

@chris001 chris001 commented Oct 27, 2017

  1. There's a few script installers, like odoo InstallScript Yenthe666/InstallScript#46 , which currently run the web service as a user with sudo privileges, This is dumb, and is currently being tested to run without sudo privileges, and soon will be working, but until then, it's vulnerable to data theft.
  2. I have a couple of PHP shell scripts which hackers used to attack a Virtualmin server I administered. In case you want to test the security of Virtualmin against "real world threats from the wild", you can have copies and try uploading them to regular user accounts on VirtualMin / Webmin / Usermin.
  3. Apart from getting root privileges or not, the hackers stole all the user private data on the Virtualmin server, by grabbing the mysql password (unencrypted in a configuration.php file, saved there by the web app) and did a mysqldump, and grabbed all the files on the filesystem by packing them into one archive with gzip. They performed these functions with one button each in the PHP shell app. Then downloaded our data and were gone quickly.
  4. The hackers also grabbed all the email and account password hashes on the system by doing a global search on a command line shell, and exported them, for offline running thru their rainbow tables, so that sooner or later they will have all those dencrypted user passwords also.
@swelljoe

This comment has been minimized.

Copy link
Collaborator Author

@swelljoe swelljoe commented Oct 28, 2017

Apart from getting root privileges or not, the hackers stole all the user private data on the Virtualmin server, by grabbing the mysql password (unencrypted in a configuration.php file, saved there by the web app) and did a mysqldump, and grabbed all the files on the filesystem by packing them into one archive with gzip. They performed these functions with one button each in the PHP shell app. Then downloaded our data and were gone quickly.

SELinux wouldn't prevent that. Your attacker was using privileges the domain owner user and the script already had and would continue to have under SELinux. SELinux wouldn't prevent a user from reading files the user is supposed to have access to. It won't solve exploitable web apps. It solves some kinds of privilege escalation, which would be its primary purpose on any sort of hosting system.

There are tools that attempt to prevent some kinds of web-based exploits (like mod_security in Apache), though they tend to mostly address things that have already been fixed in the applications they protect so they are of limited utility. That kind of tool can maybe protect poorly designed apps that are exploitable using common SQL injection attacks. It's another discussion as to whether we ought to ship mod_security. It tends to introduce subtle functionality bugs, and rarely works without extensive tweaking, so it's been something I've been hesitant to inflict on users (or on our support burden, which is already too high for the small team with have), particularly sense it tends to give people a false sense of security...it probably only prevents attacks that are already long fixed in WordPress or Drupal or whatever, and new exploits won't be addressed in the rulesets until some point after it's already fixed in WP or Drupal or whatever.

The hackers also grabbed all the email and account password hashes on the system by doing a global search on a command line shell, and exported them, for offline running thru their rainbow tables, so that sooner or later they will have all those dencrypted user passwords also.

/etc/shadow is only accessible to root. Unless they escalated to root (which would either require the user to have sudo privileges without a password, or a weak password, or there would also have to be a privilege escalation bug in the kernel or some system service that starts as root that can be manipulated to escalate the user), they wouldn't have access to system passwords.

Improving security is always great; but we've gotta match up the threat model to the right solutions. SELinux solves several security problems. But, it doesn't solve insecure web applications.

@chris001

This comment has been minimized.

Copy link

@chris001 chris001 commented Oct 28, 2017

@swelljoe
I forgot to mention. The hackers, above, who broke in thru the web application by uploading the PHP shell, they stole the domain's ssl cert and key, which were saved by Virtualmin in the home directory, /home/server3, owner and group server3.
Best practice, would be to store the key with ownership root, permission 0600.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.