[patch included] Re: using capabilities to allow debug of suid-root programs

Andrew Morgan (morgan@transmeta.com)
Sat, 17 Apr 1999 12:53:03 -0700


This is a multi-part message in MIME format.
--------------993A1AE8EB35BD2123EFC9CE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peeter,

OK, that's the problem with trying to edit other people's examples
without testing them first. :*)

try this:

luser@here /> cd
luser@here /home/luser> touch this
luser@here /home/luser> ls -l this
-rw-r--r-- 1 luser luser 0 Apr 17 12:20 this
luser@here /home/luser> ./debugwrap rm this

I'm crossing my fingers that one does what I meant you to try. (The key
is that root can only remove files that root owns unless it has the
capability to do more.) In other words, root in this case should not be
able to remove luser's file. In your examples, root always owns the
file, so necessarily, it is able to manipulate them.

To the extent that capabilities are implemented in the kernel at this
time, removing all capabilities should make a uid=0 process 'just like'
any other user process (unable to manipulate other user's system
objects). This is mostly true, __except__ for the fact that uid=0 seems
to own almost all of a typical Linux system's system-files (not to
mention most of the /proc/ filesystem -- I've appended my patch for that
'hole' -- I'll also put it with libcap.)

> I guess I misunderstand the concept here. I thought that capabilities were
> a mechanism to allow one to be more selective in allowing root permissions
> to non-root userids (so that you don't have to give out "root" userids).

That's the eventual goal, but the 2.2 filesystem support was vetoed. I
actually wrote kernel patches for 2.0.x to modify ext2 to store them,
but the ext2 guys decided that it needed to be done a different way and
now it looks like Linus has pretty much insisted that people don't mess
with ext2 any more but put it into something like ext3.

The capabilities in the kernel are effectively just implementing a
per-process superuser mask. There is CAP_SETPCAP, but I'm personally not
convinced this can be used securely (and its thankfully mostly off by
default).

Hope that clarifies things.

Cheers

Andrew
--------------993A1AE8EB35BD2123EFC9CE
Content-Type: text/plain; charset=us-ascii; name="uid-proc.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="uid-proc.patch"

diff -urN linux-2.2.1/fs/proc/inode.c linux-caps/fs/proc/inode.c
--- linux-2.2.1/fs/proc/inode.c Fri May 8 18:10:30 1998
+++ linux-caps/fs/proc/inode.c Sun Jan 31 00:02:05 1999
@@ -267,10 +267,19 @@

inode->u.generic_ip = (void *) de;
if (de) {
- if (de->mode) {
+ if (de->mode) { /* why conditional on non-zero mode? */
+ struct inode *sbi;
+
inode->i_mode = de->mode;
- inode->i_uid = de->uid;
- inode->i_gid = de->gid;
+
+ if ((ino != PROC_ROOT_INO)
+ && (sbi = sb->s_root->d_inode)) {
+ inode->i_uid = sbi->i_uid;
+ inode->i_gid = sbi->i_gid;
+ } else {
+ inode->i_uid = de->uid;
+ inode->i_gid = de->gid;
+ }
}
if (de->size)
inode->i_size = de->size;

--------------993A1AE8EB35BD2123EFC9CE--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/