SELinux support development thread

[swelljoe]

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]

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]

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]

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]

1. There's a few script installers, like odoo InstallScript https://github.com/Yenthe666/InstallScript/issues/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]

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 we have), particularly since 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]

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

[ShopixRo]

Hi,

Does anyone know if Virtualmin be used with SELinux enforcing? Is it by default or some changes are required?

Thanks!

[swelljoe]

I think all of the answers to your question can be inferred from this thread, @ShopixRo . ;-)

Virtualmin can be used with SELinux enforcing (read above, I have a couple of servers doing so), but it is not the default (also mentioned above for the reasons also given). Some changes are required (at least the ones mentioned above, possibly more given your environment and requirements). SELinux needs a lot more hand-holding than most people are willing to do, and in my testing I think I've convinced myself it's not going to be something we can ship as a default, but it might be something that can be enabled for users that want it and are are prepared to pay the additional administrative and support cost.

[chris001]

I think having as good or better security than Android OS - which runs on Linux, and is "everywhere", just like Virtualmin is - is a worthy goal to aim for.

• With Android KitKat (4.4), SELinux was switched to Enforcing mode!
• With Android Lollipop 5.x, in 2014, SELinux was mandatory Enforcing mode, for all apps on the system!

Ref: https://www.techrepublic.com/article/ios-and-android-security-a-timeline-of-the-highlights-and-the-lowlights/

[swelljoe]

Android is a wildly different platform. They don't even use common package formats, and distribute their OS updates in a container-y image format. Completely irrelevant to what we do...we aren't shipping an operating system and don't have that level of control over the system.

SELinux is on the radar but it's unlikely to be default anytime soon unless someone else does the development or sponsors it.