lkml.org 
[lkml]   [1998]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Secure-linux and standard kernel
Hi,

On Fri, 26 Jun 1998 08:03:55 +0200 (MET DST), MOLNAR Ingo
<mingo@valerie.inf.elte.hu> said:

> On Thu, 25 Jun 1998, Horst von Brand wrote:

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

>> Yes, but they *can't* be part of the binary executable itself: It
>> would be just way too easy to fake them. [...]

> i think you are overlooking the fact that the kernel only evaluates this
> 'extra info' if the given binary is a setuid root binary. Which means it's
> contents are absolutely trusted.

You are overlooking the fact that in a posix.6 capabilities
environment, there _is_ no trusted root user, and no single superuser
privilege. The entire point of the capability mask is to eliminate
that.

Having a _separate_ ext2fs attribute which conferns capability trust on
a binary is possible, but in posix.6, suid root on its own is a
perfectly valid trust property on an executable which quite explicitly
grants the root uid (and hence access to root owned files etc.) without
granting any other capabilities.

There are many reasons why you might want to let a process become uid
root in such an environment. However, you do not want to confer
capability-setting privileges to all root-owned processes.

--Stephen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:43    [from the cache]
©2003-2011 Jasper Spaans