[patch] selinux_capget()

[patch] selinux_capget()

[Darrel Goeddel]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

Currently, SELinux restricts the use of capabilities by a process based on the 
process domain's access to the capability security class.  This restriction is 
not reflected in the capabilities returned by the capget system call.  I have 
attached a small patch which would remove the "disallowed" capabilities from the 
effective set that is returned from the call.  This seems to be a good idea to 
me because it gives an accurate picture of the the capabilities that a process 
can use.  Does anyone else have an opinion on this?

-- 

Darrel

[-- Attachment #2: selinux_capget.patch --]
[-- Type: text/plain, Size: 1235 bytes --]

Index: hooks.c
===================================================================
RCS file: /cvsroot/selinux/nsa/linux-2.6/security/selinux/hooks.c,v
retrieving revision 1.26
diff -u -r1.26 hooks.c
--- hooks.c	6 Dec 2004 20:04:06 -0000	1.26
+++ hooks.c	13 Dec 2004 21:14:15 -0000
@@ -1365,13 +1365,26 @@
 static int selinux_capget(struct task_struct *target, kernel_cap_t *effective,
                           kernel_cap_t *inheritable, kernel_cap_t *permitted)
 {
+	struct task_security_struct *tsec;
+	struct av_decision avd;
 	int error;
 
 	error = task_has_perm(current, target, PROCESS__GETCAP);
 	if (error)
 		return error;
 
-	return secondary_ops->capget(target, effective, inheritable, permitted);
+	error = secondary_ops->capget(target, effective, inheritable,
+	                              permitted);
+	if (error)
+		return error;
+
+	/* Remove the capabilites that are not allowed to be used by the domain
+	   from the effective set */
+	tsec = target->security;
+	(void)avc_has_perm_noaudit(tsec->sid, tsec->sid,
+	                           SECCLASS_CAPABILITY, ~0, &avd);
+	cap_mask(*effective, avd.allowed);
+	return 0;
 }
 
 static int selinux_capset_check(struct task_struct *target, kernel_cap_t *effective,

Re: [patch] selinux_capget()

[James Morris]

On Mon, 13 Dec 2004, Darrel Goeddel wrote:

> can use.  Does anyone else have an opinion on this?

Seems to make sense.


- James
-- 
James Morris
<jmorris@redhat.com>



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch] selinux_capget()

[Casey Schaufler]

--- Darrel Goeddel <dgoeddel@trustedcs.com> wrote:

> Currently, SELinux restricts the use of capabilities
> by a process based on the 
> process domain's access to the capability security
> class.  This restriction is 
> not reflected in the capabilities returned by the
> capget system call.  I have 
> attached a small patch which would remove the
> "disallowed" capabilities from the 
> effective set that is returned from the call.  This
> seems to be a good idea to 
> me because it gives an accurate picture of the the
> capabilities that a process 
> can use.  Does anyone else have an opinion on this?

I do! I do!

The POSIX 1003.1e/2c (previously P1003.6) working
group that developed the capabilities interface
upon which Linux capabilities are based discussed
this issue at length. The concensus was that such
a "correction" should not be made. One example that
was used to demonstrate the rationale is a system
(such as IRIX) on which you are allowed to perform
a privileged operation if you have the capability
or if your UID is zero (i.e. you are root). The
getcap() call should not "correct" the effective
set of capabilities to indicate they are all on
for a root process, but should instead return the
actual set. This is in line with the "stat" behavior
which reports the actual mode bits, even if they
include "w" on a read-only file system.

Briefly, the intent of the POSIX specification
is that you should not "correct" the effective set
due to the impact of additional policies or
conditions.


=====
Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch] selinux_capget()

[James Morris]

On Mon, 13 Dec 2004, Casey Schaufler wrote:

> Briefly, the intent of the POSIX specification
> is that you should not "correct" the effective set
> due to the impact of additional policies or
> conditions.

How does the application determine the real effective set?  
(confusing enough terms ? :-)

Surely it is a reasonable thing to expect to be able to do.  I'm not sure
that your example is valid here as euid==0 doesn't mean anything in
SELinux (if it did, the application could check that first and infer that
it has all capabilities).


- James
-- 
James Morris
<jmorris@redhat.com>




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch] selinux_capget()

[Stephen Smalley]

On Tue, 2004-12-14 at 01:09, James Morris wrote:
> How does the application determine the real effective set?  
> (confusing enough terms ? :-)
> 
> Surely it is a reasonable thing to expect to be able to do.  I'm not sure
> that your example is valid here as euid==0 doesn't mean anything in
> SELinux (if it did, the application could check that first and infer that
> it has all capabilities).

An application (with appropriate permissions) could invoke the
libselinux avc_has_perm() or security_compute_av() interfaces to
determine what capabilities are allowed by SELinux.  On the downside,
that requires the application to perform an extra call and to be
SELinux-aware.  On the upside, it means that an application either
requires appropriate permissions to call security_compute_av() or must
engage in testing activity to discover what capabilitites are allowed by
SELinux as opposed to being able to trivially determine via capget.

If we were going to make this change, it would seem that you would also
need to either change fs/proc/array.c:task_cap() or change SELinux to
mask out the capabilities early (e.g. in selinux_bprm_apply_creds and
selinux_capset_set) so that the capability bitmaps in the task structure
always reflect the combined decision (at which point you'd need to move
the SELinux check prior to the secondary_ops check in selinux_capable or
you'd never see the SELinux audit message at all).  But I'm not certain
we want to make this change.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch] selinux_capget()

[Stephen Smalley]

On Tue, 2004-12-14 at 09:37, Stephen Smalley wrote:
> An application (with appropriate permissions) could invoke the
> libselinux avc_has_perm() or security_compute_av() interfaces to
> determine what capabilities are allowed by SELinux.  On the downside,
> that requires the application to perform an extra call and to be
> SELinux-aware.

BTW, note that you could always provide a new library function, e.g.
selinux_capget(), that internally does the capget() call and a
security_compute_av() call and combines the results.  Then your
applications can just make that single call.  Or even selectively
override capget() with that function using your own shared object if you
can't modify the applications.  No need for a kernel change.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch] selinux_capget()

[Darrel Goeddel]

Stephen Smalley wrote:
> An application (with appropriate permissions) could invoke the
> libselinux avc_has_perm() or security_compute_av() interfaces to
> determine what capabilities are allowed by SELinux.  On the downside,
> that requires the application to perform an extra call and to be
> SELinux-aware.  On the upside, it means that an application either
> requires appropriate permissions to call security_compute_av() or must
> engage in testing activity to discover what capabilitites are allowed by
> SELinux as opposed to being able to trivially determine via capget.
> 
> If we were going to make this change, it would seem that you would also
> need to either change fs/proc/array.c:task_cap() or change SELinux to
> mask out the capabilities early (e.g. in selinux_bprm_apply_creds and
> selinux_capset_set) so that the capability bitmaps in the task structure
> always reflect the combined decision (at which point you'd need to move
> the SELinux check prior to the secondary_ops check in selinux_capable or
> you'd never see the SELinux audit message at all).  But I'm not certain
> we want to make this change.
> 

I agree that the change may not be what we want - this is an idea that came out 
of some experimenting that I am doing.  I was actually expecting an explanation 
about the capget interface along the lines of what Casey pointed out.

We could leave the current /proc/<TGID>/status interface alone to provide a view 
to the "actual" capability set of the process.  Modifying the actual capability 
sets on the process would not work in the case where a process changes its 
domain via setcon to a domain which has greater access to capabilities - we 
would not know whether or not to raise the capabilities in the task struct.

The whole reason I noticed this is because I have been playing with a secondary 
module that makes SELinux the authoritative decision maker for capable 
decisions.  It always returns 0 in its capable hook.  It also uses the 
capability module versions of the syslog and vm_enough_memory hooks because the 
dummy versions actually do uid checks for some reason (I think that these should 
probably be changed, leaving the only uid checks in the actual capable hook for 
dummy), and a modified version of the netlink_send hook.  I just figured it 
would be nice if the module would return full sets from the capget hook, and 
then SELinux would doctor them up to reflect the actual effective capabilities. 
  This idea is still a work in progress, but the effective set modification 
seemed applicable now.

-- 

Darrel

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch] selinux_capget()

[Stephen Smalley]

On Tue, 2004-12-14 at 10:53, Darrel Goeddel wrote:
> The whole reason I noticed this is because I have been playing with a secondary 
> module that makes SELinux the authoritative decision maker for capable 
> decisions.

This is something we would eventually like to do (i.e. use RBAC/TE as
the sole basis for granting privileges), but to do it safely, you need
to perform:
a) a thorough audit and tightening of the policy, going beyond what is
in the strict policy today to provide separate domains for every setuid
root program and to only allow capabilities to those specific domains,
b) a thorough audit of userspace, going beyond what has been done in
Fedora Core to ensure that no assumptions are made about uid 0 and that
SELinux is consulted on access decisions via libselinux avc_has_perm or
security_compute_av.
 
-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch] selinux_capget()

[Casey Schaufler]

--- James Morris <jmorris@redhat.com> wrote:

> On Mon, 13 Dec 2004, Casey Schaufler wrote:
> 
> > Briefly, the intent of the POSIX specification
> > is that you should not "correct" the effective set
> > due to the impact of additional policies or
> > conditions.
> 
> How does the application determine the real
> effective set?

The short answer is that it doesn't. How do you
determine if you can really open a file for write
access? The real world behavior is to check what
you know about (e.g. UID, mode bits) and hope that
you'll pass any additinoal constraints (e.g. ACLS,
capabilities, mount options) that might apply. Then
try it and check the error return.

> (confusing enough terms ? :-)

If you think this is a confusing set of terms you
should have been in Denver when we found out that
the term "privilege" had an ISO definition, and so
we had to change the draft to use something else.
Leave it that capabilities with all it's terminology
issues was the best choice.

> Surely it is a reasonable thing to expect to be able
> to do.

Indeed it is. Unfortunatly, the best suggested
interface I've seen is on the lines of:

     canido("open(\"/somewhere/file\", O_WRITE)");

which is a generalized version of access(2), that
notoriously unuseful syscall. Needless to say, such
an inferface is impracticle and would still yield
false positives.

> I'm not sure
> that your example is valid here as euid==0 doesn't
> mean anything in
> SELinux (if it did, the application could check that
> first and infer that
> it has all capabilities).

Many applications do check to see if they're running
as root and (attempt to) behave differently if they
are. And, you will gain no ground whatever if you
try to get the developers of such applications to
mend their evil ways. Applications that use privilege
must be aware of the privilege mechanisms that
constrain them.

My example come from the capability implementation
in IRIX, where privilege is granted if you have
the effective capability or if you are root. In
Trusted Irix (Trix to it's friends) the uid is not
used in privilege checks, you must have the 
capability. The POSIX draft specification permits
either implementation. The application that cares
about the security environment it resides in and
does anything more sophisticated than trying
the operation and reacting to errors will have a
tough row to hoe.


=====
Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch] selinux_capget()

[Russell Coker]

On Wednesday 15 December 2004 03:22, Casey Schaufler <casey@schaufler-ca.com> 
wrote:
> > How does the application determine the real
> > effective set?
>
> The short answer is that it doesn't. How do you
> determine if you can really open a file for write
> access? The real world behavior is to check what
> you know about (e.g. UID, mode bits) and hope that
> you'll pass any additinoal constraints (e.g. ACLS,
> capabilities, mount options) that might apply. Then
> try it and check the error return.

Doesn't access(2) deal with ACLs and mount options?

> which is a generalized version of access(2), that
> notoriously unuseful syscall. Needless to say, such
> an inferface is impracticle and would still yield
> false positives.

A faccess(2) syscall would be handy if you are contributing to further POSIX 
standards...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch] selinux_capget()

[Casey Schaufler]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 511 bytes --]


--- Russell Coker <russell@coker.com.au> wrote:

 
> Doesn't access(2) deal with ACLs and mount options?

No. 


=====
Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
All your favorites on one personal page – Try My Yahoo!
http://my.yahoo.com 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch] selinux_capget()

[Russell Coker]

On Tuesday 14 December 2004 17:09, James Morris <jmorris@redhat.com> wrote:
> How does the application determine the real effective set?
> (confusing enough terms ? :-)
>
> Surely it is a reasonable thing to expect to be able to do.  I'm not sure
> that your example is valid here as euid==0 doesn't mean anything in
> SELinux (if it did, the application could check that first and infer that
> it has all capabilities).

If program A calls capget() and determines that it does not have a certain 
capability then it does not need to drop that capability before executing 
program B which should not have it.

However if executing program B causes a domain transition to a domain that is 
permitted the capability in question then it might suddenly acquire access to 
a capability that program A thought was unavailable.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch] selinux_capget()

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

On Mon, 20 Dec 2004 12:10:20 +1100, Russell Coker said:

> If program A calls capget() and determines that it does not have a certain 
> capability then it does not need to drop that capability before executing 
> program B which should not have it.
> 
> However if executing program B causes a domain transition to a domain that is
> permitted the capability in question then it might suddenly acquire access to
> a capability that program A thought was unavailable.

On the other hand, in that case B would still have access to the capability
in question, even if A *had* dropped the capability.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]