Re: [patch 1/3] lsm: add bsdjail module

[Herbert Poetzl]

On Thu, Oct 07, 2004 at 11:52:40AM -0700, Chris Wright wrote:
> * Andrew Morton (akpm@xxxxxxxx) wrote:
> > Chris Wright <chrisw@xxxxxxxx> wrote:
> > > * Andrew Morton (akpm@xxxxxxxx) wrote:
> > > Which feature are you concerned over, the additional hook or the
> > > new module?
> > 
> > I am concerned about the presence of new code - simple as that.
> 
> Understood.
> 
> > We need to be able to demonstrate that the new code is sufficiently useful
> > to a sufficiently large number of people as to warrant the cost of
> > maintaining it in the tree for the rest of eternity.
> 
> That's fine.  Serge, can you enlighten us with an idea of the users of
> this code?
> 
> > >  The module is a no-op for anybody who doesn't want it.
> > 
> > It still needs to be maintained.
> 
> Absolutely.
> 
> > > I can't vouch for the number of users of this module although I've seen
> > > some positive feedback from users.  One nice bit is that it goes a way
> > > towards helping vserver which does have quite a few users.
> > 
> > Tell us more.
> 
> One portion of the vserver project (that which has to do with security
> and isolation) could be largely covered by this work.  And vserver
> is an active project with many users AFAICT.  The vserver maintainer
> has expressed some interest in this as well.  The other portion of the
> project, which does the resource limiting has a decent chance of working
> well with something like CKRM or similar.

well, as 'the vserver project' probably means the
'linux-vserver project', I would like to point out 
why and where the bsdjail LSM, in it's current form
is flawed from the linux-vserver point of view ...

Serge, don't get me wrong, this is neither against 
you nor against the bsdjail LSM, which I consider
an interesting approach, and I'm still confident 
that we find some way of cooperation ...

(copied the jail struct here to comment it)

| struct jail_struct {
| 	struct kref		kref;
|
|	/* these are set on writes to /proc/<pid>/attr/exec */
|	char *root_pathname; /* char * containing path to use as jail / */

linux-vserver uses namespaces to create the vservers, 
only the legacy method uses a simple chroot() to
setup the vserver environment ...

| 	char *ip4_addr_name;  /* char * containing ip4 addr to use for jail */
| 	char *ip6_addr_name;  /* char * containing ip6 addr to use for jail */

linux-vserver is slowly moving from chbind (which 
restricts a process and it's children to a set of 
IPs to an iptable (marking) based approach, which 
is much more flexible

| 	/* these are set when a jail becomes active */
| 	__u32 addr4;		/* internal form of ip4_addr_name */
| 	struct in6_addr addr6;  /* internal form of ip6_addr_name */

up to 16 addresses are currently allowed in this set
in the future the limit will go away (network code is
actually the oldest piece) by using 'markings'
(network is virtualized to allow binding to 0.0.0.0)

| 	struct dentry *dentry;  /* dentry of fs root */
| 	struct vfsmount *mnt;	/* vfsmnt of fs root */
 
| 	/* Resource limits.  0 = no limit */
| 	int max_nrtask; 	/* maximum number of tasks within this jail. */
| 	int cur_nrtask; 	/* current number of tasks within this jail. */

linux-vserver already has a nice and usable resource
management system for most resources, supporting
much more limits than those ...

| 	long maxtimeslice;	/* max timeslice in ms for procs in this jail */
|	long nice;		/* nice level for processes in this jail */
| 	long max_data, max_memlock;  /* equivalent to RLIMIT_{DATA,MEMLOCK} */

the resource limitations should not be part of a 
security module, and the scheduler slice would be
a step in the wrong redirection, as linux-vserver
already uses token buckets to control the scheduler

| 	char jail_flags;
|};

also many distributions (and distribution hosting
is _the_ main application area for linux-vserver)
require the 'jail' to be as similar as possible
to a real host (like a separate init process, or
the ability to renice services) so some of the
'features' of that LSM are contra productive here
not to mention that linux-vserver's security is
mainly based on linux capabilities which are not
handled by this LSM at all ...

aside from that, without the notion of a security
context, which can be controlled and entered from
outside (the host) the 'jail' can not be used for
typical hosting purposes 

> > >  This module
> > > really demonstrates one of the points of LSM...to support multiple
> > > security models.
> > 
> > Sure.  But that doesn't mean that those modules have to live at kernel.org
> > rather than, say, at bsdjail.sourceforge.net.
> 
> I agree, some userbase does wonders to justify mainlining the code.

I'm pretty confident the fact that a big company
seems interested in this LSM will help with the 
integration into mainline, but I can not say that 
'linux-vserver' users or developers will have any 
immediate benefit from it's inclusion ... why?

 - the linux-vserver user would have to apply an
   additional patch anyway (and install special
   tools to control the vservers)

 - the LSM does not provide what linux-vserver
   requires and would need heavy modification
   (missing context, namespaces, network, most
   virtualization, resource isolation)

 - once CKRM will be able to replace the resource
   management currently present in linux-vserver,
   it (CKRM) will collide with the resource stuff
   done in this LSM

so while I'm fine with the idea to move a part of
linux-vserver to the LSM framework (once the LSM
stackering issues are resolved), this part would
not be usable without a decent part of kernel
modifications to do the virtualization and the
resource isolation

of course if there _is_ interest to include 
linux-vserver like features into mainline, then 
there should be some commitment to do it properly 
and this includes not limiting it to a security
module, where it requires much more to be useful
to anyone ...

finally I have no problem to maintain the 'vserver'
patches outside the kernel tree, as they are 
probably only of limited interest for the typical
linux desktop user ...

best,
Herbert 
(linux-vserver maintainer)

PS: for details see the linux-vserver paper at
http://www.linux-vserver.org/index.php?page=Linux-VServer-Paper

> thanks,
> -chris
> -- 
> Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/