2002-10-29 00:14:58

by Olaf Dietsche

[permalink] [raw]
Subject: Re: [PATCH][RFC] 2.5.44 (1/2): Filesystem capabilities kernel patch

<[email protected]> 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.
>
> 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.

Regards, Olaf.


2002-10-29 01:02:04

by Olaf Dietsche

[permalink] [raw]
Subject: Re: [PATCH][RFC] 2.5.44 (1/2): Filesystem capabilities kernel patch

Olaf Dietsche <olaf.dietsche#[email protected]> writes:

> <[email protected]> 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.

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.

Hopefully, someone more fluent in glibc issues can shed some light?
Is there a way to switch LD_PRELOAD off completely or on a needed
basis?

Regards, Olaf.

2002-10-29 11:12:11

by Chris Evans

[permalink] [raw]
Subject: Re: [PATCH][RFC] 2.5.44 (1/2): Filesystem capabilities kernel patch

Hi,

Quoting Olaf Dietsche
<olaf.dietsche#[email protected]>:

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

In theory you should be able to just replace the
__libc_enable_secure check with

__libc_enable_secure = !prctl(PR_GET_DUMPABLE);

i.e. let the kernel handle the logic of whether a
process is running privileged.If we duplicate it
between kernel and libc, we'll get security bugs.

Cheers
Chris