lkml.org 
[lkml]   [2007]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3
    Quoting Chris Friedhoff (chris@friedhoff.org):
    > On Tue, 20 Nov 2007 08:51:06 -0600
    > "Serge E. Hallyn" <serue@us.ibm.com> wrote:
    >
    > > Quoting Chris Friedhoff (chris@friedhoff.org):
    > > > On Mon, 19 Nov 2007 17:16:44 -0600
    > > > "Serge E. Hallyn" <sergeh@us.ibm.com> wrote:
    > > >
    > > > > Quoting Chris Friedhoff (chris@friedhoff.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

    Thanks for the valuable testing and bugreports, Chris.

    If I don't hear any counter-arguments I'll post the patch in its own
    thread tomorrow.

    -serge
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-11-20 23:53    [W:0.028 / U:91.436 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site