Jesse I Pollard, II writes:
> "Albert D. Cahalan" <acahalan@cs.uml.edu>:
>> Jesse I Pollard, II writes:
>>> Pavel Machek <pavel@suse.cz>:
>>>> 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.
...
> If MAC override is in some piece of junk like elfcap then I have
> no audit control to determine if it is there.
You'd better explain what kind of "audit control" you are
expecting, because this doesn't make any sense to me.
Do you want to look for privileged executables? If so, elfcap
is little different than inode-based bits. You can use the
proper search tool in either case. Elfcap does have the advantage
of giving you a quick check via regular "find" though. The real
winner here is the in-memory system, since the kernel could provide
a list via /proc.
Do you want to to record creation of privileged executables?
No problem, this comes free with setuid-creation data.
>>> 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.
I'm sure it works "fine" until an app screws up. The world is
filled with code that assumes UID 0 is special. You aren't serious
about security until you stop allowing UID 0 processes.
>> 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.
Eh... so should creating a capability-enhanced program under
your preferred design. Exceptions must be made in either case,
otherwise you couldn't even install the system.
See, you had made some claims about suddenly having privileged
executables on the system. That just won't happen, except due
to errors that affect both elfcap and your preferred design.
>>>>> 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.
There you go, using an exotic backup tool. (not cpio, I mean the
tool used to assign privileges after cpio is done)
If you actually LIKE doing that, surely GNU cpio has an option
to ignore setuid bits.
> Users should not be able to create setuid files.
> Users should not be able to assign capabilities.
No problem.
With elfcap, inability to create setuid files implies inability
to assign capabilities. Even better, inability to create files
owned by root also implies inability to assign capabilities.
An attacker would have to do both, to the same file, at the same time.
If random users can do this, you have a problem even without elfcap.
> 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.
So what? Elfcap can handle this perfectly well. Like the other
two proposed systems, elfcap is a kernel feature. You can trust
that the logging will happen.
>> 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.
It is the least ugly and the most secure.
> And the proposals to use ext2 or
> XFS to store capabilities in the inode are practical, and secure.
Security is reduced because existing admin scripts will not find
the XFS or ext2 extensions. Capability bits have enough trouble
with compatibility just by design; filesystem hacks make them worse.
>> 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.
Filesystem hacks are least reliable, least enforcable,
and least apparent. Only the in-memory system can beat elfcap.
> 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.
Problem: due to compatibility problems and management complaints,
a site decides to go back to the old way... but the filesystem is
now unreadable by the old kernel.
Problem: somebody wants to run a secure system from a standard
CD-ROM filesystem.
Problem: for an NFS-root system, one would very much want to avoid
letting users get raw network access... NFS is bad enough, and you
would not let NFS-root users try to defend themselves.
> Any filesystem should work with root privilege (well... excluding dosfs).
The in-memory system would even work with dosfs.
-
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