Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3
On Mon, 19 Nov 2007 17:16:44 -0600 Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Chris Friedhoff ([EMAIL PROTECTED]): Hello Serge, just to let you know: with 2.6.24-rc3 I have the same problem. Ok, so here is the flow. First off, using runlevel 5 on FC7, using 'log out' correctly brings you back to a new login prompt. Your problem is starting in runlevel 3, and typing 'xinit .xinitrc'; when you exit your wm, xinit is not allowed to kill X so you don't get back to your console. Yes, I'm booting in a runlevel without a session manager and starting my X session with xinit. (slackware: console-runlevel 3; sessionmanager-runlevel 4 ) First comment is, as you point out on your homepage, you could setfcaps -c cap_kill+p -e /usr/bin/xinit Then xinit is allowed to kill X. Yes xinit forks and execs a user-writable script, but of course upon the exec to start the script cap_kill is lost, so the user can't abuse this. Since you pointed this out on your homepage, I have to assume you've decided you don't want to give cap_kill to xinit? No, since I'm using capabilities and I'm very happy with it, I grant cap_kill to xinit. For myself the problem is solved ... My other question is - do we want to maintain this signal restriction? So long as a privileged process isn't dumpable, is it any more dangerous for user hallyn to kill capability-raised process owned by hallyn than it is to kill a setuid process started by hallyn? If we decide no, then maybe we should remove cap_task_kill() as well as the cap_task_setnice(), cap_task_setioprio(), cap_task_setscheduler()? Or maybe i've just forgotten a compelling scenario... thanks, -serge ... but if some user decides to configure capabilities into the 2.6.24 kernel or just uses such a kernel and 1) is not granting cap_kill to xinit, and 2) starts X by issuing xinit on the console 3) ends after some time his X session, to come back to the console he will see a different behavior compared to 2.6.23 exiting his X session and (I think) believes to have a bug in the X package. Andrew Morton describes the problem here, too: http://lkml.org/lkml/2006/11/23/15 http://lkml.org/lkml/2006/11/23/19 Am I wrong in the assumption, but should one not accept an unchanged behavior with or without capabilities in the kernel regarding the behavior of applications, when he is not actually using (by not setting the xattr capability) capabilities with this application? If I'm wrong, maybe a warning or hint should be given that one has to grant cap_kill to xinit to come back to the console if the X session was started by xinit. Chris Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
file capabilities (ltp) tests
Just fyi, here are the ltp tests I try to use to test file capabilities.
It's a patch against the 20070430 ltp release, though it won't actually
be hooked in until i write a reliable little test for whether fscaps
are in the kernel and supported by userspace so compilation and testing
don't erroneously fail.
So for now to use this
cd ltp/testcases/kernel/security/filecaps
make noltp_check
thanks,
-serge
diff -Nrup ltp-full-20070430/runltp ltp-full-20070430-filecaps/runltp
--- ltp-full-20070430/runltp2007-04-26 13:02:48.0 +0200
+++ ltp-full-20070430-filecaps/runltp 2007-05-23 00:32:02.0 +0200
@@ -284,7 +284,8 @@ main()
${LTPROOT}/runtest/mm ${LTPROOT}/runtest/ipc \
${LTPROOT}/runtest/sched ${LTPROOT}/runtest/math \
${LTPROOT}/runtest/nptl ${LTPROOT}/runtest/pty \
- ${LTPROOT}/runtest/containers
+ ${LTPROOT}/runtest/containers \
+ ${LTPROOT}/runtest/filecaps
do
[ -a $SCENFILES ] || \
{
diff -Nrup ltp-full-20070430/runtest/filecaps
ltp-full-20070430-filecaps/runtest/filecaps
--- ltp-full-20070430/runtest/filecaps 1970-01-01 01:00:00.0 +0100
+++ ltp-full-20070430-filecaps/runtest/filecaps 2007-05-23 00:04:33.0
+0200
@@ -0,0 +1,2 @@
+#DESCRIPTION:file capabilities
+Filecaps filecapstest.sh
diff -Nrup ltp-full-20070430/testcases/kernel/security/filecaps/Makefile
ltp-full-20070430-filecaps/testcases/kernel/security/filecaps/Makefile
--- ltp-full-20070430/testcases/kernel/security/filecaps/Makefile
1970-01-01 01:00:00.0 +0100
+++ ltp-full-20070430-filecaps/testcases/kernel/security/filecaps/Makefile
2007-11-17 03:47:34.0 +0100
@@ -0,0 +1,33 @@
+CC=gcc
+
+CFLAGS += -I../../../../include -Wall
+LDLIBS += -L../../../../lib -lltp -lcap
+
+SRCS= $(wildcard *.c)
+TARGETS = $(patsubst %.c,%,$(SRCS))
+NOLTP_TARGETS = $(patsubst %.c,%_noltp,$(SRCS))
+SIGTARGETS = fcap_executable suid_executable fcapsuid_executable
+NOLTP_SIGTARGETS = fcap_executable_noltp suid_executable_noltp
fcapsuid_executable_noltp
+
+%_noltp : %.c
+ $(CC) -g -DNO_LTP -o $@ $ -lcap
+ cp plain_executable_noltp fcap_executable_noltp
+ setfcaps -c cap_sys_admin=p -e fcap_executable_noltp
+ cp plain_executable_noltp suid_executable_noltp
+ chmod u+s suid_executable_noltp
+ cp plain_executable_noltp fcapsuid_executable_noltp
+ chmod u+s fcapsuid_executable_noltp
+ setfcaps -c cap_sys_admin=p -e fcap_executable_noltp
+
+all: $(TARGETS) $(SIGTARGETS)
+
+noltp: $(NOLTP_TARGETS) $(NOLTP_SIGTARGETS)
+
+clean:
+ rm -f $(TARGETS) *.o $(NOLTP_TARGETS) caps_fifo $(SIGTARGETS)
$(NOLTP_SIGTARGETS)
+
+install:
+ @set -e; for i in $(TARGETS) $(SIGTARGETS) filecapstest.sh; do ln -f
$$i ../../../bin/$$i ; chmod +x ../../../bin/$$i; done
+
+noltp_check: noltp
+ ./runtests_noltp.sh
diff -Nrup ltp-full-20070430/testcases/kernel/security/filecaps/filecapstest.sh
ltp-full-20070430-filecaps/testcases/kernel/security/filecaps/filecapstest.sh
--- ltp-full-20070430/testcases/kernel/security/filecaps/filecapstest.sh
1970-01-01 01:00:00.0 +0100
+++
ltp-full-20070430-filecaps/testcases/kernel/security/filecaps/filecapstest.sh
2007-11-17 03:50:57.0 +0100
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+echo Running in:
+cp $LTPROOT/testcases/bin/print_caps .
+mkfifo caps_fifo
+chmod 777 caps_fifo
+exit_code=0
+echo cap_sys_admin tests
+testfilecaps 0
+tmp=$?
+if [ $tmp -ne 0 ]; then
+ exit_code=$tmp
+fi
+echo testing for correct caps
+testfilecaps 1
+tmp=$?
+if [ $tmp -ne 0 ]; then
+ exit_code=$tmp
+fi
+
+for i in `seq 1 10`; do
+ ./signals_noltp $i
+ tmp=$?
+ if [ $tmp -ne 0 ]; then
+ exit_code=$tmp;
+ fi
+done
+
+exit $exit_code
diff -Nrup
ltp-full-20070430/testcases/kernel/security/filecaps/plain_executable.c
ltp-full-20070430-filecaps/testcases/kernel/security/filecaps/plain_executable.c
--- ltp-full-20070430/testcases/kernel/security/filecaps/plain_executable.c
1970-01-01 01:00:00.0 +0100
+++
ltp-full-20070430-filecaps/testcases/kernel/security/filecaps/plain_executable.c
2007-11-17 00:24:15.0 +0100
@@ -0,0 +1,44 @@
+#define _GNU_SOURCE
+#include stdio.h
+#include unistd.h
+#include endian.h
+#include byteswap.h
+#include sys/types.h
+#include sys/stat.h
+#include sys/wait.h
+#include attr/xattr.h
+#include errno.h
+#include fcntl.h
+#include signal.h
+#include sys/capability.h
+#include sys/prctl.h
+
+#ifdef NO_LTP
+#define TFAIL FAILURE:
+#define TPASS PASS:
+#define TINFO INFO:
+#define tst_resm(x, format, arg...) printf(%s: format, x, ## arg)
+#define tst_exit(x) exit(x)
+#define TSTPATH ./print_caps_noltp
+#else
+#define TSTPATH ./print_caps
+#include test.h
+char *TCID = filecaps;
+int TST_TOTAL=1;
+#endif
+
+#define GOT_SIGNAL 1
+#define NO_SIGNAL 2
+
Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3
Quoting Chris Friedhoff ([EMAIL PROTECTED]): On Mon, 19 Nov 2007 17:16:44 -0600 Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Chris Friedhoff ([EMAIL PROTECTED]): Hello Serge, just to let you know: with 2.6.24-rc3 I have the same problem. Ok, so here is the flow. First off, using runlevel 5 on FC7, using 'log out' correctly brings you back to a new login prompt. Your problem is starting in runlevel 3, and typing 'xinit .xinitrc'; when you exit your wm, xinit is not allowed to kill X so you don't get back to your console. Yes, I'm booting in a runlevel without a session manager and starting my X session with xinit. (slackware: console-runlevel 3; sessionmanager-runlevel 4 ) First comment is, as you point out on your homepage, you could setfcaps -c cap_kill+p -e /usr/bin/xinit Then xinit is allowed to kill X. Yes xinit forks and execs a user-writable script, but of course upon the exec to start the script cap_kill is lost, so the user can't abuse this. Since you pointed this out on your homepage, I have to assume you've decided you don't want to give cap_kill to xinit? No, since I'm using capabilities and I'm very happy with it, I grant cap_kill to xinit. For myself the problem is solved ... My other question is - do we want to maintain this signal restriction? So long as a privileged process isn't dumpable, is it any more dangerous for user hallyn to kill capability-raised process owned by hallyn than it is to kill a setuid process started by hallyn? If we decide no, then maybe we should remove cap_task_kill() as well as the cap_task_setnice(), cap_task_setioprio(), cap_task_setscheduler()? Or maybe i've just forgotten a compelling scenario... thanks, -serge ... but if some user decides to configure capabilities into the 2.6.24 kernel or just uses such a kernel and 1) is not granting cap_kill to xinit, and 2) starts X by issuing xinit on the console 3) ends after some time his X session, to come back to the console he will see a different behavior compared to 2.6.23 exiting his X session and (I think) believes to have a bug in the X package. Andrew Morton describes the problem here, too: http://lkml.org/lkml/2006/11/23/15 http://lkml.org/lkml/2006/11/23/19 Am I wrong in the assumption, but should one not accept an unchanged behavior with or without capabilities in the kernel regarding the behavior of applications, when he is not actually using (by not setting the xattr capability) capabilities with this application? If I'm wrong, maybe a warning or hint should be given that one has to grant cap_kill to xinit to come back to the console if the X session was started by xinit. Thanks - yes, I see (I tend to get lost in my testruns). So we're back to trying to do the fix I was trying to do along with the SIGCONT fix a few weeks ago. The problem is that when you run a setuid binary, its pP and pE are fully raised. The following patch fixes it for me. Chris, does it fix your problem? Andrew, am I again confusing myself and doing something unsafe? thanks, -serge From d0b931776c0c424e583bf736d6a2498be4eccb98 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 08:47:35 + Subject: [PATCH 1/1] file capabilities: don't prevent signaling setuid root programs. When an unprivileged user runs a setuid root program in !SECURE_NOROOT mode, fP, fI, and fE are set full on, so pP' and pE' are full on. Then cap_task_kill() prevents the user from signaling the setuid root task. This is a change in behavior compared to when !CONFIG_SECURITY_FILE_CAPABILITIES. This patch introduces a special check into cap_task_kill() just to check whether a non-root user is signaling a setuid root program started by the same user. If so, then signal is allowed. This still leaves open the question of whether we want to go back to allowing users to signal binaries owned by them which had file capabilities set. Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED] --- security/commoncap.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/security/commoncap.c b/security/commoncap.c index 302e8d0..d20d0a6 100644 --- a/security/commoncap.c +++ b/security/commoncap.c @@ -543,6 +543,9 @@ int cap_task_kill(struct task_struct *p, struct siginfo *info, if (capable(CAP_KILL)) return 0; + if (p-euid==0 p-uid==current-uid) + return 0; + return -EPERM; } #else -- 1.5.2.5 - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] capabilities: introduce per-process capability bounding set (v8)
Quoting Andrew Morgan ([EMAIL PROTECTED]):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
Andrew, this version follows all of your suggestions. Definately nicer
userspace interface. thanks
[...]
/* Allow ioperm/iopl access */
@@ -314,6 +314,10 @@ typedef struct kernel_cap_struct {
#define CAP_SETFCAP 31
+#define CAP_NUM_CAPS 32
+
+#define cap_valid(x) ((x) = 0 (x) CAP_NUM_CAPS)
+
Could you change the name of CAP_NUM_CAPS? There is some libcap building
code that does the following to automatically build the cap_* names
for libcap, and this new define above messes that up! :-(
sed -ne '/^#define[ \t]CAP[_A-Z]\+[ \t]\+[0-9]\+/{s/^#define \([^
\t]*\)[ \t]*\([^ \t]*\)/ \{ \2, \\1\
\},/;y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/;p;}'
$(KERNEL_HEADERS)/linux/capability.h | fgrep -v 0x cap_names.sed
Something like:
#define CAP_NUM_CAPS (CAP_SETFCAP+1)
will save me some hassle. :-)
Gotcha. Will change that.
I worry that what you have is just a *touch* too busy so whoever adds
capability #32 might forget to update CAP_NUM_CAPS, but it looks like
#define CAP_LAST_CAP CAP_SETFCAP
#define cap_valid(x) ((x) = 0 (x) = CAP_LAST_CAP)
should also be ok for libcap.
[...]
/*
* Bit location of each capability (used by user-space library and kernel)
*/
@@ -350,6 +354,17 @@ typedef struct kernel_cap_struct {
#define CAP_INIT_INH_SETCAP_EMPTY_SET
Its kind of a pity to put a kernel config ifdef in a header file. Could
you put the ifdef code in the c-files that uses these definitions?
Hmm, now that you mention it, I notice that the exact same block of
code is still in commoncap.c. I must have lost the patch hunk dropping
that some time ago...
But at this point CAP_INIT_BSET is only used in
include/linux/init_task.h. And I'd really rather not put the definition
in there.
Note that the conditional is under a #ifdef __KERNEL__, so applications
shouldn't be looking at it anyway. Does that help?
+#ifdef CONFIG_SECURITY_FILE_CAPABILITIES
In my experience when headers define things differently based on
configuration #defines, other users of header files (apps, kernel
modules etc.), never quite know what the current define is. If we can
avoid conditional code like this in this header file, I'd be happier.
+#ifdef CONFIG_SECURITY_FILE_CAPABILITIES
ditto.
For this I really can't, because that is the recommended way to handle
functions with different behavior per CONFIG_ variables. #ifdefs are to
be kept out of .c files to improve their readability, and helper
functions called in .c files are to have their definition in .h files
depend on the CONFIG_ variables.
[...]
+extern long cap_prctl_drop(unsigned long cap);
+#else
+#include linux/errno.h
+static inline long cap_prctl_drop(unsigned long cap)
+{ return -EINVAL; }
+#endif
+
+long cap_prctl_drop(unsigned long cap)
+{
+ if (!capable(CAP_SETPCAP))
+ return -EPERM;
+ if (!cap_valid(cap))
+ return -EINVAL;
+ cap_lower(current-cap_bset, cap);
I think the following lines are overkill. Basically, the next exec()
will perform the pP/pE clipping, and cap_bset should only interact with
fP (and not fI).
We already have a mechanism to manipulate pI, which in turn gates fI.
And this same mechanism (libcap) can clip pE, pP if it is needed pre-exec().
So, if you want to drop a capability irrevocably, you drop it in bset,
and separately in pI. The current process may continue to have the
capability, but post-exec the working process tree has lost it. For
things like login, this is desirable.
Ok...
I think this makes sense. It seems pretty subtle and complicated, and
therefore I'm a little worried that it will be fragile against future
code changes. Someone will think it's a good idea to slightly change
the capset() semantics and only a year later will we realize that the
bounding set is no longer working...
So this will all have to be very well documented (and tested).
(Actually I notice that capabilities(7) manpage isn't in the libcap
sources. So an update to that is probably long overdue...)
This also makes it possible for you to allow pI to have a capability
otherwise banned in cap_bset which is useful with limited role accounts.
Yeah... so the way you'd see this happening, I assume, is that
1. login would keep some capset in pI for user hallyn,
2. so if /bin/foo had some nonempty fI, hallyn could run
/bin/foo with cap_intersect(pI|fI)?
So now the bounding set would place a restriction on what /bin/login in
some container could leave in hallyn's pI.
+ current-cap_effective = cap_intersect(current-cap_effective,
+ current-cap_bset);
+ current-cap_permitted = cap_intersect(current-cap_permitted,
+ current-cap_bset);
+ current-cap_inheritable =
Re: [PATCH] (2.6.24-rc3 -mm only) Smack Version 11c Simplified Mandatory Access Control Kernel
--- Casey Schaufler [EMAIL PROTECTED] wrote: From: Casey Schaufler [EMAIL PROTECTED] ... I have verified this version against broken-out-2007-11-20-01-45 as well. Compiles, boots, and passes tests. Thank you. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] (2.6.24-rc3 -mm only) Smack Version 11c Simplified Mandatory Access Control Kernel
On Tue, 20 Nov 2007 11:04:32 -0800 (PST) Casey Schaufler [EMAIL PROTECTED] wrote: --- Casey Schaufler [EMAIL PROTECTED] wrote: From: Casey Schaufler [EMAIL PROTECTED] ... I have verified this version against broken-out-2007-11-20-01-45 as well. Compiles, boots, and passes tests. So is it time for me to wake up and start paying attention again? - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] (2.6.24-rc3 -mm only) Smack Version 11c Simplified Mandatory Access Control Kernel
--- Andrew Morton [EMAIL PROTECTED] wrote: On Tue, 20 Nov 2007 11:04:32 -0800 (PST) Casey Schaufler [EMAIL PROTECTED] wrote: --- Casey Schaufler [EMAIL PROTECTED] wrote: From: Casey Schaufler [EMAIL PROTECTED] ... I have verified this version against broken-out-2007-11-20-01-45 as well. Compiles, boots, and passes tests. So is it time for me to wake up and start paying attention again? Please? I've been very attentive, polling every few hours for updates in -mm so that I can catch data structure changes early. If there are any steps I can take to be helpful or to smooth the process (grease the wheels?) let me know. Thank you. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] (2.6.24-rc3 -mm only) Smack Version 11c Simplified Mandatory Access Control Kernel
* Casey Schaufler [EMAIL PROTECTED] wrote: I have verified this version against broken-out-2007-11-20-01-45 as well. Compiles, boots, and passes tests. So is it time for me to wake up and start paying attention again? Please? I've been very attentive, polling every few hours for updates in -mm so that I can catch data structure changes early. If there are any steps I can take to be helpful or to smooth the process (grease the wheels?) let me know. Andrew just asked whether he should merge your latest. Ingo - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] (2.6.24-rc3 -mm only) Smack Version 11c Simplified Mandatory Access Control Kernel
On Mon, 19 Nov 2007 21:54:37 -0800
Casey Schaufler [EMAIL PROTECTED] wrote:
From: Casey Schaufler [EMAIL PROTECTED]
Smack is the Simplified Mandatory Access Control Kernel.
This patch seems bigger than the first version ;)
random-trivial-comments-just-to-show-i-read-it:
+static int smack_inode_setsecurity(struct inode *inode, const char *name,
+const void *value, size_t size, int flags)
+{
+ char *sp;
+ struct inode_smack *nsp = (struct inode_smack *)inode-i_security;
Please avoid casting when assigning to and from void* - it's unneeded and
defeats typechecking - if someone goes and turns inode.i_security into a
float or a struct capiloaddatapart* then we do want this code to warn about
it.
+ struct socket_smack *ssp;
+ struct socket *sock;
+
+ if (value == NULL || size SMK_LABELLEN)
+ return -EACCES;
+
+ sp = smk_import(value, size);
+ if (sp == NULL)
+ return -EINVAL;
+
+ if (strcmp(name, XATTR_SMACK_SUFFIX) == 0) {
+ mutex_lock(nsp-smk_lock);
+ nsp-smk_inode = sp;
+ mutex_unlock(nsp-smk_lock);
Does this locking actually do anything? The only place where it makes
sense is if there is some code elsewhere which reads nsp-smk_inode twice,
both instances under the same taking of -smk_lock, and in which it expects
both reads to return the same value.
IOW: it's fishy.
+ return 0;
+ }
+ /*
+ * The rest of the Smack xattrs are only on sockets.
+ */
+ if (inode-i_sb-s_magic != SOCKFS_MAGIC)
+ return -EOPNOTSUPP;
+
+ sock = SOCKET_I(inode);
+ if (sock == NULL)
+ return -EOPNOTSUPP;
+
+ ssp = sock-sk-sk_security;
+
+ if (strcmp(name, XATTR_SMACK_IPIN) == 0)
+ ssp-smk_in = sp;
+ else if (strcmp(name, XATTR_SMACK_IPOUT) == 0)
+ ssp-smk_out = sp;
+ else
+ return -EOPNOTSUPP;
+ return 0;
+}
+
...
+
+/**
+ * smack_file_set_fowner - set the file security blob value
+ * @file: object in question
+ *
+ * Returns 0
+ * Further research may be required on this one.
+ */
+static int smack_file_set_fowner(struct file *file)
+{
+ file-f_security = current-security;
+ return 0;
+}
hm. I'd have expected to see some refcounting when a ref to an object is
copied like this.
+/**
+ * smack_file_send_sigiotask - Smack on sigio
+ * @tsk: The target task
+ * @fown: the object the signal come from
+ * @signum: unused
+ *
+ * Allow a privileged task to get signals even if it shouldn't
+ *
+ * Returns 0 if a subject with the object's smack could
+ * write to the task, an error code otherwise.
+ */
+static int smack_file_send_sigiotask(struct task_struct *tsk,
+ struct fown_struct *fown, int signum)
+{
+ struct file *file;
+ int rc;
+
+ /*
+ * struct fown_struct is never outside the context of a struct file
+ */
+ file = (struct file *)((long)fown - offsetof(struct file, f_owner));
Will container_of() work here?
+ rc = smk_access(file-f_security, tsk-security, MAY_WRITE);
+ if (rc != 0 __capable(tsk, CAP_MAC_OVERRIDE))
+ return 0;
+ return rc;
+}
+
+/**
+ * smack_file_receive - Smack file receive check
+ * @file: the object
+ *
+ * Returns 0 if current has access, error code otherwise
+ */
+static int smack_file_receive(struct file *file)
+{
+ int may = 0;
+
+ /*
+ * This code relies on bitmasks.
+ */
+ if (file-f_mode FMODE_READ)
+ may = MAY_READ;
+ if (file-f_mode FMODE_WRITE)
+ may |= MAY_WRITE;
+
+ return smk_curacc(file-f_security, may);
+}
+
+/*
+ * Task hooks
+ */
+
+/**
+ * smack_task_alloc_security - allocate a task blob
+ * @tsk: the task in need of a blob
+ *
+ * Smack isn't using copies of blobs. Everyone
+ * points to an immutible list. No alloc required.
+ * No data copy required.
I guess that answers my refcounting question above.
Spello: immutable.
+ * Always returns 0
+ */
+static int smack_task_alloc_security(struct task_struct *tsk)
+{
+ tsk-security = current-security;
+
+ return 0;
+}
+
+/**
+ * smack_task_free_security - free a task blob
+ * @task: the task with the blob
+ *
+ * Smack isn't using copies of blobs. Everyone
+ * points to an immutible list. The blobs never go away.
+ * There is no leak here.
Thoroughly answered.
Ditto on the spello tho.
+ */
+static void smack_task_free_security(struct task_struct *task)
+{
+ task-security = NULL;
+}
+
...
+static int smack_task_kill(struct task_struct *p, struct siginfo *info,
+int sig, u32 secid)
+{
+ /*
+ * Special cases where signals really ought to go through
+ * in spite of policy. Stephen Smalley suggests it may
+ * make sense to change the caller so
Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3
On Tue, 20 Nov 2007 08:51:06 -0600 Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Chris Friedhoff ([EMAIL PROTECTED]): On Mon, 19 Nov 2007 17:16:44 -0600 Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Chris Friedhoff ([EMAIL PROTECTED]): Hello Serge, just to let you know: with 2.6.24-rc3 I have the same problem. Ok, so here is the flow. First off, using runlevel 5 on FC7, using 'log out' correctly brings you back to a new login prompt. Your problem is starting in runlevel 3, and typing 'xinit .xinitrc'; when you exit your wm, xinit is not allowed to kill X so you don't get back to your console. Yes, I'm booting in a runlevel without a session manager and starting my X session with xinit. (slackware: console-runlevel 3; sessionmanager-runlevel 4 ) First comment is, as you point out on your homepage, you could setfcaps -c cap_kill+p -e /usr/bin/xinit Then xinit is allowed to kill X. Yes xinit forks and execs a user-writable script, but of course upon the exec to start the script cap_kill is lost, so the user can't abuse this. Since you pointed this out on your homepage, I have to assume you've decided you don't want to give cap_kill to xinit? No, since I'm using capabilities and I'm very happy with it, I grant cap_kill to xinit. For myself the problem is solved ... My other question is - do we want to maintain this signal restriction? So long as a privileged process isn't dumpable, is it any more dangerous for user hallyn to kill capability-raised process owned by hallyn than it is to kill a setuid process started by hallyn? If we decide no, then maybe we should remove cap_task_kill() as well as the cap_task_setnice(), cap_task_setioprio(), cap_task_setscheduler()? Or maybe i've just forgotten a compelling scenario... thanks, -serge ... but if some user decides to configure capabilities into the 2.6.24 kernel or just uses such a kernel and 1) is not granting cap_kill to xinit, and 2) starts X by issuing xinit on the console 3) ends after some time his X session, to come back to the console he will see a different behavior compared to 2.6.23 exiting his X session and (I think) believes to have a bug in the X package. Andrew Morton describes the problem here, too: http://lkml.org/lkml/2006/11/23/15 http://lkml.org/lkml/2006/11/23/19 Am I wrong in the assumption, but should one not accept an unchanged behavior with or without capabilities in the kernel regarding the behavior of applications, when he is not actually using (by not setting the xattr capability) capabilities with this application? If I'm wrong, maybe a warning or hint should be given that one has to grant cap_kill to xinit to come back to the console if the X session was started by xinit. Thanks - yes, I see (I tend to get lost in my testruns). So we're back to trying to do the fix I was trying to do along with the SIGCONT fix a few weeks ago. The problem is that when you run a setuid binary, its pP and pE are fully raised. The following patch fixes it for me. Chris, does it fix your problem? Yes, this patch fixes it for me, too. Thanks, Chris Andrew, am I again confusing myself and doing something unsafe? thanks, -serge From d0b931776c0c424e583bf736d6a2498be4eccb98 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 08:47:35 + Subject: [PATCH 1/1] file capabilities: don't prevent signaling setuid root programs. When an unprivileged user runs a setuid root program in !SECURE_NOROOT mode, fP, fI, and fE are set full on, so pP' and pE' are full on. Then cap_task_kill() prevents the user from signaling the setuid root task. This is a change in behavior compared to when !CONFIG_SECURITY_FILE_CAPABILITIES. This patch introduces a special check into cap_task_kill() just to check whether a non-root user is signaling a setuid root program started by the same user. If so, then signal is allowed. This still leaves open the question of whether we want to go back to allowing users to signal binaries owned by them which had file capabilities set. Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED] --- security/commoncap.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/security/commoncap.c b/security/commoncap.c index 302e8d0..d20d0a6 100644 --- a/security/commoncap.c +++ b/security/commoncap.c @@ -543,6 +543,9 @@ int cap_task_kill(struct task_struct *p, struct siginfo *info, if (capable(CAP_KILL)) return 0; + if (p-euid==0 p-uid==current-uid) + return 0; + return -EPERM; } #else -- 1.5.2.5 Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More
Re: [PATCH] 64bit capability support (legacy support fix)
On Sat, 17 Nov 2007 21:25:27 -0800 Andrew Morgan [EMAIL PROTECTED] wrote: The attached patch (171282b3553fcec43b9ab615eb7daf6c2b494a87) applies against 2.6.24-rc2-mm1. It addresses the problem reported by Kevin and Andy - ultimately, the legacy support wasn't transparent. In particular, userspace 32-bit capability manipulations (when run by root) that used to work, without this patch, fail. My venerable FC1 machine says warning: process `zsh' gets w/ old libcap warning: process `zsh' gets w/ old libcap warning: process `zsh' gets w/ old libcap should I be scared? - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
