su problem with 4.4.93

[Nate Eldredge]

On Fri, 31 Jan 2003, steve houseman wrote:

>
> Hello,
>
> I thought I sent this once, I was sure I'd sent this the next time.
> so here it is for the third time ...  I've changed my devel list to
> non-batch and with ack so I should know sooner if it doesnt arrive.
>
>
> linux kernel 2.4.18
>
> In trying to recreate this problem in a simpler example, it seems
> as though it is linked to  tracing suid executables.... which
> I assume is ok ?

No.  The reason is that tracing permits you to read and write the traced
process's memory.  So if an ordinary user could trace suid programs, you
could trace su (or your favorite suid), and alter its code to immediately
do exec("/bin/sh").  Which would be bad for security.

So if a traced process tries to exec() a suid program, the kernel drops
the suid part and runs the new program as the original user.  Unless, that
is, the original process had the ability to do setuid(2) anyway (i.e. was
root-owned) which would make this moot.

This is in compute_creds, under if (!capable(CAP_SETUID)).  It's entirely
a kernel issue and AFAIK should have nothing to do with strace.  If any
system really allows you to strace a suid binary as non-root and lets it
keep its root privileges, it has a glaring security hole and should not be
used.

>
> I wrote a trivial exe (aa) which printed out its uid and euid
> and set it owned by root and suid (to mimic su)
>
> strace  -o/tmp/dbin -f -F -tt -v su steve -c aa
> prints out euid=1000 ie steve , but a straight run as steve of .aa
> shows euid=0  as expected.

That's correct behavior.

> This is the same for 4.4.2 and 4.4.93 ... unlike the original problem
> (with wine install) that I reported which occured on 4.4.93 but
> 4.4.2 was ok.
>
>
> Investigating the suid problem with printk s in the kernel,
> the problem area seems to be compute_creds and a chunk of code
> that I dont understand what its purpose is ... but if
> ptrace & PT_PTRACE_CAP were true then it wouldnt go that way ,

But this is only true when you are already root.

> ie must_not_trace_exec would return zero, and
> it would work... ie the bprm euid wouldnt be reset.
> I guess that in the
> /usr/src/linux-2.4.18/arch/i386/kernel/ptrace.c
>
> asmlinkage int sys_ptrace(long request, long pid, long addr, long data)
> <snippety>
>         if (request == PTRACE_TRACEME) {
>                 /* are we already being traced? */
>                 if (current->ptrace & PT_PTRACED)
>                         goto out;
>                 /* set the ptrace bit in the process flags. */
>                 current->ptrace |= PT_PTRACED;
>
>
>                 if( current->uid == 0 ||     // <<<<< the 3 lines
>                     current->euid == 0  )
>                      current->ptrace |= PT_PTRACE_CAP ;
>                 ret = 0;
>                 goto out;
>         }
>
>
> then this would be set when a traceme request was made as root,
> and this capability (or something) ought to be propagated to
> children (and I *think* it would be).

Nope.  current->ptrace is only propagated to children by clone(2) with the
CLONE_PTRACE flag, and not by normal fork(2).  Which is correct: you don't
want fork() to randomly create traced processes which you weren't
expecting to have to trace.

> The above seems to work , but I dont know enough to know whether
> it is sensible or barmy ... and whether an attach (vs running
> a prog) needs anything.

To attach to a suid process you have to be root.

> It seems to work in that an strace of su steve -c aa works

Sure.  When you strace su, su runs as you, without root privileges.  But
when it forks to run aa, the child is not traced and so is perfectly
capable of execing a suid binary (aa) without interference.

> and the wine install works .... why did this (wine install)
> work under 4.4.2 and not 4.4.93 ... I have no idea.... maybe
> there is another problem lurking .

-- 

Nate Eldredge
neldredge at hmc.edu