Re: caps in elf, next itteration (the hack get's bigger)
Richard Gooch (rgooch@atnf.csiro.au)
Mon, 12 Apr 1999 18:45:53 +1000
johan.myreen@setec.fi writes:
> "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 wo=
> uld
> > 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.
I don't see the problem. A suid-root binary is immutable for everyone
but root. Only root can grant capabilities. If some user is allowed to
create binaries with privileged port access, then they just need to
run a privileged binary which adds CAP_PORT to the binary.
The mechanism is that the cap header is created/modified, the owner is
changed to root and the suid bit is set.
No problems. Much safer than overloading the sticky bit, since access
to the sticky bit is not universally restricted, which is a major
security hole. On the other hand, access to root-owned files is
universally restricted.
Regards,
Richard....
-
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/