Re: [PATCH] Capabilities, this time in elf section
Richard Gooch (rgooch@atnf.csiro.au)
Fri, 9 Apr 1999 23:22:24 +1000
Ingo Molnar writes:
>
> On Fri, 9 Apr 1999, Pavel Machek wrote:
>
> > > not required to contain a section table. And please do *not* change the
> > > header identification.
> >
> > Changing header ID is hack so that we can make executables that are
> > _not_ compatible with previous kernels.
>
> why not just make it not execute without any priviledges under older
> kernels? The mechanizm could be this:
>
> - extra section holding priviledge data, only used by newer kernels
> [this is your solution], plus:
>
> - new kernel 'fakes' a setuid root bit, so these binaries can be easily
> identified even with old (priviledge-unaware) 'ls'. (The executable
> bit is not touched.)
>
> - under old kernels the binaries are still usable, but will have
> sufficient rights only if you run them as root. (perfectly OK for eg.
> disaster recovery and generic robustness)
>
> - possible extra fcntl() for new kernels to further identify 'true'
> setuid root binaries, and 'faked' (ie. priviledge-enabled) setuid
> root binaries. new versions of 'ls' could use this fcntl(). (it's not
> a performance problems, the fcnt needs only be executed for setuid
> root binaries (both fake and real ones), which are rare)
>
> - 'fake' setuid root bits are _not_ exported through networked
> filesystems as a default.
>
> i believe this plan enables us to 'smoothly' move through the migration
> phase, and doesnt shut the door on older kernels either. Also it enables
> us to be aware of 'dangerous' executables, is secure (no normal user can
> generate a secure binary just by creating ELF sections), and doesnt export
> dangerous priviledges to networked systems automatically.
What happens when the suid-root bit is set by tar, cp and all the
others?
Also, what's wrong with exporting privileged binaries? We do that
already. That's why we have the nosuid option? The current setup gives
administrators the choice. Your scheme removes that, putting policy
back into the kernel (NFS won't support the cap bit).
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/