On Don, 19 Apr 2001 Steve Beattie wrote: > [reformatting for my sanity] > > On Thu, Apr 19, 2001 at 11:42:49AM +0000, buddy wrote: > > As an example, needing root privileges in order to (un)load modules > > doesn't make me feel any safer, but apparently I'm more paranoid than > > you are. ;-) I'm worried about all those people relying on their LKM > > notifying them of a root compromise, and being owned all the same. > > So we're in agreement that providing LSMs with the ability to mediate > the mechanisms for module (un)loading is necessary. I'm aware of three > different mechanisms for doing so, that we must provide hooks for: > > -- the (init|create|delete)_module() syscalls Essential and easy. > -- modifying /dev/(k)mem directly (which works even if you've > compiled out support for loadable modules in your kernel, BTW). > Thus we need to mediate file system accesses (so that an LSM > can restrict access to /dev/mem) and in sys_mknod (so that > an LSM can restrict the ability to create a character device > that is equivalent to /dev/(k)mem). Let's not provide device protection via special files, but rather via device numbers. How can you ensure that e.g. no fs is mounted with such a special file? I have good experience with using device numbers and types (block/char) as identification. /dev/(k)mem interception can easily be done in drivers/char/mem.c:open_opert(), without the special files pain. Also, please do not forget /proc/kcore! > -- other filesystem tricks that involve installing a non-LSM > enabled kernel or deleting your LSM module that proper > filesystem mediation should give the LSM module the ability > to prevent. Except for the boot process, this is mostly file protection via standard access control. > This level of mediation could certainly be insufficient for stopping such > an attack; if so, please outline for the list why it is insufficient > and (if possible) suggest ways to prevent such things. The important > thing is to provide a security model the means (via mediation hooks) to > prevent such an attack, NOT guarantee that the model actually does so. > As examples, requiring root privs or CAP_SYS_ADMIN to (un)load are > security models that likely won't prevent such an attack -- but that's > a weakness of those models, and hopefully not of the framework that this > list produces. The mechanism must support this control. How it is done is the module policy's problem. Amon. _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Apr 20 2001 - 01:41:05 PDT