>For ptrace the definition is:
> If the tracee has different privileges, than the tracer, than it
> can't be traced.
> For this definition, the check is not a hack. It's the only way to go.
I agree this is the proper goal for ptrace and this code is not a hack.
It's a bug. In Linux, uid, euid, suid, gid, egid, and sgid do not by
themselves determine privileges. And that's what ptrace checks. The main
determiner of basic privileges is the process capabilities. The euid,
etc. do also. I have frequently have on my system a process that runs
with the same uid, euid, etc. as some other process, but should not be
allowed to ptrace it because the tracee has CAP_DAC_OVERRIDE (the
privilege to access files in spite of file permissions) and the tracer
does not. (Furthermore, the tracee got that privilege courtesy of a
set-uid file, but as we seem to agree, that is not relevant here).
So as with the user space programs I mentioned (where the euid check is
indeed a hack), I have to fix ptrace too. Fortunately, it looks as simple
as comparing capability sets.
> Now this definition is really what is needed for the filesystem case
> too, so I think it's not a hack either.
Maybe I got lost in the problem we were trying to solve, then. What does
comparing the privileges of one process with those of another have to do
with this thread about making safe unprivileged mounts via namespaces? The
post to which I replied said we have to deal with set-uid programs. Aren't
we talking about the problem where someone sets a file's setuid flag on
with the assumption that when the program within runs, it will see certain
files at certain places? And the fact that if one could mount whatever he
wants, that would violate the assumption? The two ways suggested of
handling that are: 1) after the private mount, ignore all setuid flags. 2)
after the private mount, don't let a program that has gained privileges
via set-uid see the user-made names.
My point is still that (2) can't be done because you can't know that a
program has gained privileged via set-uid.
If it's really not about set-uid, but about ptrace-like privilege
borrowing, please enlighten me.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
