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 mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
