| 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
| ||
|
Message-ID: <20071120145106.GA6641@sergelap.austin.ibm.com> Date: Tue, 20 Nov 2007 08:51:06 -0600 From: "Serge E. Hallyn" <serue@...ibm.com> To: Chris Friedhoff <chris@...edhoff.org> Cc: Serge E Hallyn <sergeh@...ibm.com>, linux-security-module@...r.kernel.org, Stephen Smalley <sds@...ch.ncsc.mil>, Andrew Morgan <morgan@...nel.org>, Chris Wright <chrisw@...s-sol.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3 Quoting Chris Friedhoff (chris@...edhoff.org): > On Mon, 19 Nov 2007 17:16:44 -0600 > "Serge E. Hallyn" <sergeh@...ibm.com> wrote: > > > Quoting Chris Friedhoff (chris@...edhoff.org): > > > 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 <serue@...ibm.com> Date: Tue, 20 Nov 2007 08:47:35 +0000 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 <serue@...ibm.com> --- 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-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/
Powered by blists - more mailing lists