Quoting Eric W. Biederman (ebiederm@xmission.com):

"Serge E. Hallyn" [off-list ref] writes:

quoted

Quoting Eric W. Biederman (ebiederm@xmission.com):

quoted

Alan Cox [off-list ref] writes:

quoted

quoted

quoted

Execute != read. The executable file may contain secrets which must not
be available to the user running the setuid program. If you fail the
setuid, the user will be able to ptrace() and then the secret is
revealed.

It's amazing how many security holes appear from what seems like a very
simple request.

Do we have a security hole in nosuid mount option?
Can someone write a patch to fix it?

If a setuid app can read a key when its erroneously not set setuid then
the user can read it too.

Anything you can do with ptrace you can do yourself !

Now that I think about it this is really something completely separate
from setuid.  This is about being able to read the text segment with
ptrace when you on have execute permissions on the file.

I just skimmed through fs/exec.c and we set the undumpable process
flag in that case so ptrace should not work in that case.

And in fact you can't do a new ptrace_attach, but if you're already
tracing the task when it execs the unreadable-but-executable file,
then the ptrace can continue.

Just looking at the code, it appears 2.2 was the same way (though I
could be missing where it used to enforce that).

So, is that intended?  What exactly would we do about it if not?
Just refuse exec of a unreadable-but-executable file if we're
being traced?

In common cap we drop the new capabilities if we are being ptraced.
Look for brm->unsafe.

Yes - that isn't the issue.  The issue is with a file to which
we have execute permission but not read.  If user hallyn has two
terminals open, and terminal one does ./foo then terminal two
cannot do strace -f -p `pidof foo`.  But user hallyn can do
strace -f -p ./foo and succeed.

So we refuse ptrace_attach to an existing process with dumpable
turned off, but a pre-existing ptrace attach isn't affected by
executing a file which causes dumpable to be unset.

It goes back to finding a way to figure out what is inside the
file when the installer obviously thought we shouldn't be able
to read the file.

Do we care?  <shrug>

-serge