public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Olaf Dietsche <olaf.dietsche#list.linux-kernel@t-online.de>
To: Andreas Gruenbacher <agruen@suse.de>
Cc: <chris@scary.beasts.org>, <linux-kernel@vger.kernel.org>,
	Ulrich Drepper <drepper@redhat.com>, <bug-glibc@gnu.org>
Subject: Re: __libc_enable_secure check (was: [PATCH][RFC] 2.5.44 (1/2): Filesystem capabilities kernel patch)
Date: Tue, 29 Oct 2002 13:04:58 +0100	[thread overview]
Message-ID: <87fzupmowl.fsf@goat.bogus.local> (raw)
In-Reply-To: 87n0oxmrhn.fsf@goat.bogus.local

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

> Andreas Gruenbacher <agruen@suse.de> writes:
>
>> On Tuesday 29 October 2002 00:36, chris@scary.beasts.org 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.

I'm a bit lost in the glibc sources, but tried my best anyway :-).
Here is an untested patch against glibc 2.3.1. Can someone from the
glibc team please comment? Would this be acceptable or do you have any
objections against it? Could this be included even into glibc 2.2.x?

TIA
Regards, Olaf.

--- glibc-2.3.1/sysdeps/generic/dl-sysdep.c~	Sat Jul 20 19:30:48 2002
+++ glibc-2.3.1/sysdeps/generic/dl-sysdep.c	Tue Oct 29 12:47:55 2002
@@ -140,6 +140,9 @@
   DL_SYSDEP_OSCHECK (dl_fatal);
 #endif
 
+#ifdef DL_SECURE_INIT
+  DL_SECURE_INIT;
+#else
   /* Fill in the values we have not gotten from the kernel through the
      auxiliary vector.  */
 #ifndef HAVE_AUX_XID
@@ -154,6 +157,7 @@
   /* If one of the two pairs of IDs does not mattch this is a setuid
      or setgid run.  */
   INTUSE(__libc_enable_secure) = uid | gid;
+#endif
 
 #ifndef HAVE_AUX_PAGESIZE
   if (GL(dl_pagesize) == 0)
--- glibc-2.3.1/sysdeps/unix/sysv/linux/dl-sysdep.c~	Thu May 16 07:43:08 2002
+++ glibc-2.3.1/sysdeps/unix/sysv/linux/dl-sysdep.c	Tue Oct 29 12:47:53 2002
@@ -20,9 +20,11 @@
 /* Linux needs some special initialization, but otherwise uses
    the generic dynamic linker system interface code.  */
 
+#include <sys/prctl.h>
 #include <unistd.h>
 
 #define DL_SYSDEP_INIT frob_brk ()
+#define DL_SECURE_INIT INTUSE(__libc_enable_secure) = prctl (PR_GET_DUMPABLE) == 0
 
 static inline void
 frob_brk (void)

  parent reply	other threads:[~2002-10-29 11:58 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
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                 ` Olaf Dietsche [this message]
2002-10-29 14:38                 ` 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=87fzupmowl.fsf@goat.bogus.local \
    --to=olaf.dietsche#list.linux-kernel@t-online.de \
    --cc=agruen@suse.de \
    --cc=bug-glibc@gnu.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox