Crispin Cowan wrote:
I know, replying to my own post is lame. But I'm actyally replying to Wagner's post,
which I quoted here from another forum, so gimmie a break :-)
> David Wagner wrote:
> > - 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?
I agree with David, that interposition (doing more than purely refusing some requests,
i.e. changing the request arguments, requestor's state, etc.) is a desirable feature.
I also agree with Linus, that it should not be a special case: the module interface
should export enough stuff that various interposition hacks can be employed as a matter
of course.
> > - 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?
There is extensive security theory that shows that composition of security policies
does not generalize [McCullough 1988, Gligor 1998
http://www.glue.umd.edu/~gligor/cambridge98.ps ,
http://www.glue.umd.edu/afs/glue.umd.edu/home/enee/faculty/gligor/pub/oak98.ps ]. On
the other hand, there are lots of cases where one would want to use more than one
security policy:
* Immunix, by design, has separate modules for separate aspects. SubDomain does
file system access control, while CryptoMark ensures that executables are
cryptographically signed.
* We want to port the POSIX.1e to be a security module. Yet most security modules
are going to want to work in conjunction with Privs. For Immunix, we have
specifically avoided implementing functionality that is already present in Privs;
we need it.
So I propose that *cooperating* modules should be supported, and that we should make it
easy to cooperate with the Privs module.
> > - 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?
I regard this as the largest question in the linux-security-module design. My take on
the question is that the list of objects to hook should be as small as possible, and as
big as it needs to be. So we should only add hooks to an object if:
* some security extension needs it
* a convincing argument can be made that there is no other way but to add that hook
> > (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?
We're in the middle of doing that for SubDomain, although we're not using the ip*
family to do it.
> This would allow us
> > to specify policies regarding usage of network resources without
> > an inventing a new little language.
Oops; we went and invented a new little language :-)
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:20 PDT