lkml.org 
[lkml]   [1999]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: caps in elf, next itteration (the hack get's bigger)
"David L. Parsley (lkml account)" wrote:

> This gets a bit hairy,

Yes.

> but to do this we need to modify the
> kernel's understanding of 'setuid 0'. To the kernel, being setuid 0 would
> mean that the program has elevated capabilities, and that not only the
> capability bitmasks are found in the elf header, but
> _also_the_file_owner_, and that the binary is _immutable_. Confused? I
> don't think _I'm_ confused so let me explain:

...

> 2) A file flagged with capability support is immutable untill that flag is
> unset; this prevents the file owner from directly modifying the binary to
> set all cap flags.

Hmm? Are you suggesting file access permissions should depend on the
contents of the file? I thought one of the leading design principles of
Unix was that the kernel treats files as an unstructured stream of
bytes, and that imposing some kind of structure (records etc) on files
is done entirely in user space.

Before you all start screaming that this isn't true: Yes, *of course*
the kernel knows about the ELF format, but this knowledge is restricted
to when the structure has some significance to the kernel -- when it is
about to exec a binary. You seem to be proposing that also the file
system code should be parsing arbitrary files to see if they can be
written to or not.

Johan Myréen
jem@iki.fi

-
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.085 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site