lkml.org 
[lkml]   [1999]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: caps in elf, next itteration (the hack get's bigger)
On Wed, 14 Apr 1999, Ingo Molnar wrote:

> no. This is a misconception. The point is to reduce the power of
> actually executing security-relevant code, thus reduce the chance of a
> system compromise. Having some sort of (mostly inactive!) super-user
> around in the migration period is not at all broken. The point is to
> get rid of random setuid root binaries (ping, traceroute, etc.) and
> system daemons (klogd, syslogd, lpd, etc.) executing with full system
> priviledges. A considerable percentage of those binaries needs only a
> small subset of system priviledges. We do _not_ want to remove the
> administrator, that is a different task.

Thoughts for the day:

What capabilities will we want? Will they be defined by the admin
themselves, or will it be a full set of capabilities available to the
admin?

What I'm concerned about is that if we go ahead and build a capability
enabled system, and then those POSIX boys go and define their own idea of
a capability system, these two could prove to be incompatible. That would
be a disaster. Have the POSIX people actually defined the capability
standards yet? If not (or if they are in the middle of deciding that),
there's NO point in doing anything UNTIL we have a STANDARD that all
UNIXes will conform to. And then there's the question of capabilities over
shared networked filesystems (especially on a network populated by
different UNIX systems).
Looking over the discussions on this subject for the past week or so, it
looks like we're trying to kludge capabilities into Linux. I especially
don't like the suggestions that capabilities be built into the filesystems
- this has the potential to make it completely unportable to different
filesystems (i.e trying to run Linux off NTFS for example 8)

One potential answer might be *firstly* define a newer ELF standard that
is completely incompatible with the current ELF standard which will ensure
that older kernels booted on a capability-enhanced system will NOT be able
to run ANYTHING, thus closing that security hole, and *secondly*
capability-ehanced kernels SHOULD not be able to run older ELF binaries.
Then we can properly encode capabilities into the binaries, yet enforce
security.

I like this idea. A lot. Hey, if we're gonna break free from the past,
let's go the whole hog and add in ACLs too. We do want that A1/B1 security
rating, don't we? 8) We all know Microsoft has lost to us, but we haven't
really won against certified operating systems such as VAX/VMS.

Ah, this thought just hit me just now. What we're trying to do is clone
VAX/VMS!! 8)

Cheers,
Alex
--
/\_/\ Legalise cannabis now!
( o.o ) Grow some cannabis today!
> ^ < Peace, Love, Unity and Respect to all.

http://www.tahallah.demon.co.uk - Now back in the United Kingdom!







-
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    [from the cache]
©2003-2011 Jasper Spaans