linux-kernel - Re: [PATCH 1/1] security: introduce fs caps

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1162819873.5519.250.camel@moss-spartans.epoch.ncsc.mil>
Date:	Mon, 06 Nov 2006 08:31:13 -0500
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Kyle Moffett <mrmacman_g4@....com>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>,
	20060906182719.GB24670@...gelap.austin.ibm.com,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] security: introduce fs caps

On Fri, 2006-11-03 at 21:08 -0500, Kyle Moffett wrote:
> On Nov 03, 2006, at 15:47:06, Serge E. Hallyn wrote:
> >  Quoting Stephen Smalley (sds@...ho.nsa.gov):
> >> On Fri, 2006-11-03 at 14:00 -0600, Serge E. Hallyn wrote:
> >>> One question is, if this were to be tested in -mm, do we want to  
> >>> keep
> >>> this mutually exclusive from selinux through config, or should  
> >>> selinux
> >>> stack on top of this?
> >>
> >> Given that SELinux already stacks with capability and you aren't  
> >> using
> >> the security fields (last I looked), it would seem trivial to enable
> >> stacking with fscaps (just add a few secondary_ops calls to the  
> >> SELinux
> >> hooks, right?).
> >
> > Yup, I just wasn't sure if there would be actual objections to the  
> > idea of enabling both at once.
> >
> > I'll send out a patch - just as soon as I figure out where I left  
> > the src to begin with :)
> 
> To be honest from my understanding of SELinux there is no need at all  
> to use FS caps on an SELinux system.  Anything that could be done  
> with FS caps would be done in a much more fine-grained method with  
> SELinux, and the inheritance of filesystem-based capabilities should  
> be masked by SELinux-allowed capabilities anyways.  I guess it _can_  
> be done, but why?  It's possible to set up an SELinux system so that  
> there aren't even any SUID binaries, right?  /etc/passwd can run as  
> whatever random user and it will automatically transition to the  
> appropriate domain such that it can read and modify /etc/shadow.

Not currently, no.  SELinux typically applies its MAC checks after any
DAC checks have already been applied, and will only further restrict
access.  Hence, you can use SELinux to limit what a process with
capabilities can do, since it must also have the corresponding SELinux
permissions, but you still need a way of gaining those capabilities in
order to pass the usual Linux checks.

Using SELinux to authoritatively grant capabilities based on role/domain
would be useful, and has been done by some people (via custom kernels),
but doing so safely requires quite a bit of work in userspace and policy
configuration.  That wasn't viewed as practical for an initial
deployment of MAC, and we didn't want to expose systems to greater risk.

-- 
Stephen Smalley
National Security Agency

-
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/