[PATCH] LSM: SafeSetID: add selftest

Micah Morton mortonm at chromium.org
Thu Feb 7 21:54:56 UTC 2019


Yeah, that would be simple, although maybe someone is counting on
those users to exist later. We could create special users on the
system for the purpose of this test that didn't exist before the test
(and delete them afterward), but then there are other setup/cleanup
questions, like:

- Do we unmount securityfs after the test? What if something was
counting on it being mounted or not mounted?
- Do we flush the SafeSetID LSM policies after the test? Note that the
LSM doesn't currently have the functionality to flush individual
policies, so what happens if something was counting on certain
policies (for other users) being configured for the LSM and we flush
those after running our test?

These questions were the reason I was hoping to get more info on the
kind of environment in which these selftests run. If the norm is to
boot up a VM, run one of these tests, then reboot/shutdown, most of
these questions don't need to be answered (we would still probably
want to fix user creation/deletion since that is persistent across
reboots).

On Wed, Feb 6, 2019 at 11:26 AM Edwin Zimmerman <edwin at 211mainstreet.net> wrote:
>
> > On Wednesday, February 06, 2019 2:03 PM Micah Morton wrote:
> > > This patch adds a selftest for the SafeSetID LSM. The test requires
> > > mounting securityfs if it isn't mounted, creating test users in
> > > /etc/passwd, and configuring policies for the SafeSetID LSM through
> > > writes to securityfs.
> > >
> > > Signed-off-by: Micah Morton <mortonm at chromium.org>
> > > ---
> > > This test is reasonably robust for demonstrating the functionality of
> > > the LSM, but is no masterpiece by any means. I'm not totally sure how
> > > these tests are used. Are they incorporated into testing frameworks for
> > > the Linux kernel that are run regularly or just PoC binaries that sit in
> > > this directory more or less as documentation? If its the former, this
> > > code probably needs some more cleanup and better organization. Beyond
> > > coding style, the test doesn't bother to clean up users that were added
> > > in /etc/passwd for testing purposes nor flushes policies that were
> > > configured for the LSM relating to those users. Should it?
> >
> > No good reason to leave the users, so I would suggest cleaning them up.
> > All it would take would be several deluser commands
> > in safesetid-test.sh.  Very simple.
>



More information about the Linux-security-module-archive mailing list