Quoting Stephen Smalley ([email protected]):
> On Thu, 2006-08-17 at 08:00 -0400, Joshua Brindle wrote:
> > Stephen Smalley wrote:
> > > On Tue, 2006-08-15 at 21:42 -0500, Serge E. Hallyn wrote:
> > >
> > > <snip>
> > >> Very good point. Preventing communication channels i.e. through signals
> > >> isn't a concern, but user hallyn ptracing himself running /bin/passwd
> > >> certainly is.
> > >>
> > >
> > > Actually, ptrace already performs a capability comparison (cap_ptrace).
> > > Wrt signals, it wasn't the communication channel that concerned me but
> > > the ability to interfere with the operation of a process running in the
> > > same uid but different capabilities, like stopping it at a critical
> > > point. Likewise with many other task hooks - you wouldn't want to be
> > > able to depress the priority of a process running with greater
> > > capabilities.
> > >
> > >
> > On this point, what about environment tampering of processes with caps?
> > LD_PRELOAD=my_bad_lib.so /usr/bin/passwd. glibc atsecure logic would
> > have to be updated to do a capability comparison.
>
> That's the bprm_secureexec logic change that has already been mentioned;
> that determines the AT_SECURE value, and glibc then just acts based on
> that value provided by the kernel. Just a matter of extending
> cap_bprm_secureexec to compare the capability sets. Already on Serge's
> todo list, but it is necessary for this to be a safe change, and should
> happen before this patch goes anywhere (even -mm), IMHO.
Does the following seem a reasonable way to handle secureexec in the
face of file caps?
Seems like it should work so long as we don't have to worry about the
bprm changing partway through exec. This should avoid the need to store
the old capabilities.
Unless I've got my head screwed on completely backward...
thanks,
-serge
(note - Still need at least a signals patch on top of this before the
file caps could be safe for use)
>From e791e196cda84743e805167c11e424f4132aa2a4 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <[email protected]>
Date: Mon, 21 Aug 2006 14:54:17 -0500
Subject: [PATCH 1/1] security: handle secureexec with filesystem capabilities
A secure exec is required if euid!=uid, and, correspondingly,
if the executable's file capability set was not empty and the
process is not owned by (real uid) root.
Signed-off-by: Serge E. Hallyn <[email protected]>
---
security/commoncap.c | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/security/commoncap.c b/security/commoncap.c
index 6bf030d..b1777a9 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -265,11 +265,15 @@ void cap_bprm_apply_creds (struct linux_
int cap_bprm_secureexec (struct linux_binprm *bprm)
{
- /* If/when this module is enhanced to incorporate capability
- bits on files, the test below should be extended to also perform a
- test between the old and new capability sets. For now,
- it simply preserves the legacy decision algorithm used by
- the old userland. */
+ if (current->uid != 0) {
+ if (!cap_isclear(bprm->cap_effective))
+ return 1;
+ if (!cap_isclear(bprm->cap_permitted))
+ return 1;
+ if (!cap_isclear(bprm->cap_inheritable))
+ return 1;
+ }
+
return (current->euid != current->uid ||
current->egid != current->gid);
}
--
1.4.2
-
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]
