> -----Original Message-----
> From: Albert D. Cahalan [mailto:acahalan@cs.uml.edu]
> Sent: Wednesday, June 14, 2000 4:59 PM
> To: Jesse Pollard
> Cc: acahalan@cs.uml.edu; Jesse Pollard; pavel@suse.cz;
> pavel-velo@bug.ucw.cz; Joseph Gooch; linux-kernel@vger.rutgers.edu
> Subject: Re: Ke: Process Capabilities on 2.2.16, Sendmail problem
> revisited
>
>
> 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.
A util similar to lsattr with a recursive functino could provide the same
functionality for fs caps.
> >>> 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.
No argument here. Only problem being last I knew, elfcap only allowed you
to drop privs, not elevate them. Elevating caps implies uid 0. By needing
setuid root for a capability aware program you're depending on uid 0 anyway.
> >> 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.
No capabilities will be passed on from distributed files if they're in the
filesystem. Anyone can modify the ELF header. (well, anyone with write
access, but they need not be privileged) They may not be in effect until
run by root, but they're still there, a time-bomb waiting to happen.
> >>>>> 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.
Patches to cpio/tar are easy enough, in either case. Capabilities are a big
step, you have to expect application changes either way.
> > 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.
Elcap implies that someone can assign capabilities to any file they have
write access for. They aren't active until run by root or suid root. I can
see a whole slew of symlink or /tmp issues comin on...
> > 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.
This is going to be an opinion either way.
> > 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.
Existing admin scripts will not find elfcap capabilities either. It'll find
the setuid bit but not capability problems. Changing scripts will be easy
either way.
> >> 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 don't agree, but this is an opinion as well.
> > 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.
Completely false. Check out the linux-acls project, they put ACL
information in the inode and yet it works in an ACL aware kernel and an ACL
unaware kernel. Just only fsck it with an ACL aware fsck, which would be
available in either case.
> Problem: somebody wants to run a secure system from a standard
> CD-ROM filesystem.
Permissions are there already, as well as many extensions. Making a
modification there isn't that hard either. For that matter, make ext2 cds.
It'll only be read by linux but it'll have fs capabilities.
> 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.
We have global capability masks for this purpose. This doesn't follow with
the discussion at all as you need a blocking set for this, which doesn't
exist (yet).
> > Any filesystem should work with root privilege (well...
> excluding dosfs).
>
> The in-memory system would even work with dosfs.
Only if you ran it as root (no suid bits :))
Here's a question. Is there any reason why we can't do both? They could be
configurable in the kernel so that you can do one or the other or both. I
don't see any reason why not. This issue is so divided and based on opinion
and experience that allowing both is a simple compromise that should keep
both sides happy.
Joe Gooch
-
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