Messages in this thread | | | Date | Tue, 6 Apr 1999 19:05:12 +0200 | From | Pavel Machek <> | Subject | Re: Subject: Re: ext3 to include capabilities? |
| |
Hi!
> I understand that. Read my concern again. I don't understand how > your system can possibly make my (already installed) 2.0.x kernel > ignore the setuid bit. I have 2.0.x around for stability, so putting > random patches into it isn't really an option. It seems like your > system will run programs with capabilities on 2.2.x but full-blown > setuid on 2.2.x, which opens up the security holes I'm concerned ~~~~~ 2.0.x > about
Ok. So use what other people proposed: make that program setuid _but_ _not_ _executable_.
And then learn 2.2.x kernel to launch non-executable files if they have suid bit set, are root-owned and contain capability-enhanced headers. [It is ugly. Being able to execute something which does not have executable bit set is ugly. But it should work.]
Pavel
> Basically, it seems like your system doesn't allow a secure fallback > for 2.0.x machines. It promotes capabilities-having bins to suid > ones under old kernels, which is a major bug IMO.
Look above.
> (second, less interesting portion of debate snipped -- adding EUID/ > UID/FSUID/SUID fields to the header solves that problem in kernels > that grok the scheme, but has the same issue of causing older kernels > to grant suid root to binaries that only want limited privs). > > Your idea does limit the fs data needed to one bit, and that's > something I don't mind. Using the suid bit as you suggest is > bogus, though. The sticky bit would work if it were limited to root, > but that's not an assumption that's workable in an NFS environment > (correct me if I'm wrong).
-- I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
- 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/
| |