linux-kernel - static LSM objection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 12 Oct 2007 14:42:27 -0700
From:	Kees Cook <kees@...ntu.com>
To:	linux-kernel@...r.kernel.org
Subject: static LSM objection

Hi,

I just wanted to voice my opinion about the static LSM changes.
(I apologize about being late[1] to the discussion[2] -- I'd only recently
become aware of it.)  I'm personally really against this.  For example,
I want to give people choice about their security protections in Ubuntu,
and I'd like to let them pick the MAC that suits their needs.

Some people want SELinux, some people want AppArmor.  (Yes, I know
AppArmor isn't in mainline yet, but it does seem they're getting closer --
three distros are shipping AppArmor.  The static changes feel motivated
by political rather than technical reason -- though it of course have
technical merit.)  Considering things like SMACK and TOMOYO, it is going
to be very troublesome for distros to have to start building multiple
kernels to support each given MAC that their users want to use.

So, unless this is just re-hashing and you can point me to discussion
points I missed, can someone help me understand the technical issues
around this change?  It sounds like the primary reason for making it
non-modular is performance loss due to call overhead.  Aren't there
other ways to solve this without removing the boot-time module choice?
(Make it unloadable?)

I'm not convinced that the advantages of making it static out-weigh the
benefit of having it as a choice at boot-time.  (I don't really mind
needing a reboot to switch MAC implementations, as long as there is some
benefit from making them unloadable, though it sounds like there are
people would are against making LSMs unloadable too.)

Thanks,

-Kees

/me pops the safety off his fire extinguisher

[1] http://lkml.org/lkml/2007/7/19/228
[2] http://lkml.org/lkml/2007/7/14/91

-- 
Kees Cook
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/