[PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks

[Sargun Dhillon]

On Thu, Apr 5, 2018 at 9:29 AM, Casey Schaufler <casey at schaufler-ca.com> wrote:
>
> On 4/5/2018 3:31 AM, Peter Dolding wrote:
> > On Thu, Apr 5, 2018 at 7:55 PM, Igor Stoppa <igor.stoppa at huawei.com> wrote:
> >> On 01/04/18 08:41, Sargun Dhillon wrote:
> >>> The biggest security benefit of this patchset is the introduction of
> >>> read-only hooks, even if some security modules have mutable hooks.
> >>> Currently, if you have any LSMs with mutable hooks it will render all heads, and
> >>> list nodes mutable. These are a prime place to attack, because being able to
> >>> manipulate those hooks is a way to bypass all LSMs easily, and to create a
> >>> persistent, covert channel to intercept nearly all calls.
> >>>
> >>>
> >>> If LSMs have a model to be unloaded, or are compled as modules, they should mark
> >>> themselves mutable at compile time, and use the LSM_HOOK_INIT_MUTABLE macro
> >>> instead of the LSM_HOOK_INIT macro, so their hooks are on the mutable
> >>> chain.
> >>
> >> I'd rather consider these types of hooks:
> >>
> >> A) hooks that are either const or marked as RO after init
> >>
> >> B) hooks that are writable for a short time, long enough to load
> >> additional, non built-in modules, but then get locked down
> >> I provided an example some time ago [1]
> >>
> >> C) hooks that are unloadable (and therefore always attackable?)
> >>
> >> Maybe type-A could be dropped and used only as type-B, if it's
> >> acceptable that type-A hooks are vulnerable before lock-down of type-B
> >> hooks.
> >>
> >> I have some doubts about the usefulness of type-C, though.
> >> The benefit I see htat it brings is that it avoids having to reboot when
> >> a mutable LSM is changed, at the price of leaving it attackable.
> >>
> >> Do you have any specific case in mind where this trade-off would be
> >> acceptable?
> >>
> > A useful case for loadable/unloadable LSM is development automate QA.
> >
> > So you have built a new program and you you want to test it against a
> > list of different LSM configurations without having to reboot the
> > system.  So a run testsuite with LSM off  then enabled LSM1 run
> > testsuite again disable LSM1 enable LSM2. run testsuite disable
> > LSM2... Basically repeating process.
> >
> > I would say normal production machines being able to swap LSM like
> > this does not have much use.
> >
> > Sometimes for productivity it makes sense to be able to breach
> > security.   The fact you need to test with LSM disabled to know if any
> > of the defects you are seeing is LSM configuration related that
> > instance is already in the camp of non secure anyhow..
> >
> > There is a shade of grey between something being a security hazard and
> > something being a useful feature.
>
> If the only value of a feature is development I strongly
> advocate against it. The number of times I've seen things
> completely messed up because it makes development easier
> is astonishing. If you have to enable something dangerous
> just for testing you have to wonder about the testing.
>
>
[Sorry for the double post]
So, first, this gives us a security benefit for LSMs which do not have
unloadable hooks. For those, they will always be able to load at
boot-time, and get protected hooks. Given that we can't really remove
security_delete_hooks until this SELinux removes their dependency on
it, I'm not sure we that this happy accident of safe (un)loading
should be sacrificed.

I think having LSMs that are loadable after boot is extremely
valuable. In our specific use case, we've wanted to implement specific
security policies which are not capable of being implemented on the
traditional LSMs. We have the capability of deploying a Linux Kernel
Module throughout our fleet. Recent examples include issues with
specific networking address families, IPTables (over netlink API).
It's not easy to block out RDS across the system while it's running,
even if seccomp can do it.

We have other use cases -- like being able to run systemd in
unprivileged user namespaces. This comes at the cost of giving the
container CAP_SYS_ADMIN. We want to be able to give PID 1 in the user
namespace CAP_SYS_ADMIN, but we want to revoke these capbilities
across execve, without having to control the user's installation of
systemd in their container.

Other times, it's about performance. There is a measureable overhead
with seccomp, and apparmor. LSMs fit better for doing some of the
filtering we're forced to do in seccomp, or apparmor for containers.
The performance gain by implementing purpose-built policies in custom
LSMs is significant.

My suggestion is to change security_delete_hooks() to return -EPERM by
default. Hook unloading can then be disabled by a Kconfig feature. If
we need to get "more secure", we can disable unloading via cmdline, or
proc / securityfs at boot time.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html