Message-Id: <20071120232905.8029ec46.chris@friedhoff.org>
Date:	Tue, 20 Nov 2007 23:29:05 +0100
From:	Chris Friedhoff <chris@...edhoff.org>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	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>,
	"chris@...edhoff.org" <chris@...edhoff.org>
Subject: 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" <serue@...ibm.com> wrote:

> 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?

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


--------------------
Chris Friedhoff
chris@...edhoff.org
-
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