lkml.org 
[lkml]   [1999]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: caps in elf headers: use the sticky bit!
Hi!

On Sun, 11 Apr 1999, Martin Mares wrote:

> Hello!
>
> > No, the kernel still must perform checks before a process creates a file
> > with the sticky bit (=cap flag) set. Similar to the current situation
> > where root can unpack a setuid root binary, but a normal user cannot.
> > Currently, the kernel doesn't care anything about the 'sticky' bit on
> > files; I'm just saying let's use it for something useful.
>
> It won't solve the `old kernel' problem.
>
> If you overload setuid bit functionality, it will open a security hole
> on older kernels not understanding this extension. (It can bite you only
> if you share files between machines running different kernels or if you
> switch kernels on the same machine, though.)
>
> If you use the sticky bit for this purpose, a similar situation
> can happen: a normal user sets the sticky bit for a file when running
> an old kernel where it isn't restricted and then the file becomes
> privileged after switching kernels. This can be solved by ignoring
> the sticky bit on files not owned by root.

Yes, I see exactly what you mean. Certainly we would need a tool to use
when switching to the enhanced kernel that would check for capability
enhanced binaries. And it caps would need to be configurable for nfs,
much in the same manner as root squash. It's the sort of thing where,
once you switch over, you really can't (shouldn't) go back.

> > This is _exactly_ what I'm trying to accomplish; by using the sticky bit
> > in the way I've suggested, we can effectively add capabilities to the fs
> > in a nicely compatible way. Think of it this way: when a process tries to
> > set the sticky bit on a file (=cap flag) or create a file w/ that bit set,
> > the kernel reads the capabilities from the elf headers and applies the
> > same checks as if the process were trying to set caps in the fs (as we'll
> > have with ext3).
>
> Parsing file contents in sys_chmod() is plain ugly.

Well, yes, I agree; except that it's generally going to be a rare event.
Of course, you may just be referring to the fact that accessing the file's
contents _at_all_ is a difficult thing to do from sys_chmod(), which I
understand and agree with as well... we'll just have to look at it and
decide whether it's worth it.

>
> Have a nice fortnight
> --
> Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
> Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
> "WINDOWS - What Idiotic New Disk Operating Windowing System!"
>

- --
David L. Parsley
Network Specialist
City of Salem Schools


-
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/

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