[lkml]   [1998]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Secure-linux and standard kernel
MOLNAR Ingo wrote:
> the point is, we dont even need the filesystem set-capability stuff. By
> including this feature in the ELF loading mechanizm somehow, _all_
> filesystems (that support setuid root) will benefit from this, not only
> ext2fs. Theoretically, we only need a single bit in the inode to indicate
> that a binary is trusted. The rest can be done in ELF-land.
> hm? this is really part of the 'executable' proper, _not_ of the
> filesystem. capabilities are inherently associated with binary executable
> code. There is no point in allocating capabilities bimask for say a news
> spool article file ...

I retract my previous position. You are probably correct. This somewhat
flys in the face of the traditional UNIX model of having all
protection-related information in the inode but the benefits may outweigh

Some food for thought:

1. When selecting a method to encode the capabilities into the ELF binary,
it should be a high priority to select something so that the information
can easily be retrived, preferably by file(1).

2. How bad is it that we're limited to ELF? Is it important to allow
things like capability-enhanced perl scripts, for instance.
set[ug]id perl scripts are fairly common now.

3. Remember that unlike ext2-level checks there will be no way for the
kernel to prevent the owner of the file from changing its capabilities.
Obviously it would refuse to honor them for non-suid-root files but
what about protecting from root? This works against the division-of-root
concept of capabilities. I'm not familiar enough with the eventual
direction of the capabilities stuff and how it will interface with
the traditional uid=0 to say whether this is bad or not. Make sure
that there aren't any security implications with allowing uid=0 to
implicitly set any capability on any binary, regardless of what
capabilities are currently in effect.

I think this idea needs some hashing out, but I now see that it has some good


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

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