implementing AppLocker-like functionality with SELinux?

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

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?

[Thomas Mueller]

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

[Stephen Smalley]

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.