Hello,
everything works as expected, but ...
closing X and no capabilities set for xinit does shutdown only the
windowmanager and not the X server (Xorg server 1.4)
Consolemessage is:
xinit: Operation not permitted (errno 1): Can't kill X server
the xattr capability is removed, when the file is chown'ed.
Chris
--------------------
Chris Friedhoff
[email protected]
Quoting Chris Friedhoff ([email protected]):
> Hello,
>
> everything works as expected, but ...
>
> closing X and no capabilities set for xinit does shutdown only the
> windowmanager and not the X server (Xorg server 1.4)
> Consolemessage is:
> xinit: Operation not permitted (errno 1): Can't kill X server
>
>
> the xattr capability is removed, when the file is chown'ed.
Hi Chris,
yes on chown the capability is removed. I'm not quite sure what
you're asking? Is your setup depending on being able to chown
while keeping file capabilities? Can you give some more details?
thanks,
-serge
Hello Serge,
I wanted only to express what I observed.
A "yes it should" confirms its ok.
And yes, I haven't looked into the patches and the name and commentary
of file-capabilities-clear-fcaps-on-inode-change.patch explains this
already.
I'm preparing to update my page http://www.friedhoff.org/fscaps.html
for 2.6.24, and I also want to explain what one has to take into account
or be beware off. If I stumble about this, I think others will also
(imho).
I have written a script to change suid binaries and servers,
automating the examples I give on the webpage.
In the sequence of commands I was setting fscaps and than chown the
binary. Now with the aforementioned patch the fscaps are removed when
I chown and the script wasn't working anymore. My point is not my
script, it's being surprised and being a bit at a loss. Documenting
this helps to clarify things and users to adopt this feature.
The matter with "xinit: Operation not permitted..." happens, when I
(unprivileged user) close a from a console started X session. Similar to
Andrew Morton'S http://lkml.org/lkml/2006/11/23/15 . The 2.6.24-rc2
kernel has capabilties enabled but /usr/bin/xinit has no capabilities
set. It remains the black screen with a cursor, the windowmanager is
closed. Is this known? Is this a problem? Does anyone else observes
this?
As far as I understand, I dont have to grant / to use capabilities even
when the kernel has capabilities enabled.
Chris
On Tue, 13 Nov 2007 17:53:18 -0600
"Serge E. Hallyn" <[email protected]> wrote:
> Quoting Chris Friedhoff ([email protected]):
> > Hello,
> >
> > everything works as expected, but ...
> >
> > closing X and no capabilities set for xinit does shutdown only the
> > windowmanager and not the X server (Xorg server 1.4)
> > Consolemessage is:
> > xinit: Operation not permitted (errno 1): Can't kill X server
> >
> >
> > the xattr capability is removed, when the file is chown'ed.
>
> Hi Chris,
>
> yes on chown the capability is removed. I'm not quite sure what
> you're asking? Is your setup depending on being able to chown
> while keeping file capabilities? Can you give some more details?
>
> thanks,
> -serge
--------------------
Chris Friedhoff
[email protected]
Quoting Chris Friedhoff ([email protected]):
> Hello Serge,
>
> I wanted only to express what I observed.
>
> A "yes it should" confirms its ok.
>
> And yes, I haven't looked into the patches and the name and commentary
> of file-capabilities-clear-fcaps-on-inode-change.patch explains this
> already.
> I'm preparing to update my page http://www.friedhoff.org/fscaps.html
> for 2.6.24, and I also want to explain what one has to take into account
> or be beware off. If I stumble about this, I think others will also
> (imho).
>
> I have written a script to change suid binaries and servers,
> automating the examples I give on the webpage.
Cool, sounds very useful.
> In the sequence of commands I was setting fscaps and than chown the
> binary. Now with the aforementioned patch the fscaps are removed when
> I chown and the script wasn't working anymore. My point is not my
> script, it's being surprised and being a bit at a loss. Documenting
> this helps to clarify things and users to adopt this feature.
>
>
> The matter with "xinit: Operation not permitted..." happens, when I
> (unprivileged user) close a from a console started X session. Similar to
> Andrew Morton'S http://lkml.org/lkml/2006/11/23/15 . The 2.6.24-rc2
> kernel has capabilties enabled but /usr/bin/xinit has no capabilities
> set. It remains the black screen with a cursor, the windowmanager is
> closed. Is this known? Is this a problem? Does anyone else observes
> this?
I'm setting up a vm to play with this. Will look into it.
Oh, looking at a few branches, I see that the patch for bug# 9247
(on bugzilla.kernel.org) isn't in 2.6.24-rc2 yet. Can you check
whether the following patch fixes it?
thanks,
-serge
>From 347faf5852644b91632813885784104f4cdb640a Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <[email protected]>
Date: Wed, 14 Nov 2007 13:00:52 -0500
Subject: [PATCH 1/1] file capabilities: allow sigcont within session (v2.6.24-rc2)
Allow sigcont to be sent to a process with greater capabilities
if it is in the same session. Otherwise, a shell from which
I've started a root shell and done 'suspend' can't be restarted
by the parent shell.
(this patch against v2.6.24-rc2)
Signed-off-by: Serge E. Hallyn <[email protected]>
---
security/commoncap.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/security/commoncap.c b/security/commoncap.c
index bf67871..c9f6867 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -534,6 +534,8 @@ int cap_task_kill(struct task_struct *p, struct siginfo *info,
* Used only by usb drivers?
*/
return 0;
+ if (sig == SIGCONT && (task_session_nr(current)==task_session_nr(p)))
+ return 0;
if (cap_issubset(p->cap_permitted, current->cap_permitted))
return 0;
if (capable(CAP_KILL))
--
1.5.1.1.GIT
No, the patch doesn't fix the problem.
I still have the black screen with the cursor when I close the
xsession, only the windowmanager is closed.
consolemessage:
xinit: Operation not permitted (errno 1): Can't kill X server
kernel has capabilities, xinit has no caps granted.
Chris
> I'm setting up a vm to play with this. Will look into it.
>
> Oh, looking at a few branches, I see that the patch for bug# 9247
> (on bugzilla.kernel.org) isn't in 2.6.24-rc2 yet. Can you check
> whether the following patch fixes it?
>
> thanks,
> -serge
>
> >From 347faf5852644b91632813885784104f4cdb640a Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <[email protected]>
> Date: Wed, 14 Nov 2007 13:00:52 -0500
> Subject: [PATCH 1/1] file capabilities: allow sigcont within session (v2.6.24-rc2)
>
> Allow sigcont to be sent to a process with greater capabilities
> if it is in the same session. Otherwise, a shell from which
> I've started a root shell and done 'suspend' can't be restarted
> by the parent shell.
>
> (this patch against v2.6.24-rc2)
>
> Signed-off-by: Serge E. Hallyn <[email protected]>
> ---
> security/commoncap.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/security/commoncap.c b/security/commoncap.c
> index bf67871..c9f6867 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -534,6 +534,8 @@ int cap_task_kill(struct task_struct *p, struct siginfo *info,
> * Used only by usb drivers?
> */
> return 0;
> + if (sig == SIGCONT && (task_session_nr(current)==task_session_nr(p)))
> + return 0;
> if (cap_issubset(p->cap_permitted, current->cap_permitted))
> return 0;
> if (capable(CAP_KILL))
> --
> 1.5.1.1.GIT
--------------------
Chris Friedhoff
[email protected]
Hello Serge,
just to let you know: with 2.6.24-rc3 I have the same problem.
Chris
On Thu, 15 Nov 2007 23:02:27 +0100
Chris Friedhoff <[email protected]> wrote:
> No, the patch doesn't fix the problem.
> I still have the black screen with the cursor when I close the
> xsession, only the windowmanager is closed.
> consolemessage:
> xinit: Operation not permitted (errno 1): Can't kill X server
> kernel has capabilities, xinit has no caps granted.
>
> Chris
>
>
> > I'm setting up a vm to play with this. Will look into it.
> >
> > Oh, looking at a few branches, I see that the patch for bug# 9247
> > (on bugzilla.kernel.org) isn't in 2.6.24-rc2 yet. Can you check
> > whether the following patch fixes it?
> >
> > thanks,
> > -serge
> >
> > >From 347faf5852644b91632813885784104f4cdb640a Mon Sep 17 00:00:00 2001
> > From: Serge E. Hallyn <[email protected]>
> > Date: Wed, 14 Nov 2007 13:00:52 -0500
> > Subject: [PATCH 1/1] file capabilities: allow sigcont within session (v2.6.24-rc2)
> >
> > Allow sigcont to be sent to a process with greater capabilities
> > if it is in the same session. Otherwise, a shell from which
> > I've started a root shell and done 'suspend' can't be restarted
> > by the parent shell.
> >
> > (this patch against v2.6.24-rc2)
> >
> > Signed-off-by: Serge E. Hallyn <[email protected]>
> > ---
> > security/commoncap.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/security/commoncap.c b/security/commoncap.c
> > index bf67871..c9f6867 100644
> > --- a/security/commoncap.c
> > +++ b/security/commoncap.c
> > @@ -534,6 +534,8 @@ int cap_task_kill(struct task_struct *p, struct siginfo *info,
> > * Used only by usb drivers?
> > */
> > return 0;
> > + if (sig == SIGCONT && (task_session_nr(current)==task_session_nr(p)))
> > + return 0;
> > if (cap_issubset(p->cap_permitted, current->cap_permitted))
> > return 0;
> > if (capable(CAP_KILL))
> > --
> > 1.5.1.1.GIT
>
>
> --------------------
> Chris Friedhoff
> [email protected]
--------------------
Chris Friedhoff
[email protected]
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.
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?
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
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]
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 +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 <[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
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 +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 <[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]
Quoting Chris Friedhoff ([email protected]):
> 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
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
On Tue, 20 Nov 2007 16:51:21 -0600
"Serge E. Hallyn" <[email protected]> wrote:
> Quoting Chris Friedhoff ([email protected]):
> > 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
>
> Thanks for the valuable testing and bugreports, Chris.
You're welcome!
Chris
>
> If I don't hear any counter-arguments I'll post the patch in its own
> thread tomorrow.
>
> -serge
--------------------
Chris Friedhoff
[email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Serge E. Hallyn wrote:
> 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?
I think this is yet another example of the fragile mess that is UID
emulation with capabilities. Your patch is an example of privilege
escalation - luser can kill a more-capable process. In the kill CONT
case we reached the opposite conclusion to this one. As was the case
then, I didn't disagree then :*). If it meets folk's expectations, then
this is probably a good patch...
> --- 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;
> +
Its late and I'm obviously tired, but is there any reason not to simply use:
if (p->uid == current->uid)
return 0;
Whatever the case, could you put the new code closer to the sig ==
SIGCONT test? The capability tests are at the end of cap_task_kill() and
this new check breaks that pattern.
Cheers
Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFHRTLlQheEq9QabfIRAt/hAKCJgj2kbuyAWI486LOwwDLdkbcpoQCfQdrQ
J+bcvi+9pGTodFn42PsHJHA=
=cXaG
-----END PGP SIGNATURE-----