Our users have a tendency to install software that, per company policy, is not permitted to be installed. Most users have sudo privileges on their hosts, which is how they install the software.
In the Windows world, AppLocker can be used to restrict users from executing programs, by path, publisher, or hash.
Has anyone contemplating using SELinux to implement something similar to AppLocker, but for Linux?
One thought would be to roll a custom policy that creates a new type (say, forbidden_t), and then essentially prevent all access for that type. But this would not work unless we changed the default SELinux User for users from unconfined_u to user_r, and that has the potential to be very disruptive.
Even if we did this, it wouldn't permit us to blacklist by hash; it would be dependent on the path location.
We run Clam Antivirus on our hosts, so something we are thinking of doing is writing custom rules to flag the unwanted programs as malware. But unless we also used fanotify-based blocking with ClamAV, that wouldn't prevent users from executing the unwanted programs.
Note that we *are not* trying to stop malicious users from deliberately installing software they know is forbidden. Our main problem is that our users typically don't bother to consult the "forbidden software" list before installing. So we're attempting to catch users who are unintentionally doing the wrong thing, not deliberately doing the wrong thing.
Has anyone else already explored this issue? If so, what were your conclusions?
Am 07.02.2018 um 21:56 schrieb James Ralston:
Our users have a tendency to install software that, per company policy, is not permitted to be installed. Most users have sudo privileges on their hosts, which is how they install the software.
I don't think there is a readymade AppLocker thing for linux. There is Linux IMA which maybe could be used to run only signed code.
https://lwn.net/Articles/733431/ http://linux-ima.sourceforge.net/
SELinux might support you by not giving users rights to install software at all. But If they don't have the rights to install software normally also implies they can't do what they need to. ;-)
Note that we *are not* trying to stop malicious users from deliberately installing software they know is forbidden. Our main problem is that our users typically don't bother to consult the "forbidden software" list before installing.
You could have a policy that only signed RPM's can be installed and implement monitoring of installed rpm gpg keys and verify all installed packages match a known signature.
There is some ugly looking rpm command to list rpm's with its signing key:
http://lists.rpm.org/pipermail/rpm-list/2011-December/001048.html
And an example command to list installed rpm gpg keys:
rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n'
- Thomas
On Wed, 2018-02-07 at 15:56 -0500, James Ralston wrote:
Our users have a tendency to install software that, per company policy, is not permitted to be installed. Most users have sudo privileges on their hosts, which is how they install the software.
In the Windows world, AppLocker can be used to restrict users from executing programs, by path, publisher, or hash.
Has anyone contemplating using SELinux to implement something similar to AppLocker, but for Linux?
One thought would be to roll a custom policy that creates a new type (say, forbidden_t), and then essentially prevent all access for that type. But this would not work unless we changed the default SELinux User for users from unconfined_u to user_r, and that has the potential to be very disruptive.
Even if we did this, it wouldn't permit us to blacklist by hash; it would be dependent on the path location.
We run Clam Antivirus on our hosts, so something we are thinking of doing is writing custom rules to flag the unwanted programs as malware. But unless we also used fanotify-based blocking with ClamAV, that wouldn't prevent users from executing the unwanted programs.
Note that we *are not* trying to stop malicious users from deliberately installing software they know is forbidden. Our main problem is that our users typically don't bother to consult the "forbidden software" list before installing. So we're attempting to catch users who are unintentionally doing the wrong thing, not deliberately doing the wrong thing.
Has anyone else already explored this issue? If so, what were your conclusions?
A slightly less disruptive change than changing from unconfined_u to user_u would be to change to staff_u. staff_u users are confined but not as restrictively as user_u, and they can newrole -r unconfined_r or sudo -r unconfined_r to switch to unconfined when they want to perform privileged actions.
Otherwise, I'd also refer to you to Linux IMA with digital signatures as a potential approach, although there remain non-trivial challenges to effectively deploying it.
selinux@lists.fedoraproject.org