l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On trusting its parent process


From: Marcus Brinkmann
Subject: Re: On trusting its parent process
Date: Tue, 11 Oct 2005 17:13:11 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Mon, 10 Oct 2005 22:01:27 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> 
> >>From the perspective of the 'su' program, the difficult is that 'su'
> utterly relies on the fact that the password file is authentic. It can
> check that the format of the file is good, but it has no way to know if
> the file has been replaced entirely. In Plan 9, this is a case where the
> *identity* rather than the *interface* matters.

I will assume for this discussion that "su" is a suid program owned by
root on the root filesystem.

If you want to execute the program, you have two choices in the Hurd:

1. You read out the binary data and then create a process image from
   that.  Good luck.  The program will only be able to get whatever
   capabilities you are willing to give to it.  If you don't already
   have the capability to switch to the user ID you want to have
   directly, you won't get it from su either.

2. You ask the filesystem to execute the suid program on behalf of
   you.

   The filesystem will see the suid bit, and then apply a bit of magic
   to ensure that everything works out OK:

   *) It will create an authentication capability to its own trusted
    authentication server that contains, in the proper order, the user
    ID of the caller as the real user ID and the file owner ID as
    effective user ID.

   *) It will provide a current and root directory capability to its
    own trusted filesystems.

   *) In general it will set things up as a suid program would expect
    them to be set up :)

The important thing here is that the suid application receives all the
important stuff from the filesystem it resides on, NOT from the user
that is starting the application.  So even if the user is chrooted,
the suid application will escape the chroot and see the real
/etc/passwd file, or /servers/passwd server, or whatever.

Note that the filesystem must have the necessary authorization to do
all this.  In particular, it must be authenticated as root, or at
least as the file owner of the file that has the suid bit set.

I suspect you will object to this design with a small "o" :) But
whatever problems it has is not that the su program might see the
wrong stuff.

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]