lkml.org 
[lkml]   [2002]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Filesystem Capabilities in 2.6?
I see no one has responded to this yet, so I'll ask again.

Does anyone have any comments about my idea outlined below?

Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu

http://dilbert.com/comics/dilbert/archive/images/dilbert2040637020924.gif


On Sun, 3 Nov 2002, Patrick Finnegan wrote:

> On 3 Nov 2002, Alan Cox wrote:
>
> > On Sun, 2002-11-03 at 02:03, Linus Torvalds wrote:
> > > So I'd suggest _not_ attaching that capability to the sendmail binary
> > > itself, or to any inode number of that binary. A binary is a binary is a
> > > binary - it's just the data. Instead, I'd attach the information to the
> > > directory entry, either directly (ie the directory entry really has an
> > > extra field that lists the capabilities) or indirectly (ie the directory
> > > entry is really just an "extended symlink" that contains not just the path
> > > to the binary, but also the capabilities associated with it).
> >
> > So what are the semantics for writing to the file. If I modify a setuid
> > (or setpartlysetuid) type file then I wan't the setuidness revoked as
> > happens now. That is done for very good reason. Your system appears to
> > need a scan of the entire file system to find directory references to
> > this object, done atomically.
> >
> > > The reason I like directory entries as opposed to inodes is that if you
> > > work this way, you can actually give different people _different_
> > > capabilities for the same program. You don't need to have two different
> > > installs, you can have one install and two different links to it.
> >
> > I'll trade 500K of disk space for a working security model especially as
> > the case in question is not that common.
>
> Here's a random idea, it has problems, but seems workable to me:
>
> 1) Add a standardized exported data structure to your ELF executable
> called "KERNEL_PROCESS_CAPABILITIES_v1" or another name you like, and
> have it as a fixed-length bit-array (null terminated) of capabilities,
> maybe 128 bits for version one. If extensions are needed later, we can
> fairly easily extend the length by aliasing it with another name, say
> "KERNEL_PROCESS_CAPABILITIES_v2" and sticking the extra bits at the end
> of the structure (or create a second structure...).
>
> 2) SUID root the binary like normal
>
> This is what the kernel does:
>
> 1) Checks if the binary is SUID root (uid 0), if not go on like normal.
>
> 2) If SUID root, and it's an ELF execuable, look for the ELF symbol(s)
> above; if not present, set uid to 0 and execute.
>
> 3) If caps are present, read them in, don't change UID/GID, set the caps,
> and execute.
>
> 4) If that process executes another process, drop all capabilities
>
> This could (probably be) extended to a.out format. To deal with scripts
> and 'binfmt_misc' stuff, you can create a capability called "CAP_WRAPPER"
> which allows capabilities to be transferred to the next process. When you
> execute that process, the kernel drops only that one flag, denying the
> wrapped executable from transferring capabilities.
>
> Here's some advantages:
> - No huge and wierd /etc/fstab[.d], and no mounting of files to gain
> capabilites, or other 'strange things'.
> - If the kernel doesn't recognize capabilites, it'll just SUID root the
> binary like normal
> - If the binary doesn't have capabilities listed, it'll just get SUID
> root like normal
> - Changing the binary still drops SUID root, and thus drops the
> capabilites
> - User can create wrapper 'binaries' fairly simply
> - Since the size of the bitfield for the capabilities is fixed, the user
> can modify capabilites inside a binary with that structure.
>
> Problems:
> - It's binary, not text, so possibly harder to read without tools.
> - Stripped binaries. This could be fixed by a small change:
>
> Instead of using a symbol to look up capabilites, use text in the
> executable eg:
>
> struct caps_t {
> int magic;
> char name[28];
> char caps[8];
> } kern_proc_caps =
> {0x1234AA55, "KERNEL_PROCESS_CAPSTRING_v1", ... };
>
> Comments?
>
> Pat
> --
> Purdue Universtiy ITAP/RCS
> Information Technology at Purdue
> Research Computing and Storage
> http://www-rcd.cc.purdue.edu
>
> http://dilbert.com/comics/dilbert/archive/images/dilbert2040637020924.gif
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

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

\
 
 \ /
  Last update: 2005-03-22 13:30    [W:0.172 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site