"Albert D. Cahalan" <acahalan@cs.uml.edu>:
>
> Jesse I Pollard, II writes:
> > Pavel Machek <pavel@suse.cz>:
>
> >>> When I install software, I try to install it as non-root.
> >>> This prevents the normal creation of setuid binaries that
> >>> I don't know about. The number
> >>
> >> Fine. You have no problems with elfcap, then. Noone has setuid 0 bit,
> >> you don't have to examine anything, elfcaps are nop.
> >
> > THEY ARE NOT - I may use them as root. Someone else may use them as root.
>
> Well, that would be pretty stupid of you, wouldn't it?
> Why in hell are you running trojan binaries as root?
> Why did you give this clueless "Someone else" admin power?
Not my choice. I only audit the systems. The way elfcap is implemented means
I cannot audit the executables.
> Just as programming languages can not prevent bugs, security
> systems can not prevent complete administrative abuse.
> Not even MAC can prevent this kind of error... if an install
> program asks you to grant it MAC override, do you do so?
If MAC override is in some piece of junk like elfcap then I have no audit
control to determine if it is there.
> > they may have passed the initial testing and appear as quite normal
> > applications UNTIL they are run as root. Even on a system with root
> > having no privileges, suddenly this program becomes privileged.
>
> See, there is your mistake. It is foolish to think that it is
> practical to have root without privileges. Just disable the account.
> (set the password entry to '*' or adjust the kernel as desired)
Works fine on many systems.
> One should also maintain control over setuid executables by blocking
> their creation, blocking their use with mount options, auditing the
> use and creation, etc.
Creating a setuid program should be prevented by the system as a security
violation in the first place.
> >>> of binary only installation software is very large, since many vendors do
> >>> not want the installation procedure modified. Since I can't look at the
> >>> binaries before installation, I can only look at them afterward. elfcap
> >>> makes it necessary to examin every file (executable or not) to search for
> >>> trojan horses with improper capability assignments.
> >>
> >> No. Just search executable being setuid 0 for trojan horses. Elfcap is
> >> nop for binaries not being setuid 0. Take a look at code.
> >
> > did. and I repeat:
> >
> > NO ELFCAP. not secure, not reliable, not auditable.
>
> Oh bullshit. You've not proven any of that. I can well imagine
> that one might think elfcap is ugly, but it gets the job done.
> It is just horrible to require exotic filesystem features and
> exotic backup tools when they shouldn't be needed at all.
It is only reasonable as a prototype, not production.
The filesystem features are neither horrible nor are exotic backup tools
needed. I help oversee UNICOS systems using MLS + capabilities using
cpio for backup, which does not need special privileges to perform backups.
If a root system has to be restored, it is done in single user mode, THEN
the specified privileges (capabilities) are assigned to the relevent images.
After that, the system can be booted into multi-user mode.
Users should not be able to create setuid files.
Users should not be able to assign capabilities.
Any use of a capability is a security event.
Any attempt to use a capability that is not authorized is a security violation.
The level audit logging is up to the facility.
> As of now, the only other practical proposal was the one that
> involved registering privileged executables with the kernel,
> using an in-memory set of capabilities and an immutable bit.
That is very ugly, but it is secure. And the proposals to use ext2 or
XFS to store capabilities in the inode are practical, and secure.
> It is about time that you admit elfcap gets the job done.
Again, it is only reasonable as a prototype. It is not reliable, nor
fully enforcable as it stands. It is no better than setuid, and it
diffuses the ability to audit setuid since the actual priviliges are
not apparent. That makes it difficult/impossible to have a verifiable
audit.
I want BETTER. There are standards (even if draft) that do define a better
way. Ext2 already has the storage assigned. XFS already has the storage
assigned. All that is left is completing and validating the implementation.
That is in the works by at least two different approaches. Which will be the
better is still open (assuming only one, both may be desirable).
I see no problem with a requirement that the root filesystem be one of
these when the system is going to be used for a capability-only privilege
operation.
Any filesystem should work with root privilege (well... excluding dosfs).
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:32 EST