Andreas Gruenbacher <[email protected]> writes:
> On Tuesday 29 October 2002 00:36, [email protected] wrote:
>> I'm not sure what the current glibc security check is, but it used to be
>> simple *uid() vs. *euid() checks. This would not catch an executable with
>> filesystem capabilities.
>> Have a look at
>> http://security-archive.merton.ox.ac.uk/security-audit-199907/0192.html
[...]
>> I think the eventual plan was that we pass the kernel's current->dumpable
>> as an ELF note. Not sure if it got done. Alternatively glibc could use
>> prctl(PR_GET_DUMPABLE).
>
> Sorry, I don't know exactly what was your plan here. Could you please explain?
Judging from the mail archive above: instead of checking uid vs. euid
and gid vs. egid, ask the kernel and grant or deny LD_PRELOAD
according to the dumpable flag (see prctl(2)). This flag is set to
false, if uid != euid, etc. So, this flag could be used/cleared by
capabilities as well.
> A perhaps unrelated note: We once had Pavel Machek's elfcap implementation, in
> which capabilities were stored in ELF. This was a bad idea because being able
> to create executables does not imply the user is capable of CAP_SETFCAP, and
> users shouldn't be able to freely choose their capabilities :-] We still want
I remember this hack and since I hear this claim every now and then, I
downloaded his patch and verified with the source. Pavel's capability
patch was about _restricting_ not granting capabilities, so it's more
like an inheritable, rather than a permitted, set.
At least that was his intention. I didn't verify this with the
appropriate kernel sources from 1999.
Regards, Olaf.
On Tuesday 29 October 2002 12:09, Olaf Dietsche wrote:
> Andreas Gruenbacher <[email protected]> writes:
> > A perhaps unrelated note: We once had Pavel Machek's elfcap
> > implementation, in which capabilities were stored in ELF. This was a bad
> > idea because being able to create executables does not imply the user is
> > capable of CAP_SETFCAP, and users shouldn't be able to freely choose
> > their capabilities :-] We still want
>
> I remember this hack and since I hear this claim every now and then, I
> downloaded his patch and verified with the source. Pavel's capability
> patch was about _restricting_ not granting capabilities, so it's more
> like an inheritable, rather than a permitted, set.
>
> At least that was his intention. I didn't verify this with the
> appropriate kernel sources from 1999.
I forgot to CC Pavel the last time. Elfcap probably truly was restrictive
only. This is comparable to dropping capabilities very early in the suid root
binaries themselves, and thus not a significant improvement.
We want to be able to also grant capabilities (not only restrict them), so we
may have fewer suid root binaries.
--Andreas.