Olaf Dietsche <olaf.dietsche#[email protected]> writes:
> 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.
This is already done in cap_bprm_compute_creds(), it seems. Here is an
untested patch to trick glibc into thinking this is a SGID binary and
thus ignoring LD_PRELOAD. This may break some programs, though.
Comments?
Regards, Olaf.
--- a/security/capability.c Thu Oct 24 00:11:51 2002
+++ b/security/capability.c Tue Oct 29 15:13:42 2002
@@ -187,6 +187,8 @@
}
}
do_unlock = 1;
+ if (current->euid == current->uid && current->egid == current->gid)
+ current->gid = -1;
}
/* For init, we want to retain the capabilities set