[PATCH] ptrace: it is fun to strace /sbin/init - Kernel

This is a discussion on [PATCH] ptrace: it is fun to strace /sbin/init - Kernel ; On Tue, 2008-03-25 at 08:40 -0500, Serge E. Hallyn wrote: > Quoting Stephen Smalley (sds@tycho.nsa.gov): > > > > On Tue, 2008-03-25 at 02:04 +0300, Oleg Nesterov wrote: > > > On 03/24, Pavel Machek wrote: > > > > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 31 of 31

Thread: [PATCH] ptrace: it is fun to strace /sbin/init

  1. Re: [PATCH] ptrace: it is fun to strace /sbin/init


    On Tue, 2008-03-25 at 08:40 -0500, Serge E. Hallyn wrote:
    > Quoting Stephen Smalley (sds@tycho.nsa.gov):
    > >
    > > On Tue, 2008-03-25 at 02:04 +0300, Oleg Nesterov wrote:
    > > > On 03/24, Pavel Machek wrote:
    > > > >
    > > > > > /sbin/init is important, but there are other important (and sometimes
    > > > > > much more important) services. Why it is so special so that we can't
    > > > > > debug/strace it?
    > > > >
    > > > > Maybe. Let's kill /sbin/init protection in 2.6.26. But making it
    > > > > optional is wrong.
    > > >
    > > > You are right, the boot parameter is silly. How about sysctl?
    > > >
    > > > Stephen, do you see any security problems if we make /sbin/init
    > > > ptraceable by default?

    > >
    > > Not an issue for SELinux (we apply an orthogonal check based on security
    > > context, so we can already block ptrace of init independent of whether
    > > root/CAP_SYS_PTRACE can do it). I'm not sure though as to whether
    > > people using capabilities have ever relied on this special protection of
    > > init (e.g. custom init spawns children with lesser capabilities and
    > > relies on the fact that they cannot ptrace init to effectively re-gain
    > > those capabilities, even if they possess CAP_SYS_PTRACE).

    >
    > Still thinking it through, but it seems like special casing init isn't
    > useful. There are likely to be other tasks with all capabilities
    > set which the malicious task could just as well ptrace to do his
    > mischief, right?


    Depends on the bounding set. Didn't it used to be the case that only
    init had CAP_SETPCAP (until the meaning of it was changed by the
    filesystem capability support)?

    Might want to double check with e.g. the vservers folks that they
    weren't relying in any way on special handling of init.

    --
    Stephen Smalley
    National Security Agency

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

  2. Re: [PATCH] ptrace: it is fun to strace /sbin/init

    Hi!

    > > > I like the general idea -- i used to patch kernels to allow this too,
    > > > but it is dangerous.

    > >
    > > Though root-only. Root doesn't want to be limited and knows better
    > > anyway.

    >
    > The problem is that you can deadlock if you are not very careful.


    How is that different from ptracing any other process with _lot_ of
    children -- like X? You'll get same zombies in both cases, leading to
    same issues, no?

    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
    --
    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/

  3. Re: [PATCH] ptrace: it is fun to strace /sbin/init

    Andi Kleen writes:

    > Sure, but if the deadlocks can be avoided on the kernel level (just
    > making sure the children are already reaped) then it would be even
    > better.


    Well, if you mean the kernel would do that unconditionally (thus it
    won't be init's job anymore, ptrace or not) then I can only agree.
    --
    Krzysztof Halasa
    --
    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/

  4. Re: [PATCH] ptrace: it is fun to strace /sbin/init

    On Tue, Mar 25, 2008 at 03:47:54PM +0100, Pavel Machek wrote:
    > Hi!
    >
    > > > > I like the general idea -- i used to patch kernels to allow this too,
    > > > > but it is dangerous.
    > > >
    > > > Though root-only. Root doesn't want to be limited and knows better
    > > > anyway.

    > >
    > > The problem is that you can deadlock if you are not very careful.

    >
    > How is that different from ptracing any other process with _lot_ of
    > children -- like X? You'll get same zombies in both cases, leading to
    > same issues, no?


    There is no unresolvable deadlock no.

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

  5. Re: [PATCH] ptrace: it is fun to strace /sbin/init

    On 03/25, Andi Kleen wrote:
    >
    > Andrew Morton writes:
    > >
    > > Why not just unconditionally enable root's abiltiy to ptrace init?

    >
    > It would be fine to allow this unconditionally if there was some mechanism
    > to make sure someone else takes over reaping childs while init is ptraced.


    I think we can't do this. From my /etc/inittab:

    c1:1235:respawn:/sbin/agetty 38400 tty1 linux

    If /sbin/agetty exits, we shouldn't reap it. /sbin/init should notice
    the death of login, and respawn the new child.

    Thanks to all for replies! I'll re-send this patch as one-liner, without
    any boot params or sysctls, and with long CC list.

    I hope someone (not me) will make a final authoritative decision

    Oleg.

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

  6. Re: [PATCH] ptrace: it is fun to strace /sbin/init

    Quoting Stephen Smalley (sds@tycho.nsa.gov):
    >
    > On Tue, 2008-03-25 at 08:40 -0500, Serge E. Hallyn wrote:
    > > Quoting Stephen Smalley (sds@tycho.nsa.gov):
    > > >
    > > > On Tue, 2008-03-25 at 02:04 +0300, Oleg Nesterov wrote:
    > > > > On 03/24, Pavel Machek wrote:
    > > > > >
    > > > > > > /sbin/init is important, but there are other important (and sometimes
    > > > > > > much more important) services. Why it is so special so that we can't
    > > > > > > debug/strace it?
    > > > > >
    > > > > > Maybe. Let's kill /sbin/init protection in 2.6.26. But making it
    > > > > > optional is wrong.
    > > > >
    > > > > You are right, the boot parameter is silly. How about sysctl?
    > > > >
    > > > > Stephen, do you see any security problems if we make /sbin/init
    > > > > ptraceable by default?
    > > >
    > > > Not an issue for SELinux (we apply an orthogonal check based on security
    > > > context, so we can already block ptrace of init independent of whether
    > > > root/CAP_SYS_PTRACE can do it). I'm not sure though as to whether
    > > > people using capabilities have ever relied on this special protection of
    > > > init (e.g. custom init spawns children with lesser capabilities and
    > > > relies on the fact that they cannot ptrace init to effectively re-gain
    > > > those capabilities, even if they possess CAP_SYS_PTRACE).

    > >
    > > Still thinking it through, but it seems like special casing init isn't
    > > useful. There are likely to be other tasks with all capabilities
    > > set which the malicious task could just as well ptrace to do his
    > > mischief, right?

    >
    > Depends on the bounding set. Didn't it used to be the case that only
    > init had CAP_SETPCAP (until the meaning of it was changed by the
    > filesystem capability support)?


    Not quite. CAP_SETPCAP was taken out of everyone's bounding set. But
    kernel/sysctl.c allowed only init to add capabilities to the bounding
    set. (Whereas CAP_SYS_MODULE was sufficient to remove them).

    > Might want to double check with e.g. the vservers folks that they
    > weren't relying in any way on special handling of init.


    Herbert, Pavel, do you have objections to allowing ptrace of init?
    (I believe Eric has already Acked the idea iirc?)

    thanks,
    -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/

  7. Re: [PATCH] ptrace: it is fun to strace /sbin/init

    On Tue, Mar 25, 2008 at 01:06:11PM -0500, Serge E. Hallyn wrote:
    > Quoting Stephen Smalley (sds@tycho.nsa.gov):
    > >
    > > On Tue, 2008-03-25 at 08:40 -0500, Serge E. Hallyn wrote:
    > > > Quoting Stephen Smalley (sds@tycho.nsa.gov):
    > > > >
    > > > > On Tue, 2008-03-25 at 02:04 +0300, Oleg Nesterov wrote:
    > > > > > On 03/24, Pavel Machek wrote:
    > > > > > >
    > > > > > > > /sbin/init is important, but there are other important (and sometimes
    > > > > > > > much more important) services. Why it is so special so that we can't
    > > > > > > > debug/strace it?
    > > > > > >
    > > > > > > Maybe. Let's kill /sbin/init protection in 2.6.26. But making it
    > > > > > > optional is wrong.
    > > > > >
    > > > > > You are right, the boot parameter is silly. How about sysctl?
    > > > > >
    > > > > > Stephen, do you see any security problems if we make /sbin/init
    > > > > > ptraceable by default?
    > > > >
    > > > > Not an issue for SELinux (we apply an orthogonal check based on security
    > > > > context, so we can already block ptrace of init independent of whether
    > > > > root/CAP_SYS_PTRACE can do it). I'm not sure though as to whether
    > > > > people using capabilities have ever relied on this special protection of
    > > > > init (e.g. custom init spawns children with lesser capabilities and
    > > > > relies on the fact that they cannot ptrace init to effectively re-gain
    > > > > those capabilities, even if they possess CAP_SYS_PTRACE).
    > > >
    > > > Still thinking it through, but it seems like special casing init isn't
    > > > useful. There are likely to be other tasks with all capabilities
    > > > set which the malicious task could just as well ptrace to do his
    > > > mischief, right?

    > >
    > > Depends on the bounding set. Didn't it used to be the case that only
    > > init had CAP_SETPCAP (until the meaning of it was changed by the
    > > filesystem capability support)?

    >
    > Not quite. CAP_SETPCAP was taken out of everyone's bounding set. But
    > kernel/sysctl.c allowed only init to add capabilities to the bounding
    > set. (Whereas CAP_SYS_MODULE was sufficient to remove them).
    >
    > > Might want to double check with e.g. the vservers folks that they
    > > weren't relying in any way on special handling of init.

    >
    > Herbert, Pavel, do you have objections to allowing ptrace of init?
    > (I believe Eric has already Acked the idea iirc?)


    inside a guest, by default no (i.e. there simply is
    no capability for that), on the host the behaviour is
    unmodified .. note that there are guests without init
    where the blend through init is protected in a special
    way

    HTH,
    Herbert

    > thanks,
    > -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/

  8. Re: [PATCH] ptrace: it is fun to strace /sbin/init

    Hi!

    > > Might want to double check with e.g. the vservers folks that they
    > > weren't relying in any way on special handling of init.

    >
    > Herbert, Pavel, do you have objections to allowing ptrace of init?
    > (I believe Eric has already Acked the idea iirc?)


    No problem from me...

    (..but do not introduce command line option or sysctl. It is not worth it).

    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
    pomozte zachranit klanovicky les: http://www.ujezdskystrom.info/
    --
    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/

  9. Re: [PATCH] ptrace: it is fun to strace /sbin/init

    > It would be fine to allow this unconditionally if there was some mechanism
    > to make sure someone else takes over reaping childs while init is ptraced.


    I don't see why this particular issue is any special case. The zombie leak
    is just one of many ways that the system might become unusable if root does
    the wrong thing to an essential system daemon. Caveat superusor. Diddling
    with init on a system you expect ever to do anything again is dangerous and
    requires great care. The question of allowing an administrator to engage
    in dangerous activities is orthogonal to the details of a particular danger.

    With today's kernel, init can avoid any reparented zombies collecting if it
    doesn't care about its own children either. That is, it can ignore SIGCHLD
    or set SA_NOCLDWAIT to make all its children clean themselves up. That
    doesn't help for a normal init, which does care (for respawn and logging).
    (Also it's never been tried, and I'm almost sure it has a bug. But that's
    supposed to be the semantics.)

    That said, the orthogonal question of orphan zombies may well be worth
    addressing too. Just let's not conflate it with the ptrace question.
    (AFAIK there is no good reason not to make orphans just self-reap, it's
    just hysterical raisins inherited from the dawn of Unix. I'm sure that
    Oleg and I can work out the cleanups, but in a separate thread please.)


    Thanks,
    Roland
    --
    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/

  10. Re: [PATCH] ptrace: it is fun to strace /sbin/init

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    FWIW. I completely concur.

    Pavel Machek wrote:
    |> Herbert, Pavel, do you have objections to allowing ptrace of init?
    |> (I believe Eric has already Acked the idea iirc?)
    |
    | No problem from me...
    |
    | (..but do not introduce command line option or sysctl. It is not worth
    it).

    Cheers

    Andrew
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFH6mw8+bHCR3gb8jsRAsKjAJ40JnoyrqGzgIZPgz5gv9 uqeeiZ1wCdFKSv
    snEU/yiVdWQ4cGSwbU3A8Hg=
    =xArK
    -----END PGP SIGNATURE-----
    --
    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/

  11. Re: [PATCH] ptrace: it is fun to strace /sbin/init

    [snip]

    > Herbert, Pavel, do you have objections to allowing ptrace of init?
    > (I believe Eric has already Acked the idea iirc?)


    I 100% agree with the patch.

    And I always say this to Oleg about all his patches

    > thanks,
    > -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/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2