Hi Andries,

> The question came up whether execve of a suid binary while being ptraced
> would fail or ignore the suid part. The answer today seems to be the
> latter:
> 
> E.g. (in 2.6.11) security/dummy.c:
> 
> static void dummy_bprm_apply_creds (struct linux_binprm *bprm, int 
> unsafe)
> {
>         if (bprm->e_uid != current->uid || bprm->e_gid != current->gid) {
>                 if ((unsafe & ~LSM_UNSAFE_PTRACE_CAP) &&
> !capable(CAP_SETUID)) {
>                         bprm->e_uid = current->uid;
>                         bprm->e_gid = current->gid;
>                 }
>         }
> }
> 
> and fs/exec.c:
> 
> void compute_creds(struct linux_binprm *bprm) {
>         int unsafe;
> 
>         unsafe = unsafe_exec(current);
>         security_bprm_apply_creds(bprm, unsafe);
> }
> 
> static inline int unsafe_exec(struct task_struct *p) {
>         int unsafe = 0;
>         if (p->ptrace & PT_PTRACED) {
>                 if (p->ptrace & PT_PTRACE_CAP)
>                         unsafe |= LSM_UNSAFE_PTRACE_CAP;
>                 else
>                         unsafe |= LSM_UNSAFE_PTRACE;
>         }
>         return unsafe;
> }
> 
> That is: if the process that calls execve() is being traced,
> the LSM_UNSAFE_PTRACE bit is et in unsafe and security_bprm_apply_creds()
> will make sure the suid/sgid bits are ignored.
> 
> ---
> 
> In my man page I do not read anything like that. It says
> 
>  EPERM  The process is being traced, the user is not the  superuser and
>         the file has an SUID or SGID bit set.
> and
> 
>  If  the current program is being ptraced, a SIGTRAP is sent to it after
>  a successful execve().
> 
>  If the set-uid bit is set on the program file pointed  to  by filename
>  the  effective user ID of the calling process is changed to that of the
>  owner of the program file.
> 
> So, maybe this sentence should be amended to read
> 
>  If the set-uid bit is set on the program file pointed  to  by filename
>  and the current process is not being ptraced, the  effective user ID
>  of the calling process is changed to ...

I changed your "current" to "calling" (to be consistent with the 
rest of the page), but otherwise applied as you suggest.

The revision will appear in man-pages-2.03, which I can release
any time now.  Are you avialable to do an upload tomorrow?
This commit is contained in:
Michael Kerrisk 2005-05-31 16:07:24 +00:00
parent 5e4e13a313
commit 6aacaf94e5
1 changed files with 3 additions and 1 deletions

View File

@ -65,7 +65,8 @@ If the current program is being ptraced, a \fBSIGTRAP\fP is sent to it
after a successful \fBexecve()\fP.
If the set-uid bit is set on the program file pointed to by
\fIfilename\fP the effective user ID of the calling process is changed
\fIfilename\fP, and the calling process is not being ptraced,
then the effective user ID of the calling process is changed
to that of the owner of the program file. Similarly, when the set-gid
bit of the program file is set the effective group ID of the calling
process is set to the group of the program file.
@ -210,6 +211,7 @@ Since Unix V7 both are NULL.
.BR chmod (2),
.BR fork (2),
.BR path_resolution (2),
.BR ptrace (2),
.BR execl (3),
.BR environ (5),
.BR ld.so (8)