From: Darrel Goeddel <dgoeddel@TrustedCS.com>
To: "selinux@tycho.nsa.gov" <selinux@tycho.nsa.gov>
Subject: [patch] selinux_capget()
Date: Mon, 13 Dec 2004 16:32:39 -0600 [thread overview]
Message-ID: <41BE1887.4010201@trustedcs.com> (raw)
[-- 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,
next reply other threads:[~2004-12-13 22:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-13 22:32 Darrel Goeddel [this message]
2004-12-14 0:05 ` [patch] selinux_capget() James Morris
2004-12-14 0:48 ` Casey Schaufler
2004-12-14 6:09 ` James Morris
2004-12-14 14:37 ` Stephen Smalley
2004-12-14 15:14 ` Stephen Smalley
2004-12-14 15:53 ` Darrel Goeddel
2004-12-14 16:11 ` Stephen Smalley
2004-12-14 16:22 ` Casey Schaufler
2004-12-20 1:16 ` Russell Coker
2004-12-20 4:51 ` Casey Schaufler
2004-12-20 1:10 ` Russell Coker
2004-12-21 20:32 ` Valdis.Kletnieks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41BE1887.4010201@trustedcs.com \
--to=dgoeddel@trustedcs.com \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.