Dumpable tasks and ownership of /proc/*/fd

Dumpable tasks and ownership of /proc/*/fd

[Petr Baudis]

  Hello,

  I would like to ask why is /proc/*/fd owned by root when the task is
not dumpable - what security concern does it address? It would seem more
reasonable to me if the /proc/*/fd owner would be simply always the real
uid of the process.

  The issue is that now all tasks calling setuid() from root to non-root
during their lifetime will not be able to access their /proc/self/fd.
This is troublesome because the fstatat() and other *at() routines are
emulated by accessing /proc/self/fd/*/path and that will break with
setuid()ing programs, leading to various weird consequences (e.g. with
the latest glibc, nftw() does not work with setuid()ing programs and
furthermore causes the LSB testsuite to fail because of this, etc.).

  Thanks,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.

Re: Dumpable tasks and ownership of /proc/*/fd

[Eric W. Biederman]

Petr Baudis <pasky@suse.cz> writes:

>   Hello,
>
>   I would like to ask why is /proc/*/fd owned by root when the task is
> not dumpable - what security concern does it address? It would seem more
> reasonable to me if the /proc/*/fd owner would be simply always the real
> uid of the process.
>
>   The issue is that now all tasks calling setuid() from root to non-root
> during their lifetime will not be able to access their /proc/self/fd.
> This is troublesome because the fstatat() and other *at() routines are
> emulated by accessing /proc/self/fd/*/path and that will break with
> setuid()ing programs, leading to various weird consequences (e.g. with
> the latest glibc, nftw() does not work with setuid()ing programs and
> furthermore causes the LSB testsuite to fail because of this, etc.).

Looking at it the current check is indeed incorrect.
Primarily because it is a check on open and not a check
on access.  We can open the directory anytime so if
this is a serious permission we need to check on access.

Further when it is ourselves we always have access to that
information directly, and /proc is just a convenience.  So
we should not be denying ourselves.

Other processes we do need to deny if we aren't dumpable because
they don't have another way to get that information.

Speaking of things why does the *at() emulation need to touch
/proc/self/fd/*?  I may be completely dense but if the practical
justification for allowing access to /proc/self/fd/ is that we
already have access then we shouldn't need /proc/self/fd.

I suspect this a matter of convenience where you are prepending
/proc/self/fd/xxx/ to the path before you open it instead of calling
fchdir openat() and the doing fchdir back.  Have I properly guessed
how the *at() emulation works?

Eric

Re: Dumpable tasks and ownership of /proc/*/fd

[Petr Baudis]

Dear diary, on Mon, Apr 10, 2006 at 07:43:03AM CEST, I got a letter
where "Eric W. Biederman" <ebiederm@xmission.com> said that...
> Speaking of things why does the *at() emulation need to touch
> /proc/self/fd/*?  I may be completely dense but if the practical
> justification for allowing access to /proc/self/fd/ is that we
> already have access then we shouldn't need /proc/self/fd.
> 
> I suspect this a matter of convenience where you are prepending
> /proc/self/fd/xxx/ to the path before you open it instead of calling
> fchdir openat() and the doing fchdir back.  Have I properly guessed
> how the *at() emulation works?

Ok, now I'm not completely following you. Only i386 and x86_64 appears
to provide the openat() syscall (only in new kernels, furthermore) and
glibc otherwise emulates openat(n, "relpath") with
open("/proc/self/fd/<n>/relpath"). I don't know of any other way how to
emulate it.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.

Re: Dumpable tasks and ownership of /proc/*/fd

[Eric W. Biederman]

Petr Baudis <pasky@ucw.cz> writes:

> Dear diary, on Mon, Apr 10, 2006 at 07:43:03AM CEST, I got a letter
> where "Eric W. Biederman" <ebiederm@xmission.com> said that...
>> Speaking of things why does the *at() emulation need to touch
>> /proc/self/fd/*?  I may be completely dense but if the practical
>> justification for allowing access to /proc/self/fd/ is that we
>> already have access then we shouldn't need /proc/self/fd.
>> 
>> I suspect this a matter of convenience where you are prepending
>> /proc/self/fd/xxx/ to the path before you open it instead of calling
>> fchdir openat() and the doing fchdir back.  Have I properly guessed
>> how the *at() emulation works?
>
> Ok, now I'm not completely following you. Only i386 and x86_64 appears
> to provide the openat() syscall (only in new kernels, furthermore) and
> glibc otherwise emulates openat(n, "relpath") with
> open("/proc/self/fd/<n>/relpath"). I don't know of any other way how to
> emulate it.

I can think of a couple of ways, but thanks for confirming
I properly guessed how the openat emulation was working.

The first point to note is that fixing proc and exporting
syscalls to new architectures is going to take about equally
long with a chance that fixing proc will take longer because
that needs to be understood.

With that said I can think of a couple of different ways
to implement openat that won't have proc permission problems.

The most straight forward is:
int openat(int dirfd, const char *path, int flags, int mode)
{
        int orig_dir_fd;
        int result;
	lock()
	orig_dir_fd = open(".");
	fchdir(dirfd);
        result = open(relpath);
        fchdir(orig_dir_fd);
        close(orig_dir_fd);
        unlock();
        return result;
}

I suspect something like the above needs to be considered if
you want the emulation to work on old kernels, in the presence
of suid applications.

I will look at fixing proc but I none of my work on /proc
is going to get merged until 2.6.18 at this point.

I doubt a proc permission change could count as a simply
a bug fix, and even then it doesn't matter because it won't
be available for your emulation.

Although I guess you could attempt to use /proc/self/fd/<n>
and if that gets a permission problem try a slower but more
reliable path in the emulation.

Eric

Re: Dumpable tasks and ownership of /proc/*/fd

[Petr Baudis]

Dear diary, on Mon, Apr 10, 2006 at 09:42:03AM CEST, I got a letter
where "Eric W. Biederman" <ebiederm@xmission.com> said that...
> The most straight forward is:
> int openat(int dirfd, const char *path, int flags, int mode)
> {
>         int orig_dir_fd;
>         int result;
> 	lock()
> 	orig_dir_fd = open(".");
> 	fchdir(dirfd);
>         result = open(relpath);
>         fchdir(orig_dir_fd);
>         close(orig_dir_fd);
>         unlock();
>         return result;
> }
> 
> I suspect something like the above needs to be considered if
> you want the emulation to work on old kernels, in the presence
> of suid applications.
> 
..snip..
> 
> Although I guess you could attempt to use /proc/self/fd/<n>
> and if that gets a permission problem try a slower but more
> reliable path in the emulation.

Oops, I completely forgot about fchdir(). Thanks, I think I will use
something like this for now.


By the way, I would like to return to a statement from your previous
mail:

> Other processes we do need to deny if we aren't dumpable because
> they don't have another way to get that information.

I still don't understand this - so why don't provide them _this_ way to
get that information? What is the security risk?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.

Re: Dumpable tasks and ownership of /proc/*/fd

[Bodo Eggert]

Eric W. Biederman <ebiederm@xmission.com> wrote:

> Speaking of things why does the *at() emulation need to touch
> /proc/self/fd/*?  I may be completely dense but if the practical
> justification for allowing access to /proc/self/fd/ is that we
> already have access then we shouldn't need /proc/self/fd.
> 
> I suspect this a matter of convenience where you are prepending
> /proc/self/fd/xxx/ to the path before you open it instead of calling
> fchdir openat() and the doing fchdir back.  Have I properly guessed
> how the *at() emulation works?

Think about threads or siglongjmp(sp?).
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.