sarnold	thanks for coming everyone; the talk of the hour is going to be given by chris wright, discussing the Linux Security Modules interface, currently being worked into the 2.5 series of kernels
sarnold	there are spanish translations in #redes, dutch in #taee....
sarnold	questions and comments should be directed in #qc
sarnold	and with that, cdub, please take us away.. :)
cdub	thank you sarnold
cdub	today i'm speaking of the linux security modules project (LSM)
cdub	thank you all for atttending.
cdub	I would like to start with a brief overview of where LSM came from.  Some hisorical perspective
cdub	the 2001 kernel summit is the logical place to look to.
riel_	one small housekeeping message: if you have questions about the lecture, you can ask them in #qc  (sorry)
cdub	a member of the SELinux team, Pete Loscoco, presented SELinux to the kernel summit for inclusion into the linux kernel.
cdub	linus and others expressed concern that SELinux was too invasive, and solved a specific problem.  leaving other security projects out in the cold.
cdub	as a consequence, linus requested a framework that could support various security projects with pluggable modules.
cdub	this was the birth of the LSM project.
cdub	promptly, members from various security projects began collaborating and designing a framework to support the various existing security projects.
cdub	this framework was built on a set of assumptions:
cdub	1.  the framework should be generic enough that it can support varioius security models.
cdub	2. it should be light weight, and not impose unnecessary overhead.
cdub	3.  it would support only Access Control security models (meaning full audit, often necessary for accredidation, isn't supported)
cdub	4. it needed to support the pre-existing capabilities
cdub	this lead the LSM project to the current design, which is partially merged with the 2.5 mainline kernel.
cdub	<rene:#qc> more explanation of "access control" versus "full audit"?
cdub	sure.
cdub	often, things like Common Criteria, or Orange Book certifications require a variety of security enhancements.
cdub	one being fairly obvious, access control
cdub	another aspect of certification is often the ability to real-time audit the transactions in a system.
cdub	so, not just restricting access for foo process to bar object, but also logging this event in a structured way.
cdub	and this logging/audting is beyond the scope of the current LSM project's charter.
cdub	so, let me begin breaking down the aspects of the LSM design.
cdub	but first, a quick qeustion:
cdub	yes.
cdub	;-)
cdub	Alright, so here are some of the basic qualities of the LSM framework.
cdub	1. It provides the ability to register a new security module.
cdub	2. It provides the in-kernle hooks required for the the module to enforce access control
cdub	registration is very simple, the module simple fills out the callbacks required, and calls register_security()
cdub	<zanshin:#qc> Is there a list af objects for which security modules can be written?
cdub	that's where i'm headed ;-)
cdub	sure.
cdub	let me give a quick look at the list of objects that are protected, then look at the syscall issue.
cdub	the LSM framework monitors access to some basic kernel objects, like super blocks, inodes, binprm (during program execution), ipc objects: semaphores, mqueues, shared mem
cdub	it also, hooks into the network stack at a couple levels (sockets level, transport layer, network layer, ...)
cdub	so, defining the core kernel objects is intrinisically far away from the syscall entry points
cdub	the syscall entry point defines a nice abstraction for userspace to interact with the services the kernel provides.
cdub	however, it does not work with kernel primitives (such as dentry's and inode's).
cdub	so the syscall entry point takes user supplied data, (often strings in the fs layer), and converts them to kernel objects.  throught pathname resolutoin.
cdub	the kernel copies in this data and translates it in a non-atomic way, so it is race prone to just use the syscall entry point.
cdub	finally, the syscall entry point _does_ describe much of what the user can do to the system.
cdub	so LSM must protect against all these actions.
cdub	therefore, it is not uncommon to see a LSM hook that looks suspicisously similar to the syuscall entry point.
cdub	infact, the sockets internal api is basically just the socket syscall api...
cdub	riel_: does that answer your question?
cdub	<rene:#qc> cdub: could you give an example of a race here?
cdub	yes, open ("foo")
cdub	foo is copied in to kernel, and looked up.  if the LSM interface was before translation, it could look up foo, grant access.
cdub	then another thread could modify foo.  and the kernel would then see "newfoo", know that it passed lsm, look it up...
cdub	blam...
cdub	alright, just to recap, since there were questions interspersed...
cdub	the LSM framework is a simple hooking API.  it provides the registration, and in-kernel callbacks
cdub	no, userspace.
cdub	<nab:#qc> cdub: Is it possible to use multiple security modules at the same time,  and if so what are the limitations in doing so.
cdub	nab: that's an interesting question.
cdub	let me digress shortly before answering.
cdub	one of the things that the LSM interface provides is the ability to label kernel objects with security id's
cdub	this is core to the ability to decide if an action is safe.  the LSM module could compare the task's security id with the inode's security id, for example.
cdub	because of security labelling, it is difficult for multiple security models to share the LSM space at one time.
cdub	(without adding some smarts to the interface that knows which module is querying the object).
cdub	linus specifically didn't want this.
cdub	and in fact, security research shows that arbitrary security models compose and produce arbitrary results
cdub	not satisfactory for security.
cdub	so...the LSM interface provides the ability to stack modules, but requires a module to handle the stacking.  basically someone in charge of deciding how to compose the results of the various security deccisions
cdub	such a module has been written, although it is not part of the LSM tree.
cdub	this is an area where future development will likely change the current behaviour.
cdub	but for now, we follow, KISS
cdub	<zanshin:#qc> are syscall hooks and callbacks pointers to fuctions one should fill in when registering a security module?
cdub	the LSM interface is a structure of callback pointers.  this is all you have to fill in to register.
cdub	some of the callback pointers very closely mimic the syscall entry point they are protecting, but not all.
cdub	we could look at a sample call flow to see how this looks in terms of code.
cdub	most security models will care, for example, about the creation of a new task, and specifically execve() which can change your exectuoin domains.
cdub	<nab:#qc> cdub:  How much overhead is associated in using the various hooks,  in what section of the kernel (fs ops, socket ops, etc) do the largest performance drawbacks lie?
cdub	nab: the overhead measured in macro benchmarks is very low.
cdub	nab: often in th 0-2% range.
cdub	<nab:#qc> cdub: or would this be more related to the implemenation of the hooks inside the security module?
cdub	absolutely.
cdub	the network hooks tend to cause more overhead
cdub	but, a poorly coded hook could serialize an operation that must highly concurrent and optimized.
cdub	so the module itself is critical in system perf measurements.
cdub	but, it is possible to create a very simple module to stress just the framework.
cdub	there we see, as i mentioned, the network stack having more impact.
cdub	also, our numbers showed stat open/close and unlink to be heavier than other fs hooks.
cdub	consider anything that has to look up the kernel path (or dentry) will do multiple permisison checks, on at each directory, plus a check on the final object, so this is not a surprise.
cdub	alright, so i was showing a simple call flow...
cdub	execve("/bin/foo")
cdub	this will first look up the bin/foo object and turn it into a kernel file pointer
cdub	this lookup will triggeer a couple permission checks on "/" and "/bin" and "/bin/foo"
cdub	then, assuming one has access to the full path, the binformat handlers are queried.
cdub	during this stage, a binprm structre is created, and then LSM labels it.
cdub	this becomes clear if you think of a UNIX setuid program.
cdub	the task would have one label (uid 500 == chris, for example)
cdub	but the binprm structure would have another label (uid 0, for example).
cdub	later the module is queried if it's ok to execute the new program.  this include perhaps transtioning the current task to a new security domain.
cdub	this one could be elevated or lowered...
cdub	to follow this in code, one would look at the bprm based LSM hooks.
cdub	once the task is labelled, either via fork, or exec, all future access to kernel objects (superblocks via mount(2), files via open/read/write.., network via sockets api)
cdub	must go through LSM module, and the labels on the kernel objects are compared against the task label
cdub	this is the fundamental behaviour of LSM.
cdub	<pdp:#qc> But why allow upped sec-levels from un "unsecured sec-level by the Main sec-level ?  ??
cdub	i'm not sure i understand the question.  this is a security policy question.
cdub	for example, it may be ok for the /bin/foo security domain (from execve("/bin/foo")
cdub	to call /bin/bar
cdub	and according to the policy, it may be a way for increased privs.  but it may not.  it is all determined by the policy codified in the security module
cdub	in fact, that is one of the critical features of LSM.
cdub	all policy is in the module.
cdub	the framework just doesn't care.
cdub	<riel_:#qc> cdub: does LSM handle passing of filedescriptors via unix domain sockets ?
cdub	absolutely
cdub	it is possible to control the passing of fd's.
cdub	some policies may allow it, but if you get a lower security level fd, perhaps your tasks security domain will bbe lowered
cdub	or perhaps you simply wouldn't allow the fd to be passed at all.
cdub	a common question is: "aren't modules insecure?"
cdub	this is a debatable question.  but LSM doesn't have to be modular.  it can be compiled statically, just as other modules.  so this is not a real issue.
cdub	and, of course, the security module controls the loading and unloading of modules, so it can run a tight ship.
cdub	alright, as i mentioned earlier, LSM is for access control.
cdub	it is largely used for Macdatory Access Control (MAC), but is not limited to this.
cdub	as such, the standard UNIX Discretionary Access Control (DAC) mechanism is still in tact.
cdub	and there is an ordering issue between DAC and MAC.
cdub	in general, we place LSM hooks were there already exists kernel permissoin checking logic
cdub	and we check LSM before falling back to the DAC checks (as is typically required by MAC).
cdub	andre had a couple questions that i'd like to discuss now
cdub	<andre:#qc> cdub: how is the addition of LSM against any other bolt on
cdub	API different, regardless if it is natively adopted
cdub	well, the primary difference is the level of intrusiveness.
cdub	most API's are smaller and live in their own corner of the kernel
cdub	however, given the nature of LSM, it touches much of the core kernel
cdub	and therefore it is different, esp when it comes to GPL and kernel code.
cdub	most kernel developers are very concerned about the GPL and don't want their code exploited in a non-GPL way.
cdub	so the LSM API is exported as a GPL only API.
cdub	this is because it touches so much of the core kernel, it is important to make it clear that security module is in the core kernel code
cdub	and is a derived work of the linux kernel
cdub	insert appropriate "I am not a lawyer" disclaimer here.
cdub	i'm not sure what people may have missed during the netsplits
cdub	so perhaps, i'll take some questions now
cdub	feel free to ask questions in #qc
cdub	<andre:#qc> now are all LSM additions derived works and this forced to GPL thus removing the viable secret nature of LSM operations
cdub	<andre:#qc> now if the secret sauce of each discrete LSM is disclosed, what is the use of LSM period
cdub	alright, this is an important question, but i hope not to fall to far into license wars.
cdub	first of all, the use of the LSM interface itself is very core to the linux kernel.
cdub	it hooks around linux kernel core objects, and allows/disallows access
cdub	thus one could argue that the use of the LSM interface is clearly a derived work of the linux kernel
cdub	furthermore...
cdub	in this case, we are talking of security
cdub	it is a well-known security concern that secrets are not good for security
cdub	while that doesn't dictate that the code itself be open, at least the algorithm should be disclosed and well-understood
cdub	otherwise you are on the verge of security through obscurity
cdub	so, if disclosing your security module compromises the security of the module, then it's likely the module is insecure to begin with (license aside
cdub	back to the license side...the LSM project doesn't really care one way or the other.
cdub	we care about adding a security infrastructure to the linux kernel
cdub	linus said what he wanted, and we gave it to him
cdub	and he believes the LSM api should be exported GPL_ONLY
cdub	this is a sacrifice we are willing to make, to ensure that LSM does not get removed from the kernel
cdub	i hope that answers the question.  it is a very contentious topic, and often sparks emotional rather than techinal arguments
cdub	<andre:#qc> cdub: invalid argument, only future releases can be removed not older versions
cdub	alright, point taken.
cdub	however, consider that LSM is largely out of tree
cdub	we are only about halfway merged
cdub	so, what we care about is full merging
cdub	and 2.5 is not 2.6 yet, so things can still change.
cdub	linus as good as said, it will be GPL_ONLY or I will rip it out.  period.  it's his tree, we do what he (and other copyright holders) want
cdub	and the stuff that is in the LSM tree exists as a patch to the kernel.  and the licesnse restriction there tends to be considered GPl by definition
cdub	alright, are there any other questions.
cdub	the talk has been a little fragmented, so please feel free to speak up if there are things that are unclear
cdub	<rene:#qc> cdub: you mentioned compatibility with capabilities as a requirement; how do they fit in? just another policy?
cdub	rene: that's a good question
cdub	linux (before LSM) supported some portion of the POSIX.1e draft for Capabilities
cdub	so, we needed to preserve that
cdub	capabilities are a slight enhancement on UID == 0 policy (super user policy)
cdub	however, a tasks capabilities are reasonably static
cdub	so, capabilities are done both as a module and inline coded in the kernel
cdub	we separated all the capabilities logic out, put it behind functions that can be called from the security module
cdub	then, recently, gregkh made it possible to compile away LSM, which leaves you with the old style kernel
cdub	this calls the capabilities functions that we separated out inline, rather than through the LSM interface.
cdub	however, one are of capabilities is not in LSM
cdub	the task label which is used  to identify the security domain is not used by capabilities
cdub	instead, it still uses the task_struct native capabilties data structures
cdub	so, capabilities is the odd duck.  it is half-in, half-out.
cdub	and it's primary roll is to override security deciisions
cdub	in other words, most MAC models restrict access..."can i have access" yes/no
cdub	however capabilities typically override:  "i wasn't supposed to have access, but...please?" yes/no
cdub	so, capabilities compatiblity has made lsm a different APi than we originally imagined.
cdub	rene: sure ;-)
cdub	i guess there is one other small area that i didn't cover.
cdub	LSM tries to stick to the core kernel.
cdub	this means it is largely not present in drivers, filesystems, etc.
cdub	(of course, the exception is capable() which is present all over ;-)
cdub	and, most of the LSM hooks are called from process context
cdub	this means, most the LSM hooks are called on behalf of a system call.
cdub	however some are called in interrupt context.
cdub	specifically, some of the async io data ready events are delivered (and LSM filtered) here
cdub	also, arriving network packets
cdub	so, when one codes an LSM module they need to be aware of the contexts the hook can be called from.
cdub	i should also mention what we have today.
cdub	the LSM interface is roughly 150 callbacks.
cdub	about half of those are merged with linus' tree.
cdub	the networking code is up for merging, but it will be a challenge to get it in (due to the performance impact).
cdub	thankfully, gregkh made LSM compilable away, so we hope this helps with the perf. argument.
cdub	also, there are about 5 modules that have been developed.
cdub	the first two are simple: super user, and capabilities.
cdub	the third adds a bit of the Openwall kernel patch.
cdub	(ok there are six ;-)
cdub	the last three are much more complex.
cdub	aiee.. (ok there are 7 ;-)
cdub	gregkh wrote an example module, showing how you could enforce a policy by requiring a specific USB device to be present to get root privs (or somthing along those lines)
cdub	the last three, LIDS, DTE and SELInux are more complicated examples of usage of LSM.
cdub	SELinux uses the most of the interface.
cdub	and it allows you to effectively control every access to every object.
cdub	it allows you to do MAC, TE, MLS.  things that are important when many users have access to a machine, and it has confidential (read: often military) information.
cdub	also, there are some out of tree modules, for example SubDomain, and whatever HP and SGI are working on.  Also, some new modules should show up from IBM security research.
cdub	<rene:#qc> TE/MLS?
cdub	Type Enforcement
cdub	Multi Level Security
cdub	i'd suggest google to get complete defintions.
cdub	<zanshin:#qc> Can you explain the part about id's and registering id's once more... when is an object registerd?. And when is it referenced if a syscall is made? And how are the internal hooks hooked on userland syscalls? pffieuw :)
cdub	well, i'll give it a quick shot.  otherwise we can talk offline
cdub	the LSM interface provides a structure of callbacks (function pointers)
cdub	the module fills out a structure with its policy specific callbacks
cdub	then it registers with the framework
cdub	from that point forward, the LSM hooks that are in the kernel
cdub	will callback (through the fucntion pointer) to the module
cdub	the callbacks do things like tell the module that a new object is being created
cdub	one is being destroyed
cdub	or one is being accessed
cdub	when  a new object is created (a new inode for example)
cdub	the kernel creates the object, then calls to the module to allocate module specific space
cdub	in the object for the module to maintain a security label
cdub	the label is typically the security ID
cdub	and later, when the object is accessed
cdub	the current security domain (typically that of the current running process that made the syscall, for example)
cdub	can be compared with the objects label
cdub	depending on the policy, this information is used to grant/deny access to the object
cdub	that's it in a nutshell
cdub	hope that was clearer
cdub	so, LSM is far from done
cdub	aside for continuing to clean up, and merge with the kernel
cdub	we are looking for ways to fit more cleanly into the kernel's infrastucture
cdub	this could help keep the module interface clean, and easy to maintain.  right now it is very much a bolt on (as andre said)
cdub	also, we are hoping to incorporate new modules
cdub	and ideas from similar projects.  for example, RSBAC (for linux) and TrustedBSD (bsd obvsiously) have some nice ideas that we'd like to see how we can use.
cdub	if you are interested in helping out, please take a look at lsm.immunix.org.  it has code, docs, mail list links, irc links, etc.
cdub	i'm happy to take more questions.
cdub	well, i'll take that to mean you've all fallen asleep ;-)
cdub	heh, thanks very much for your time.
viXard	im trying to write my Q
fernand0	plas plas plas plas plas plas plas plas plas plast
<fernand0> plas plas plas plas plas plas plas plas plas plast
fernand0	plas plas plas plas plas plas plas plas plas plast
viXard	PLAS PLAS PLAS PLAS PLAS PLAS :))))
viXard	PLAS PLAS PLAS PLAS PLAS PLAS :))))
fernand0	plas plas plas plas plas plas plas plas plas plast
viXard	PLAS PLAS PLAS PLAS PLAS PLAS :))))
viXard	PLAS PLAS PLAS PLAS PLAS PLAS :))))
BorZung	thanks you cdub for your time
viXard	PLAS PLAS PLAS PLAS PLAS PLAS :))))
Pummel	plas plas plas plas plas plas
pdp	clap clap clap clap
zanshin	clap clap clap clap clap :0)
fernand0	plas plas plas plas plas plas plas plas plas plast
rene	in dutch, that's "pee pee pee" ...
rene	we say "klap"
cdub	<viXard:#qc> Are these modules arch careless?
viXard:#qc	forgive my english :)
cdub	viXard: almost
Taigeru	wse say "bis", just to force you to repeat everything :)
cdub	ptrace is typicall arch specific.  in most other cases, we are arch independent.
pdp	encore encore!
cdub	s/typicall/typically/
* zanshin loves these presentations on irc.
cdub	again, thanks
<cdub> and feel free to bug me on irc or on the mailing list
sarnold	cdub: thanks :)
viXard	so, you think LSM will be the official Linus tree security module? (sorry if the question is dumb )
cdub	zanshin: yes i do to.  very nice medium for presentations.  uninet does a great job!
pdp	tnx  cuagn
cdub	viXard: LSM is not one module, but a framework to support many modules
zanshin	hope there will be more on a regular basis.
cdub	a little bit like the VFS, which allows pluggable filesystems
viXard	ok, it´ll be the official one?
sarnold	zanshin: we hope to have an INFOSEC talk around april
cdub	so, LSM should be in linus' tree (it is already half way in)
* viXard freeze out !
zanshin	nice... looking forward to it.
cdub	and who knows what would be the most popular module.  SELinux is certainly well known
viXard	arrg, infosec :$
sarnold	zanshin: maybe we will have a 6fevu (ipv6) conference somewhere around here....
sarnold	viXard: you'll have fun. :-P  :)
fernand0	and of course, anybody willing to talk here is invited to do so whenever he wants
cdub	heh ;-)
sarnold	zanshin: uninet also hosts other conferences, such as doctors and pathologists and math and ....
viXard	law
viXard	lawyers
rene	cdub: many thanks again!
cdub	rene sure
zanshin	sarnold: are there also talks about education and opensource? I hope to get an opensource project started at my school.
sarnold	zanshin: heh, that probably would have fit into umeet pretty well :)

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net!