From: Bernhard Kaindl <email@example.com>
To: Arjan van de Ven <firstname.lastname@example.org>
Cc: Nuno Silva <email@example.com>,
Yusuf Wilajati Purna <firstname.lastname@example.org>,
Marcelo Tosatti <email@example.com>,
Subject: Re: [PATCH][2.4+ptrace] fix side effects of the kmod/ptrace secfix
Date: Thu, 24 Apr 2003 13:26:11 +0200 [thread overview]
Message-ID: <Pine.LNX.firstname.lastname@example.org> (raw)
On Thu, 24 Apr 2003, Arjan van de Ven wrote:
> On Thu, Apr 24, 2003 at 06:40:55AM +0100, Nuno Silva wrote:
> > Good morning! :)
> > I'd like to ear an "official" word on this subject, please. :)
> > Is this patch still secure?
> The check is loosend too much.
Last month, you sounded different:
On 2003-03-22 17:28:54, Arjan van de Ven wrote:
>On Sat, Mar 22, 2003 at 05:13:12PM +0000, Russell King wrote:
>> int ptrace_check_attach(struct task_struct *child, int kill)
>> + if (!is_dumpable(child))
>> + return -EPERM;
>> So, we went from being able to ptrace daemons as root, to being able to
>> attach daemons and then being unable to do anything with them, even if
>> you're root (or have the CAP_SYS_PTRACE capability). I think this
>> behaviour is getting on for being described as "insane" 8) and is
>> clearly wrong.
>ok it seems this check is too strong. It *has* to check
>child->task_dumpable and return -EPERM, but child->mm->dumpable is not
Can you give me an explanation that changed with regard to the
Im private discussuion this possible scenario has been brought up:
> execed setuid
> opens RAW_SOCKET
> setuid back
AFAICS, ptrace_attach() will abort, because the "setuid back" does
not set mm->dumpable back to 1, it is left at 0 and ptrace_attach()
Of course you could do an exec() to get a new mm and then, you may
get an mm->dumpable is set != 0.
But especially in the case of an exec() I think the setuid program
should not go back to the original uid because the user may send
any signal it wants to the suid program then, read it's environment
and do all other sorts of bad stuff e.g. if the program is stupid
enough to not use a safe directory for temp files and such.
If we really need to protect such (IMHO insecure) progam to be
somewhat more secure, we could inherit task_dumpable over exec's,
but I'm not sure what kind of side effects whis would have when
using programs like su and login...
I think by adding such workarounds which are unrelated to kmod,
we would introduce more unwanted side effects insted of fixing
what we alread have because of too strong checks.
next prev parent reply other threads:[~2003-04-24 12:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-17 5:46 2.4+ptrace exploit fix breaks root's ability to strace Yusuf Wilajati Purna
2003-04-19 5:57 ` Bernhard Kaindl
2003-04-22 5:03 ` Yusuf Wilajati Purna
2003-04-22 22:30 ` [PATCH][2.4+ptrace] fix side effects of the kmod/ptrace secfix Bernhard Kaindl
2003-04-24 5:40 ` Nuno Silva
2003-04-24 9:00 ` Arjan van de Ven
2003-04-24 11:26 ` Bernhard Kaindl [this message]
2003-04-24 22:37 Andreas Gietl
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).