Messages in this thread | | | Date | Mon, 12 Apr 1999 18:45:53 +1000 | From | Richard Gooch <> | Subject | Re: caps in elf, next itteration (the hack get's bigger) |
| |
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/
| |