Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3

[Serge E. Hallyn]

Quoting Chris Friedhoff (chris@xxxxxxxxxxxxx):
> On Mon, 19 Nov 2007 17:16:44 -0600
> "Serge E. Hallyn" <sergeh@xxxxxxxxxx> wrote:
> 
> > Quoting Chris Friedhoff (chris@xxxxxxxxxxxxx):
> > > 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