selinux_capget()

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

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
@@ -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,

Seems to make sense.

- James

James Morris
<[email protected]>



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

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
[email protected]

__________________________________
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.

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
<[email protected]>




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

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 <[email protected]>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

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 <[email protected]>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

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 [email protected] with
the words "unsubscribe selinux" without quotes as the message.

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 <[email protected]>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

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.

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.

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.

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
[email protected]

__________________________________
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.

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 [email protected] with
the words "unsubscribe selinux" without quotes as the message.

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

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 [email protected] with
the words "unsubscribe selinux" without quotes as the message.

No.

=====
Casey Schaufler
[email protected]

__________________________________
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.

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