In my previous post, I presented two quotes from Linus. The second quote is actually a reply to this post by David Wagner, one of the authors of the Janus security enhancement for Solaris and Linux. It offers some interesting perspectives on what facilities the security module interface needs. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org ------------------------------------------------------------------------ David Wagner wrote: > > I would, for example, be willing to entertain the notion of having a > > (global or per-process or whatever) pointer to a "security checks" > > structure: > > > > struct security_checks_struct { > > int (*execve)(struct task_struct *tsk,struct binprm *new); > > int (*file_open)(struct file *); > > int (*raise_capability)(... > > ... > > ... selinux had about 140 points they wanted to hook into .. > > ... others probably have a few more. > > ... > > }; > > > > and then just have a opaque per-security-model security ID thing scattered > > around in critical places (the obvious being the thread structure, files, > > directory cache, inodes, etc). And instead of having _any_ policy at all, > > the kernel would just call the security procedure. Which might choose to > > fail (-EFASCIST) or might choose to return success but silently downgrade > > the security of the process that does the action, or whatever. > > Great! I'm persuaded: I like it, a lot. After spending a good > deal of time on Janus (http://www.cs.berkeley.edu/~daw/janus/), > a sandboxing tool based on system call interposition, I've become > thoroughly convinced of the power of interposition and the need > for support in the kernel for extensible security mechanisms. > I find Linus's suggested direction very promising. > > Let me suggest a few design issues for consideration: > > - State. > My experience is that pure interposition is not enough for > many policies: security extensions often need ability to add > per-process state, or per-inode state, etc., as well as hooks > to be called whenever a kernel object of the desired type > (process, inode, ...) is created or destroyed. Should this > be supported, and if so, how? > > - Passive vs. active filtering. > Passive filters ("reference monitors") just get to inspect > a request and allow or deny it. Active interposers (think of > "firewall proxies") can modify the request (canonicalization, etc.). > The latter is potentially more powerful; should it be supported? > > - Composition of policies. > How are policy extensions combined? Can we have wuftpd restricted > according to SELinux policy, sendmail according to Janus policy, and > Apache controlled by the restrictions of both SELinux and Janus? > Must extensions be a conservative refinement of existing Unix > permissions, or can an extension policy engine allow a request > that existing Unix permissions would disallow? How do multiple > multiple extensions play nicely with each other? > > - What to interpose on? > Here are a few suggestions for possibilities: interposition on all > system calls; interposition on all VFS calls; on sockets. What else? > (By the way, in Linux today, it's already hard even to do just syscall > interposition cleanly [1], let alone more interesting cases, so a > mechanism like the one Linus suggested would be a nice step forward.) > Can we extend ipfirewalling/ipchains/iptables to allow firewalling > rules to be specified on a per-process basis? This would allow us > to specify policies regarding usage of network resources without > an inventing a new little language. > > Also, let me refer the interested reader to the archives of the GACI > mailing list (http://www.compuniverse.de/lwgate/GACI/archives/), > which is devoted to discussion on this direction. Several messages > contain some detailed proposals on relevant events that could use > hooks as proposed by Linus. See, e.g., > http://www.compuniverse.de/lwgate/GACI/archives/gaci.2000/Subject/article-8.html > http://www.compuniverse.de/lwgate/GACI/archives/gaci.2000/Subject/article-35.html > > Regards, > -- David Wagner > > > [1] A few examples of woes of syscall interposition in today's Linux kernel: > - sys_execve() reads up into its caller's stack frame. As a consequence, > inserting a wrapper around sys_exeve() breaks things, so you have to > cut-and-paste code from arch/i386/kernel/process.c (non-portable!); > - there's no way to lock the syscall table, so it's not obvious to me > how to insert/delete a hook on a syscall in a SMP-safe way; > - the lack of a general interface for copying args to kernelspace > means that the interposition agent has to duplicate a lot of code > for unmarshalling syscall arguments.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:15:20 PDT