"Anil B. Somayaji" wrote:
> Hello everyone! My name is Anil Somayaji, and as some of you know
> (and most of you probably don't), for the past few years I've been
> doing research on how short sequences of system calls can be used to
> differentiate between normal and abnormal program behavior.
IMHO, two important factors contribute to Linux's success:
* Linux doesn't do any research: what gets implemented in the Linux mainline
is not far-out research ideas, but rather really well-founded, tried&true
techniques. This makes Linux stable, fast, and compatible with other
UNIXies.
* Linux, being open source, enables lots of great research. Before 1995,
many OS research papers said "we did this cool hack to our source copy of
fooNIX, but it's under NDA, so we can't share." Now, most OS research
papers say "we hacked this idea into Linux, here's the URL for the source."
In that spirit, I would like to avoid turning linux-security-modules into a
research chat forum (which is hard, because I like research chat :-) and instead
keep it focused on producing working code that Linus will actually accept.
Linus has already told us what he will accept and what he will resist accepting,
and I think it would be interesting to see how far we can get under those
restrictions.
We (WireX) hope to have a a rough cut implementation out in a few days that will
support a POSIX.1e module and our SubDomain module. From there, the really
interesting questions are:
* What other security modules can this (conceivably) support?
* What changes could be made to the interface to expand the set of
supported/supportable modules, without violating Linus' constraints?
* What changes can be made to the modules to make them fit the constraints?
* Finally, when push comes to shove, what (few) changes can we try to
convince Linus to accept to expand the set of supportable modules?
> Light system calls are good, indeed. I sorry to say that my
> modifications have killed system call latency (but because system
> calls in Linux are so lightweight, nobody seems to notice). However,
> I also know that security costs something, and if you want to minimize
> those costs, it is best to do actions at the right place, and at the
> right time.
I think what Linus is getting at is that the existence of the security module
interface should not inherently add any perceptible latency. This way, the base
user doesn't suffer (much) overhead, and users can make a choice about the
performance penalty they are willing to pay for security.
> If you want to mess with system calls, you should mess
> with them in kernel-space - anywhere else is either too expensive,
> insecure, or both.
I don't actually see a performance issue with hooking at the syscall interface.
And in fact, you can already hook syscalls by reloading the system call table.
The catch is that you don't have much context when you hook at the system call
level, i.e. you know the arguments to (say) open, but you don't know anything
about the inode number that it will resolve to after it gets through namei.
This is exactly the quandary that SubDomain and LOMAC faced. SubDomain "solved"
it by punting and going with a kernel patch. LOMAC solved it by re-implementing
parts of the kernel in their module. The security LKM is supposed to relieve
security modules from having to use either of these sub-optimal solutions.
> I actually do believe that sometimes you do care that a program is
> writing to /dev/null - especially if that program normally writes to a
> log file! But really, what it comes down to is that many people have
> proposed and tested effective security mechanisms that work at the
> system-call level.
True, but couldn't that be detected through a hook deep down in open? What just
cannot be mediated with hooks in open? Quick answer: processes share file
descriptors, so you also have to mediate read and write. But what else?
> So, while I like the general idea of interposing on system calls, I
> see lots of problems with doing it in practice. I'm curious - what do
> other people actually want to do to system calls? How much info is
> needed? Maybe we can't have a really flexible API, but maybe we can
> have one that does 90% of the job for 10% of the effort and 1% of the
> slowdown.
That's the goal.
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution: http://immunix.org
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:15:22 PDT