This patch adds filesystem capabilities to 2.5.42, but it applies to
2.5.43 as well.
It's very simple. In the root directory of every filesystem, there
must be a file named ".capabilities". This is the capability database
indexed by inode number. These files are populated by a chcap tool,
see next mail.
This fs capability system should work on all filesystem, which can
provide long dotted names and have some sort of inode. Another benefit
is, when holes in files are allowed. Otherwise the .capabilities file
could grow pretty large.
I use this on an ext2 filesystem. It boots and seems to work so far.
Comments?
Regards, Olaf.
diff -urN a/security/Config.in b/security/Config.in
--- a/security/Config.in Sat Oct 5 18:44:05 2002
+++ b/security/Config.in Fri Oct 18 13:38:55 2002
@@ -3,5 +3,6 @@
#
mainmenu_option next_comment
comment 'Security options'
-define_bool CONFIG_SECURITY_CAPABILITIES y
+tristate 'Security Capabilities' CONFIG_SECURITY_CAPABILITIES
+dep_bool ' Filesystem Capabilities (EXPERIMENTAL)' CONFIG_FS_CAPABILITIES $CONFIG_EXPERIMENTAL
endmenu
diff -urN a/security/capability.c b/security/capability.c
--- a/security/capability.c Sat Oct 12 14:24:21 2002
+++ b/security/capability.c Fri Oct 18 20:05:30 2002
@@ -18,6 +18,7 @@
#include <linux/smp_lock.h>
#include <linux/skbuff.h>
#include <linux/netlink.h>
+#include <linux/namei.h>
/* flag to keep track of how we were registered */
static int secondary;
@@ -115,14 +116,53 @@
return 0;
}
+#ifdef CONFIG_FS_CAPABILITIES
+static struct file *open_capabilities(struct linux_binprm *bprm)
+{
+ static char name[] = ".capabilities";
+ struct nameidata nd;
+ int err;
+ nd.mnt = mntget(bprm->file->f_vfsmnt);
+ nd.dentry = dget(nd.mnt->mnt_root);
+// nd.last_type = LAST_ROOT;
+ nd.flags = 0;
+ err = path_walk(name, &nd);
+ if (err)
+ return ERR_PTR(err);
+
+ return dentry_open(nd.dentry, nd.mnt, O_RDONLY);
+}
+
+static void read_capabilities(struct file *filp, struct linux_binprm *bprm)
+{
+ __u32 fscaps[3];
+ unsigned long ino = bprm->file->f_dentry->d_inode->i_ino;
+ int n = kernel_read(filp, ino * sizeof(fscaps), (char *) fscaps, sizeof(fscaps));
+ if (n == sizeof(fscaps)) {
+ bprm->cap_effective = fscaps[0];
+ bprm->cap_inheritable = fscaps[1];
+ bprm->cap_permitted = fscaps[2];
+ }
+}
+#endif
+
static int cap_bprm_set_security (struct linux_binprm *bprm)
{
+#ifdef CONFIG_FS_CAPABILITIES
+ struct file *filp;
+#endif
/* Copied from fs/exec.c:prepare_binprm. */
- /* We don't have VFS support for capabilities yet */
cap_clear (bprm->cap_inheritable);
cap_clear (bprm->cap_permitted);
cap_clear (bprm->cap_effective);
+#ifdef CONFIG_FS_CAPABILITIES
+ filp = open_capabilities(bprm);
+ if (filp && !IS_ERR(filp)) {
+ read_capabilities(filp, bprm);
+ filp_close(filp, 0);
+ }
+#endif
/* To support inheritance of root-permissions and suid-root
* executables under compatibility mode, we raise all three
On Fri, 18 Oct 2002, Olaf Dietsche wrote:
> This patch adds filesystem capabilities to 2.5.42, but it applies to
> 2.5.43 as well.
>
> It's very simple. In the root directory of every filesystem, there
> must be a file named ".capabilities". This is the capability database
> indexed by inode number. These files are populated by a chcap tool,
> see next mail.
>
> This fs capability system should work on all filesystem, which can
> provide long dotted names and have some sort of inode. Another benefit
> is, when holes in files are allowed. Otherwise the .capabilities file
> could grow pretty large.
>
> I use this on an ext2 filesystem. It boots and seems to work so far.
>
> Comments?
His-fscking-terical. Seriously, what comments do you expect? To start
with, on a bunch of filesystems inode numbers are unstable. Moreover,
owner of that file suddenly gets _all_ capabilities that exist in the
system, ditto for any task capable of mount(2), ditto for owner of
root directory on some filesystem. And there is no way to recognize
that file as such, so additional checks on write(), mount(), unlink().
etc. are not possible. And that is not to mention that binding of
non-root will play silly buggers with the entire scheme.
IOW, idea is unsalvagable.
Alexander Viro <[email protected]> writes:
> On Fri, 18 Oct 2002, Olaf Dietsche wrote:
>
>> This patch adds filesystem capabilities to 2.5.42, but it applies to
>> 2.5.43 as well.
>>
>> It's very simple. In the root directory of every filesystem, there
>> must be a file named ".capabilities". This is the capability database
>> indexed by inode number. These files are populated by a chcap tool,
>> see next mail.
>>
>> This fs capability system should work on all filesystem, which can
>> provide long dotted names and have some sort of inode. Another benefit
>> is, when holes in files are allowed. Otherwise the .capabilities file
>> could grow pretty large.
>>
>> I use this on an ext2 filesystem. It boots and seems to work so far.
>>
>> Comments?
>
> His-fscking-terical.
Yes, I like it very much, too ;-)
> Seriously, what comments do you expect?
Seriously, I'm more or less a newbie in this area, so I want thoughts
and suggestions from more experienced people. That's what this list is
about, isn't it?
> To start
> with, on a bunch of filesystems inode numbers are unstable.
Not really a problem, so restrict it to stable inode systems only.
> Moreover,
> owner of that file suddenly gets _all_ capabilities that exist in the
> system,
Yup, like root for example.
> ditto for any task capable of mount(2),
How's that? I think this task must own the filesystem and root
directory too.
> ditto for owner of
> root directory on some filesystem.
Which is a problem for foreign (network) filesystems only. Should be
solvable with a mount option (i.e. mount -o nocaps ...).
> And there is no way to recognize
> that file as such, so additional checks on write(), mount(), unlink().
> etc. are not possible.
Depends on, wether I want to recognize it and do these checks. Anyway,
could be solved with a mount option too or something like quotactl(2)
maybe.
> And that is not to mention that binding of
> non-root will play silly buggers with the entire scheme.
I don't understand this sentence. What do you mean with "binding of
non-root"?
> IOW, idea is unsalvagable.
I'm working on it. Thanks for sharing your thoughts.
Regards, Olaf.
On Sat, 19 Oct 2002, Olaf Dietsche wrote:
> > To start
> > with, on a bunch of filesystems inode numbers are unstable.
>
> Not really a problem, so restrict it to stable inode systems only.
So exec.c code should go looking for fs type and try and match it
against some table? OK...
> > Moreover,
> > owner of that file suddenly gets _all_ capabilities that exist in the
> > system,
>
> Yup, like root for example.
>
> > ditto for any task capable of mount(2),
>
> How's that? I think this task must own the filesystem and root
> directory too.
mount --bind my_file /usr/.capabilities
> > ditto for owner of
> > root directory on some filesystem.
>
> Which is a problem for foreign (network) filesystems only. Should be
> solvable with a mount option (i.e. mount -o nocaps ...).
>
> > And there is no way to recognize
> > that file as such, so additional checks on write(), mount(), unlink().
> > etc. are not possible.
>
> Depends on, wether I want to recognize it and do these checks. Anyway,
> could be solved with a mount option too or something like quotactl(2)
> maybe.
Ahem. You had made several capabilities equivalent to "everything".
E.g. "anyone who can override checks in chown() can set arbitrary
capabilities", etc. Which changes model big way and makes the affected
capabilities pretty much useless - they can be elevated to any other
capability.
> > And that is not to mention that binding of
> > non-root will play silly buggers with the entire scheme.
>
> I don't understand this sentence. What do you mean with "binding of
> non-root"?
mount --bind /usr/bin /mnt
Suddenly /mnt/foo and /usr/bin/foo (same file) have different capabilities.
On Friday 18 October 2002 21:07, Olaf Dietsche wrote:
> This patch adds filesystem capabilities to 2.5.42, but it applies to
> 2.5.43 as well.
>
> It's very simple. In the root directory of every filesystem, there
> must be a file named ".capabilities". This is the capability database
> indexed by inode number. These files are populated by a chcap tool,
> see next mail.
>
> This fs capability system should work on all filesystem, which can
> provide long dotted names and have some sort of inode. Another benefit
> is, when holes in files are allowed. Otherwise the .capabilities file
> could grow pretty large.
>
> I use this on an ext2 filesystem. It boots and seems to work so far.
>
> Comments?
Capabilities should be implemented as extended attributes; see Ted's recent
postings. Adding the necessary kernel infrastructure as extended attributes
is pretty simple. We will need to spend more time on producing good user
space tools, and figuring out ways so that the whole thing remains
manageable.
--Andreas.
Andreas Gruenbacher <[email protected]> writes:
> Capabilities should be implemented as extended attributes;
Why "should" this be implemented as extended attributes? What are the
benefits in doing so?
> see Ted's recent postings.
Ted's recent postings argue against capabilities at all. So what do
you mean?
Regards, Olaf.
Hi,
I believe that Capabilities on the file system are a useful thing. They
obviously also are quite controversial. If deployed without the right tools
they may certainly lead to less secure systems. So these supporting tools
need to be develped first, and some real-world experience seems necessary to
learn more.
Whatever the result of this process will be, should we decide to have
filesystem capabilities we would need to associate some pieces of information
with individual inodes, and this is exactly what Extended Attributes were
designed for. There are implementations for ext2, ext3, jfs, xfs, reiserfs,
so I think it makes no sense to reinvent the wheel. (Xattrs (or EAs) were
actually not invented for Linux; Irix and other OSes support almost identical
schemes.)
Do you happen to know the attr(5) manual page? An online version is available
at <http://acl.bestbits.at/cgi-man/attr.5>; perhaps that helps.
--Andreas.
On Monday 21 October 2002 17:25, Olaf Dietsche wrote:
> Andreas Gruenbacher <[email protected]> writes:
> > Capabilities should be implemented as extended attributes;
>
> Why "should" this be implemented as extended attributes? What are the
> benefits in doing so?
>
> > see Ted's recent postings.
>
> Ted's recent postings argue against capabilities at all. So what do
> you mean?
>
> Regards, Olaf.