All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olaf Dietsche <olaf.dietsche#list.linux-kernel@t-online.de>
To: <chris@scary.beasts.org>
Cc: <linux-kernel@vger.kernel.org>, <drepper@redhat.com>, <agruen@suse.de>
Subject: Re: [PATCH][RFC] 2.5.44 (1/2): Filesystem capabilities kernel patch
Date: Tue, 29 Oct 2002 12:08:31 +0100	[thread overview]
Message-ID: <87smypmrio.fsf@goat.bogus.local> (raw)
In-Reply-To: 877kg2njbi.fsf@goat.bogus.local

Olaf Dietsche <olaf.dietsche#list.linux-kernel@t-online.de> writes:

> Olaf Dietsche <olaf.dietsche#list.linux-kernel@t-online.de> writes:
>
>> <chris@scary.beasts.org> writes:
>>
>>> On Mon, 28 Oct 2002, Olaf Dietsche wrote:
>>>
>>>> If you're careful with giving away capabilities however, this patch
>>>> can make your system more secure as it is. But this isn't fully
>>>> explored, so you might achieve the opposite and open new security
>>>> holes.
>
> Famous last words :-(
>
>>>
>>> Have you checked how glibc handles an executable with filesystem
>>> capabilities? e.g. can an LD_PRELOAD hack subvert the privileged
>>> executable?
>>
>> No, I didn't check. Thanks for this hint, I will look into this.

Executables with inheritable sets only are not affected. A regular
user may use LD_PRELOAD, but he is not able to gain additional
privileges.

> I just downloaded glibc 2.3.1 and would say you can subvert a
> privileged executable with LD_PRELOAD. There's no mention of
> PR_GET_DUMPABLE anywhere and __libc_enable_secure is set according to
> some euid/egid tests.

This means setting the executable to SGID nogroup or a similar hack
would close at least some of the security holes for now.

Regards, Olaf.

  reply	other threads:[~2002-10-29 11:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-18 19:07 [PATCH][RFC] 2.5.42 (1/2): Filesystem capabilities kernel patch Olaf Dietsche
2002-10-18 23:00 ` Alexander Viro
2002-10-19  0:07   ` Olaf Dietsche
2002-10-19  0:25     ` Alexander Viro
2002-10-24 12:25       ` [PATCH][RFC] 2.5.44 " Olaf Dietsche
2002-10-28 22:56         ` Olaf Dietsche
2002-10-28 23:36           ` chris
2002-10-29  0:20             ` Olaf Dietsche
2002-10-29  1:08               ` Olaf Dietsche
2002-10-29 11:08                 ` Olaf Dietsche [this message]
2002-10-29 11:18                 ` Chris Evans
2002-10-29  2:23             ` Andreas Gruenbacher
2002-10-29 11:09               ` Olaf Dietsche
2002-10-29 11:35                 ` Andreas Gruenbacher
2002-10-29 12:04                 ` __libc_enable_secure check (was: [PATCH][RFC] 2.5.44 (1/2): Filesystem capabilities kernel patch) Olaf Dietsche
2002-10-29 14:38                 ` [PATCH][RFC] 2.5.44 (1/2): Filesystem capabilities kernel patch Olaf Dietsche
2002-10-20  0:24 ` [PATCH][RFC] 2.5.42 " Andreas Gruenbacher
2002-10-21 15:25   ` Olaf Dietsche
2002-10-21 22:03     ` Andreas Gruenbacher

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87smypmrio.fsf@goat.bogus.local \
    --to=olaf.dietsche#list.linux-kernel@t-online.de \
    --cc=agruen@suse.de \
    --cc=chris@scary.beasts.org \
    --cc=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.