LSM talk

riel
ok, time to start, I guess
riel
I will now make this channel moderated
riel
meaning that the audience cannot speak here
riel
instead, if you have a question, please ask it in the channel #qc
riel
ok, I'll be introducing today's lecture
riel
well, today's evening lecture, David had another lecture earlier today ;)
riel
this lecture will be about a framework for a more flexible security infrastructure in Linux
riel
more flexible security is a good thing, for various reasons
riel
for one, on large server systems the traditional user - group - other security is a pain to manage for eg. the anonymous CVS user
riel
today's lecture will be given by Chris Wright and Seth Arnold from WireX Communications
riel
they are developing the Linux Security Module (LSM) framework
cdub
heh, is that our queue? ;-)
riel
as for an introduction about them, they have told me nothing special would be needed, since "<cdub> heh, sarnold's cunning intelect and smashing good looks speak for themselves ;-)"
riel
so I guess I'll turn over the channel to cdub and sarnold
cdub
thanks riel ;-)
sarnold
thank you riel for introducing us, and thanks also to uninet.edu for providing a forum for a lecture series
riel
oh, and if you have a question ... feel free to ask it in #qc
cdub
<rsd:#qc> is LSM somewhat related to NSA work on security for Linux?
cdub
heh, we'll start off with some history, and you should see the analogy
cdub
yes, thanks.  and also, thanks to all who are attending.
cdub
alright...
cdub
starting with the linux 2.5 kernel summit.
cdub
the NSA gave a presentation aobut SELinux and the security framework they had in the kernel.
cdub
to make a long story short, linus and others agreed that linux needed advanced security
cdub
however, linus really wanted something flexible.
cdub
he did not want to accept one security project at the cost of turning another away.
cdub
this basically started the LSM project.
cdub
we started trying to define an abstract framework to allow a variet of security policies to be implemented in the kernel
cdub
without having to continue patching for every project.
cdub
the first important question we faced was how do we want to interpose our framework
cdub
there were many people in favor of a strict syscall interpostition
cdub
we eventually chose to leave the syscall boundary alone
cdub
(which was good, as linus advised us against it)
cdub
instead we chose to view each kernel object that was accessible to user space as something that needs protection
cdub
the state-of-the-art in the present kernel allows for basic mode bit tests (super user test) and capabilities tests (which typically amount to a super user test)
cdub
so we started by trying to create a framework that would support the current access control system in the kernel
cdub
the problem with the syscall boundary is that it is far away from where the 'action' is taking place.
cdub
there is user data that needs to be copied into kernel, there are kernel objects that need to be looked up, etc.
cdub
so by focusing on the kernel objects themselves, like inode, file, task_struct, etc, we feel we can get best access control coverage
cdub
by looking at the placement of the existing capable() and suser() checks we saw that this approach was not too far off from where the kernel presently is.
cdub
so we began defining a structure of callbacks that represents all the kernel objects, and all the actions that users can do the manipulate the kernel object
cdub
the lsm code itself that is in the kernel is a series of hooks that protects access to the kernel objects
cdub
these hooks execute the callbacks, which call into module specific code
cdub
one critical idea here is
cdub
separate _policy_ from _mechanism_
cdub
we want to make the framework as security policy agnostic as possible, and push _all_ policy decisions into the security module.
cdub
the current security policies in the kernel are bascially DAC (discetionary access control)
cdub
but there are many other types of security policies, like MAC, DTE, etc...
cdub
one important feature missing in DAC is the ability to do object specific labelling
cdub
acme:#qc> like the netfilter infrastructure?
sarnold
as far as I understand netfilter :) yes, very similar to the netfilter infrastructure
cdub
yes, just like that ;-)
cdub
so part of the access control framework supports object labelling
cdub
this means we've added a new member to all these kernel objects...
cdub
something we affectionately call, the opaque security blob
cdub
so, in addition to providing access control hooks, we provide the necessary allocation/deallocation hooks for these policy sepcific opaque security blobs (read: void * ;-)
cdub
then, the security module can use these labels as part of the access control criteria when chosing whether to allow access or not.
cdub
that's the high level overview of LSM
cdub
perhaps we should field some questinos before we move on
cdub
<velco:#qc> blob ? like Binary Large OBject ? large 
cdub
these are just void *, the security module can place whatever it likes there
cdub
acme:#qc> what other uses do you envision when this infrastructure (i.e. the hooks) are in place? resource control (i.e. kinda like userbeans)?
sarnold
< acme:#qc> what other uses do you envision when this infrastructure (i.e. the hooks) are in place? resource control (i.e. kinda like userbeans)?
cdub
hehe
cdub
go ahead sarnold ;-)
sarnold
I'm sorry to say that I do not know what userbeans are off the top of my head; however, the hooks are placed in fairly convenient locations .. I imagine there are probably many possible uses..
sarnold
some quick and dirty thoughts that come to mind are features such as BSD's portal filesystem, or directory watchers..
cdub
acme, one of the things we have tried to do, is resist a generic hooking scheme...so the hooks are specific to access control
sarnold
< acme:#qc> userbeans: is user quotas for kernel resources, Andrey Savochkin did it and Marcelo Tosatti worked a bit on it in the past
sarnold
how very cool :)
cdub
sure, sounds like something that could be implemented in an LSM.
sarnold
I imagine that a security module could also take a whack at implementing resource limits through the LSM interface
cdub
since LSM has hooks to control object creation, etc...
cdub
<acme:#qc> kinda like inode->u.generic_ip, netdevice->private, struct sock->protinfo.destruct_hook (yes, I'm overloading the thing) 8)
cdub
yes, we have inode->i_security, etc. and these hold module specific object labels.
cdub
any other questions before we move on?
cdub
sarnold, anything you'd like to add?
cdub
riel:#qc> will it be possible to use multiple security modules at the same time ?
sarnold
13:30 < riel:#qc> will it be possible to use multiple security modules at the same time ?
cdub
hehe, how about you hold on just a sec on that one ;-)
cdub
i was going to cover that next
cdub
alright...
cdub
now that we've looked at the high level framework, let's take a look at some of the details.
cdub
the callbacks are all in one stucture, security_operations.
cdub
when the module is initialized, either at load time, or during init_calls if it's complied in to kernel
cdub
it needs to initializ this security_ops
cdub
this is done via a standard, register_security type interface
cdub
and one of the first things we hit was
cdub
how to possibly stack security modules with this interface
cdub
(and don't forget each module is storing it's own opaque label in the kernel object)
cdub
linus has strong opinions on this, as do many people in the security field
cdub
linus says effectively, do not compose security policies
cdub
security research says, that in general, security policies do not compose
cdub
we decided to take a middle ground here.
cdub
one important thing to note is that the super user and capabilities checks are done against data in the task_struct directly
cdub
so it should be "trivial" to compose an arbitrary security policy with the superuser or capability module, since they don't directly step on each other's toes (via the opaque pointer)
cdub
the only problem now, is the kernel interface (the callback structure)
cdub
so we have the notion of a primary module.  this is the one that first calls register_security
cdub
all subsequent modules register not with the kernel, but with the primary module itself
cdub
this allows the kernel to be clueless about module stacking
cdub
and forces the modules that are stacking with each other to explicitly allow such behaviour
cdub
this way, we think that while arbitrary composition of security policies may be an intractable problem
cdub
compostion of some know policies can be done easily
cdub
we have considered creating a basic composition module
cdub
that just allows you to register multiple modules, and basically && or || the results, but such a module does not exist right now.
cdub
so to recap, module stacking is supported, but we tried to make the kernel unaware, so the stacking mechanism is not fully generic.
cdub
another key issue that we hit was what exactly does a hook look like?
cdub
does the hook give authoritative access to an object, or just simply restrictive access to an object.
cdub
this makes most sense when you consider what the kernel code looks like.
cdub
<riel:#qc> cdub: mmmm, something like ACLs would combine well with something like vserver  (virtual servers in one machine)
cdub
yes, i think so, however, we still have a few other issues to iron out with vserver, that i'll get to shortly.
cdub
kernel code often looks like this:
cdub
if (uids != match && !(capable()) goto failed;
cdub
do_action()
cdub
with LSM it looks similar:
cdub
if (uids != match && !(capable()) goto failed;
cdub
if (security_ops->do_action()) goto failed;
cdub
do_action();
cdub
so we have a problem that we may want to override access to some object for some subject
cdub
the security hook there is only going to restrict access granted by the in-kernel logic
cdub
we have argued about this very point quite a bit, and decided to make a compromise...
cdub
we have a hook in the capable() function, so that fucntion can override (this is the behaviour of 'standard' POSIX.1e capabilities)
cdub
the compromise is that, the capable function gets very little context.  just a 32 bit vector CAP_SYS_ADMIN, etc...
cdub
so while we can restrict access to objects on a very fine granularity
cdub
(the restrictive interfaces may have many arguments to the callback, inode, dentry, etc.)
cdub
we can only override access control on a coarse granularity (32bit vector)
cdub
we chose this compromise because it enables the most security modules, with the smallest amount of changes in the kernel.
cdub
alright, now the vserver problem...
cdub
vserver is a project to allow multiple virtual servers to run in isolated security contexts
cdub
we can support most of what vserver would like to do, with two exceptions:
cdub
1) vserver directly touches scheduler code, something we never intend to do...hopefully more modular scheduler designs will offload this from us ;-)
cdub
2) vserver returns data to the user based on the users context
cdub
we can restrict access to the data based on the context, but we can not return context specific data in call syscall paths.
cdub
this is something that we can work on as we improve the LSM framework.
cdub
oh, i forgot to mention, LSM is targeting 2.5 for mainline acceptance...
sarnold
(as a specific example, vserver can return different uname information to different security contexts..)
cdub
yes, thanks sarnold ;-)
cdub
(we can acutally handle that one, but some of the others we can't, sorry can't remember which right now)
cdub
another problem we've had should hopefully be solved for us by the VFS changes anticipated in 2.5
cdub
some security policies would like to make access control decisions based on file name, while others based on inode number.
cdub
the security_ops framework mirrors the inode_operations
cdub
so just before the filesystem is called to do something, we check if it's ok
cdub
<maluco:#qc> cdub : like LIDS do?
cdub
you mean filenames?
cdub
yes, exactly ;-)
cdub
some argue that filenames aren't sufficient, since you are really trying to protect the inode, but that's a matter for security policy wars ;-)
cdub
we try to be agnostic, so we hope to support projects like LIDS.
cdub
since our hooks mirror the inode_operations, we take the same arguements.
cdub
for those that have tried, you can't reliably build a pathname from an inode alone.  you really need both the dentry and the vfsmount
cdub
luckily, al viro plans on chaning the filesystem interface, so we anticipate this functionality Real Soon Now (TM) ;-)
cdub
whew, that's a lot of info...perhaps we should break for some more questions....
cdub
heh, alright then, no more rest for my typing hand ;-)
cdub
so where are we now?
cdub
we have implemented the full framework
cdub
and we have implemented modules that use the framework, namely superuser and capabilities.
cdub
in addition, from the lsm community at large, we have a DTE module, an SELInux module, and a module that implements much of the Openwall kernel patch.
cdub
we are closely tracking 2.5 development, and hope to propose lsm sometime after the VFS changes are done.
cdub
i haven't mentioned a whole lot about the network part of LSM.
cdub
it draws largely from netfilter, and only adds what's missing for complete coverage.
cdub
so part of the LSM interface is a series of netfilter hooks.
cdub
we do not want to re-invent the wheel afterall ;-)
cdub
ah, yes, and of course, we are tracking the extended attributes and ACL development, as EA makes enables a lot of labeling to be done without having to use a backing file for a attribute database
cdub
<acme:#qc> cdub:  using the netfilter existing infrastructure for the network parts of LSM is a nice thing
cdub
yes, i agree ;-)
cdub
<acme:#qc> cdub:  but by doing that you're extending a network specific infrastructure and going toward a more generic infrastruture ;)
cdub
well, that's one way to look at it ;-)  when it came to LSM network supoort it was obvious that we needed to leverage netfilter.
cdub
so, i think of netfilter as extending LSM ;-)
cdub
heheh
cdub
s/extending/enhancing
cdub
<acme:#qc> so netfilter, LSM, EA, userbeans, etc could be a big generic hook infrastructure 8)
cdub
indeed, and this is where we walk a fine line.
cdub
for example, the LTT project came to us when we first started and suggested we use LTT as the beginning of LSM
cdub
and this is exactly what we don't want.
cdub
so we try to keep focused on security and access control
cdub
<acme:#qc> but there are common parts and this is where all the projects can benefit
cdub
yes, i agree, we don't plan to solve all the problems, but just as we've used netfilter, others can use us to enable there needs.
cdub
for example, we do not support full audit
cdub
this has high kernel intrusion
cdub
but, people who care about audit have a lot of there work done for them by LSM
cdub
<velco:#qc> is LSM concerned with authentication ? where does it get credentials (and veryfier). or it is outside the scope of LSM ?
cdub
this we consider a policy that would be enforced by a module., so LSM core does not care.
cdub
LSM hooks things like fork and exec for example
cdub
so during this time the module may set the tasks credentials.
cdub
<hensema:#qc> I've recently read in some interview that the Hurd is able to  run a process without a user concext, eg. without rights. This would enable a ftp server to run without rights (as apposed to running as root on Unix) until a user is logged in. Would something like this be implementable using LSM?
cdub
yes, and in fact, judicious use of capabilities would allow this on linux already i think.
sarnold
14:18 < Jae:#qc> which modules are already available ?
cdub
but LSM can enable you to give your ftp server just the rights it needs to do it's job, and no more ;-)
cdub
DTE, SELinux, Openwall, capability, superuser are the modules available right now.
sarnold
there are currently the root=god module, POSIX1.e capabilities, a domain and type enforcement module, the SELinux module, many pieces of Solar Designer's Openwall module ..
cdub
SELinux is itself in infrastructure that allows multiple policies (MAC, etc.) so there is quite a bit available now.
cdub
LIDS people said they would like to port when LSM stableizes
cdub
and i have a partially functional vserver module
cdub
and, we are accepting patches and modules ;-)
cdub
ah yes, and i believe Janus has plans to use LSM
cdub
sarnold, do you have anything to add?  what have i forgotten? ;-)
sarnold
(note that we don't intend to try to get the various LSM modules accepted into 2.5 mainline along with LSM .. we keep them in a source repository along with LSM mainly for convenience and helping to keep them up to date...)
sarnold
hmm
sarnold
an additional thought .. riel was asking about composing ACLs and vserver
sarnold
and, perhaps this is a great example of why generic modules don't automatically compose well
sarnold
for example, the ACLs could be implemented entirely 'within' the vserver's context, providing an additional level of mandatory access control through vserver
sarnold
however, the ACLs could also be implemented outside the vserver framework, to allow more fine-grained sharing between the vservers
sarnold
two perfectly legitimate security policies come from slightly different perspectives of composing two (fairly straight-forward looking) modules
sarnold
are there any other questions?
cdub
some project details...
cdub
you can find patches at lsm.immunix.org
riel
ok, it seems pretty quiet now
sarnold
(oh yes, for those of you wondering about 'LTT' from above: http://www.opersys.com/LTT/)
cdub
we have a mailing list...
cdub
http://mail.wirex.com/mailman/listinfo/linux-security-module
cdub
and we hang out on irc.openprojects.net #lsm-dev
cdub
<wli:#qc> Is it within the scope of LSM design to counteract covert communication channels?
cdub
ahh, good question.
cdub
not completely, as this is a losing battle.
cdub
yes, and i/o seek times, etc..
cdub
we do not have the ability to close all covert channels
cdub
but there are many LSM hooks that help you cover many cases.
cdub
kind of a bland answer, but covert channels are very tough...
riel
ok, thanks to cdub and sarnold for this nice lecture
riel
in 30 minutes there will be another lecture
riel
by  Raúl Eduardo Millán Villalaz, about Viabilidad economica y técnica de Linux en el Escritorio de Trabajo
riel
that lecture will be in spanish, but maybe there will be a translation in #redes
riel
cdub, sarnold:  THANK YOU 
fernando
plas plas plas plas plas plas plas plas plas plas plas plas plas
fernando
plas plas plas plas plas plas plas plas plas plas plas plas plas
riel
clap clap clap clap clap clap clap clap
riel
clap clap clap clap clap clap clap clap
riel
clap clap clap clap clap clap clap clap
fernando
plas plas plas plas plas plas plas plas plas plas plas plas plas
riel
clap clap clap clap clap clap clap clap
riel
clap clap clap clap clap clap clap clap
fernando
plas plas plas plas plas plas plas plas plas plas plas plas plas
fernando
plas plas plas plas plas plas plas plas plas plas plas plas plas
MJesus
clap clap clap clap clap clap clap clap clap clap
wli
heh
MJesus
clap clap clap clap clap clap clap clap clap clap
MJesus
clap clap clap clap clap clap clap clap clap clap
hensema
Thanks, cdub en sarnold. Very nice
FloodeR
splas splas splas
FloodeR
splas splas splas
FloodeR
splas splas splas
JALH
clap clap clap clap clap clap clap
JALH
clap clap clap clap clap clap clap
MJesus
clap clap clap clap clap clap clap clap clap clap
MJesus
clap clap clap clap clap clap clap clap clap clap
MJesus
clap clap clap clap clap clap clap clap clap clap
FloodeR
chop chop chop
FloodeR
chop chop chop
MJesus
clap clap clap clap clap clap clap clap clap clap
E-D-W-I-N
plas plas plas plas plas plas plas plas plas plas plas plas plas
E-D-W-I-N
plas plas plas plas plas plas plas plas plas plas plas plas plas
E-D-W-I-N
plas plas plas plas plas plas plas plas plas plas plas plas plas
E-D-W-I-N
plas plas plas plas plas plas plas plas plas plas plas plas plas
*** dmc has left #linux
fernando
plas plas plas plas plas plas plas plas plas plas plas plas plas
E-D-W-I-N
plas plas plas plas plas plas plas plas plas plas plas plas plas
MJesus
clap clap clap clap clap clap clap clap clap clap
fernando
plas plas plas plas plas plas plas plas plas plas plas plas plas
E-D-W-I-N
plas plas plas plas plas plas plas plas plas plas plas plas plas
E-D-W-I-N
plas plas plas plas plas plas plas plas plas plas plas plas plas
MJesus
clap clap clap clap clap clap clap clap clap clap
fernando
plas plas plas plas plas plas plas plas plas plas plas plas plas
*** joseph has left #linux
dardhal
sarnold: great work
E-D-W-I-N
plas plas plas plas plas plas plas plas plas plas plas plas plas
dardhal
cdub: great work
MJesus
plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas
Jae
clap clap clap clap clap clap clap clap clap clap clap clap 
cdub
thanks for listening!  and please join us on the mailing list or irc if you'd like to help or ask more question!
* Jae is downloading the patch :)
*** riel changes topic to '00:00 CET  Raúl Eduardo Millán Villalaz "Viabilidad economica y técnica de Linux en el Escritorio de Trabajo" | English in #redes ?? | questions in #qc'
* riel really has to go now
riel
cdub, sarnold: it was a nice and interesting lecture
cdub
thanks unriel 
MJesus
thnks all !!