Complete coverage in Linux security modules

The Linux Security Module (LSM) framework is intended to allow security modules to lock down a system by inserting checks whenever the kernel is about to do something interesting. A security module hooks into those check points and, for each operation, convinces itself that the operation is allowed by the security policy currently in force. This approach can work well if checks have been placed in all of the relevant locations. A missing check could open a door allowing a user-space process to do something which the site's policy would disallow.

Kostik Belousov recently noticed this sort of problem in the 2.6 kernel: it seems that the readv() and writev() system calls ran without calling the associated LSM hook. The missing check means that a process which uses these calls (rather than read() or write()) could perform file I/O which was not subject to oversight by any security modules currently loaded in the system. The practical effect of this vulnerability is minimal: any security module worth its bits will have done its access checks when the file is opened, so the ability to do unchecked reads and writes should not open any gaping holes in the system.

The more important point is how easily this sort of opening can come about. When the security modules patch was originally merged into the kernel, it included checks on readv() and writev(). But those system calls were later rewritten, and the LSM hooks fell by the wayside. This change apparently happened around 2.5.47, but it only came to light now.

Most kernel developers are only peripherally aware of the LSM system. Very few of them know how to code an LSM call, and the rules for the insertion of LSM checks are not particularly well documented. Code which is missing an LSM call still appears to work just fine in normal testing and use. The end result of all this is that it is trivially easy to omit an important check, or to delete one by accident. Such mistakes can then go unnoticed for years.

Anybody who depends on a Linux security module (such as SELinux) is depending on comprehensive checking within the kernel. But, as has been demonstrated here, it is hard to feel sure that the LSM checks are, indeed comprehensive. There are many code paths through the kernel. When a relatively simple system call can go unprotected for so long, how secure do we feel about the more complex paths? It would seem that a thorough audit is called for. An automated audit might even be better; it may well be possible to adapt a tool like sparse to detect unchecked paths through the kernel. Some work in this area could do a lot to increase the level of trust which can be placed in LSM-based modules.

Index entries for this article
Kernel	Modules/Security modules
Kernel	Security/Security modules

---

to post comments

Complete coverage in Linux security modules

Posted Oct 6, 2005 8:56 UTC (Thu) by dps (guest, #5725) [Link]

It might be worth looking at building the security controls "deeper" into the kernel. If read() and readv() both end up calling something and the security conrol could be placed there then it would be more resistant to implementation changes. Of course it might be than by then you have lost important context information, so that strategy will not work.

I could see possible value in restricting rewriting the boot block in the block layer. Doing this would cover mmap/msync, write, writev, asyncheonous I/O and anything else I might have missed. I am not volunteering do this right now.

file system security

Posted Oct 6, 2005 16:01 UTC (Thu) by ccyoung (guest, #16340) [Link]

(from last week's reading of Reiser) how much of this would be necessary if reiser's fs were in place, that is, security checking at the fs level vs the kernel (assuming /sys and kin were reiserfied).

1. it seems to me this is a much more straightforward approach, more modular and more flexable (esp with plugins).

2. how close would it come to being comprehensive?

Complete coverage in Linux security modules

Posted Oct 6, 2005 16:50 UTC (Thu) by cdmiller (guest, #2813) [Link]

Had to type this line for the post to work. Content:
K.I.S.S.

Complete coverage in Linux security modules

Posted Oct 6, 2005 20:13 UTC (Thu) by thoffman (guest, #3063) [Link] (1 responses)

Why are there not published regression tests which would catch this sort of thing immediately?

Surely the NSA and other SELinux developers have (or should have!) test sets which load a variety of different security modules, and then run multiple sequences of user programs which both verify that what should be allowed IS allowed, and what should not be allowed is not allowed.

It's really an embarrassment that any bug like this could be unnoticed for so long, I can't think of any excuse for it other than lack of motivation to really test the code.

Complete coverage in Linux security modules

Posted Oct 7, 2005 9:01 UTC (Fri) by liljencrantz (guest, #28458) [Link]

I'd be surprised if a comprehensive test suite doesn't exist. This particular bug wouldn't show up in such a test since before you read or write to a file, you need to open it. If the checks on open work, then the checks on readv/writev will never do anything interesting. The only reason for implementing them, as far as I can see, is to limit the damage done if someone finds a way to break the security checks on open.

Complete coverage in Linux security modules

Posted Oct 13, 2005 10:39 UTC (Thu) by kostikbel1 (guest, #33070) [Link]

I completely disagree that _any_ security module shall do the checks at the open time. One of the most interesting applications of LSM appears when process permissions are based on the process behaviour profile. It is when developing such module, the hole was found. BTW, look for new one involving AIO.

Overall, I have a strong fill that LSM is considered to have only one user, namely SELinux. This is the real cause of reported omission, due to SELinux does not support relabeling.