Message-ID: <9789.1197405725@redhat.com>
Date:	Tue, 11 Dec 2007 20:42:05 +0000
From:	David Howells <dhowells@...hat.com>
To:	Stephen Smalley <sds@...ho.nsa.gov>
Cc:	dhowells@...hat.com, Karl MacMillan <kmacmill@...hat.com>,
	viro@....linux.org.uk, hch@...radead.org,
	Trond.Myklebust@...app.com, casey@...aufler-ca.com,
	linux-kernel@...r.kernel.org, selinux@...ho.nsa.gov,
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

Stephen Smalley <sds@...ho.nsa.gov> wrote:

> > That sounds too SELinux specific.  How do I do it so that it works for any
> > LSM?
> 
> You can't.  There is no LSM for userspace; LSM specifically disavowed
> any common userspace API, and that was one of our original
> objections/concerns about it.

So, basically, userspace programs (outside of security tools) aren't supposed
to need access to the security infrastructure?

> > Is linking against libselinux is a viable option if it's not available under
> > all LSM models?  Is it available under all LSM models?  Perhaps Casey can
> > answer this one.
> 
> Nope, they would all have their own libraries, if they have a library at
> all.  But that isn't your problem

It is if I have to maintain a special pieces of code for each possible LSM.
One piece for SELinux, one piece for AppArmour, one piece for Smack, one piece
for Casey's security system.  That sounds like a pain.

> - your kernel interface should be generic, and your LSM hooks should be
> generic, but your userspace isn't required to be.  Have a look at how many
> programs in the distribution currently link against libselinux, whether
> directly or by dlopen'ing it.

In /usr/bin ldd reports approximately 297 binaries link to libselinux, though
I can't say how many of those linked against it directly rather than picking
it up by contamination through a shared library.  Furthermore, I've no idea
how many more find it by dlopen.

> > > > I use to do that, but someone objected...  Possibly Karl MacMillan.
> > > 
> > > Yes, but I think I disagreed then too.
> > 
> > So, who's right?
> 
> Karl isn't a maintainer of the SELinux kernel code.  And I had thought
> that even he had reconsidered this idea after further discussion.

Not that I know of.

> > > It doesn't fit with how other users of security_kernel_act_as() will
> > > likely want to work (they will want to just set the context to a
> > > specified value, whether one obtained from the client or from some local
> > > source), nor with how type transitions normally work (exec, with the
> > > program type as the second type field).  I think it will just cause
> > > confusion and subtle breakage.
> > 
> > It's causing me lots of confusion as it is.  I have been / am being told by
> > different people to do different things just in dealing with SELinux, and
> > various people are raising extra requirements or restrictions beyond that.
> > There doesn't seem to be a consensus.
> > 
> > It sounds like the best option is just to have the kernel nick the userspace
> > daemon's security context and use that as is, and junk all the restrictions on
> > what the daemon can do so that the kernel isn't too restricted.
> 
> Well, you could do that, if that meets your needs, but it doesn't sound
> very optimal either.

True.  I'd rather have separate security for each.

> Why are you opposed to having userspace determine the context and write it
> to a cachefiles interface,

Because, from what I gather, that means my userspace program needs to do
something different, depending on the security model that's currently in force
on a system.  Furthermore, I would have to have separate code, as far as I
know, for each security model as there's no commonality in userspace.

I can't just link against libselinux.  It might not be there.  I'm not going
to tie my program to SELinux either.

Furthermore, I worked out "the right way to do this" with some apparent
SELinux person, and you seemed reasonably accepting of it.  Now I have to go
and redo all the work, having had to redo the security stuff a couple of times
already because someone objected.  *That* is the main obstacle to getting my
code accepted at the moment, I think.

How about I just stick the context in /etc/cachefilesd.conf as a textual
configuration item and have the daemon pass that as a string to the cachefiles
kernel module, which can then ask LSM if it's valid to set this context as an
override, given the daemon's own security context?  That seems entirely
reasonable to me.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists