Quoting Chris Wright ([email protected]):
> [folks, this is getting much too long-winded to stay a private thread]
>
> * Serge E. Hallyn ([email protected]) wrote:
> > Quoting Chris Wright ([email protected]):
> > > * Andrew Morgan ([email protected]) wrote:
> > > > I share Casey's view that what's in the kernel now appears to have
> > > > evolved because of the absence of filesystem capabilities and not in
> > > > preparation for them. I'm not at all clear that they offer any real
> > > > improvement over the more macroscopic, but much simpler to understand,
> > > > superuser model.
> > >
> > > Presently they offer next to nothing. From the POV of kernel code,
> > > they've added an extremely coarse grained way to check privs for
> > > actions (CAP_SYS_ADMIN renders much of this useless for least priv).
> > > >From userspace POV, there's basically one well-known program that uses
> > > the existing crippled model to drop privs. And from end-users' POV,
> > > there's no end of frustrated attempts to make something useful out
> > > of it. From a security POV, there's missing functionality (which has
> > > been addressed in Andrew's older patches and Serge's current patchset).
> >
> > I'm sorry I'm not sure what your conclusion is then. Are you saying
> > that my patch does add functionality, or arguing that it shouldn't be
> > included?
>
> It does add functionality, it is existing capabilities which are not
> particularly useful.
Ah, ok.
> > > > I think the implementation (the patch) adds support for storing
> > > > capabilities in the filesystem. But, I don't believe it is as a step
> > > > towards 'POSIX' capability support, but just adding another incrementa
> > > > twist to the Linux capability implementation - its hard to reason about
> > > > such a thing, in terms of security or otherwise. (Have you thought about
> > > > whether LD_LIBRARY_PATH is ignored by capability aware, but non-setuid-0
> > > > programs? To voice one example. There are many system consequences to
> > > > this model that will only become apparent when people start to seriously
> > > > implement and use it.)
> > >
> > > The classic argument has been one of administration. Tools know how to
> > > search for setuid programs,
> >
> > Sure, but 'find' plus a 5-line program to check for security.capability
> > xattrs will find capability programs, right?
>
> Yes. I'm not 100% sold on the administration issue, but it is real, and
> unfortunately the extra 5-line program isn't a great solution.
It might not be :), but surely once people see what the actual
administration challenges turn out to be, they/we can write the tools to
satisfy those needs? I don't believe they will be insurmountable.
You had in the past played with caps quite a bit, do you already have a
sense of what kinds of admin problems people will have?
> > Are there popular gui's in
> > widespread use which depend on programs granting extra privilege doing
> > so using setuid?
> >
> > > and mainline MAC is not adding caps based on
> > > security domain during exec, etc.
> >
> > I don't understand what you're saying - could you explain? Which
> > 'mainline MAC', what sort of domains (TE?)?
>
> mainline MAC meaning basically SELinux. IOW, while LIDS and Apparmor
> had/have models for handling capabilities (don't recall if it was grant
> or restrict only), SELinux is just now talking about doing something
> like this, but nothing is upstream and in wide distribution.
>
> > > My biggest concern is leaking caps to
> > > programs which are meant to be unprivileged.
> >
> > Would it help if we place CONFIG_SECURITY_FILE_CAPABILITIES under
> > CONFIG_EXPERIMENTAl for a bit?
>
> Would not hurt ;-)
Ok, here's a patch on top of 2.6.22-rc4-mm2 to do so,
thanks,
-serge
>From bf1566bb34ed47ffadfe9289ba2f1a85df5dc36f Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <[email protected]>
Date: Thu, 21 Jun 2007 11:40:23 -0400
Subject: [PATCH 1/1] file capabilities: make file capabilities option EXPERIMENTAL
Make file capabilities depend upon CONFIG_EXPERIMENTAL, as few
people have used them to date.
Signed-off-by: Serge E. Hallyn <[email protected]>
---
security/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/Kconfig b/security/Kconfig
index 7c941d9..ac56c2c 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -81,8 +81,8 @@ config SECURITY_CAPABILITIES
If you are unsure how to answer this question, answer Y.
config SECURITY_FILE_CAPABILITIES
- bool "File POSIX Capabilities"
- depends on SECURITY=n || SECURITY_CAPABILITIES!=n
+ bool "File POSIX Capabilities (EXPERIMENTAL)"
+ depends on (SECURITY=n || SECURITY_CAPABILITIES!=n) && EXPERIMENTAL
default n
help
This enables filesystem capabilities, allowing you to give
--
1.5.1.1.GIT
-
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]
