Yes there is. "root" == administrator. Just because you have
capabilities doesn't mean you have to discard root. Capabilities are a
way of refining privileges, so you get something between average luser
and root. This in no way implies that average luser or root or
privileges or accounts are discarded.
> > Suid-non-root binaries are different: they switch identity. The kernel
> > doesn't check the ELF CAP header.
>
> What happens then to poor user whose UID is 0 by accident?
Won't happen. UID=0 is root, and means something special. A
capabilities-enabled system doesn't change that.
> > If some ordinary user wants to create a binary that grants
> > capabilities *to others*, he must ask the sysadmin for permission. If
> > the sysadmin agrees, he runs a tool to edit/audit the ELF CAP header
> > and then chowns to root and chmod u+s.
>
> This whole idea is way too complicated, IMHO. Capabilities are
> essentially refinements of the S[UG]ID bits for executables, and
> should be handled in a similar way. Sure, that screws tools that
> don't know about them. But you will need new tools anyway (see
> above). And the new tools have to be carefully designed, built and
> audited if the whole concept is to make any sense at all. This
> includes the kernel mechanisms to enforce the restrictions set
> out. Better if they are _simple_, there is exactly _one_ way of
> representing caps (i.e., either in the file (unsatisfactory, IMO) or
> in metadata for a capability-aware filesystem).
There is no practical reason why storing capability information in an
ELF header won't work.
> If you use a capability enhanced filesystem, you have a reasonable
> upgrade path: For now, SUID root is as today even with caps set. You
> can mount the filesystem with either caps, suid, sgid, or any
> combination enabled. If caps isn't there, some new executables that
> aren't SUID root break horribly since they haven't got the
> capabilities to do their jobs, but that is to be expected (and can
> be fixed making them SUID root for now). Old stuff works fine via
> S[UG]ID. After replacing the old SUID root affected binaries (a very
> few!) you get rid of the special meaning of root, and everything is
> fine again. Taking tar(1), cp(1) or such to the files is inocuous,
> as capabilities aren't being smuggled around (compare to "cp
> /bin/login ~").
You actually *want* capabilities to be copied around with tar, cp and
friends. I don't want to use special tools to backup or copy my
system.
> Please do not screw up the capability handling forever for the sake of a
> temporary partial relief! Linux is characterized by doing things the
> _right_ way, even if it hurts.
>
> What is needed for starters:
>
> - fsck(8): Needs to be modified/rewritten anyway
> - dump/restore: Write from scratch anyway
> - mount(8): Needs modification anyway (shouldn't be hard)
> - setcap(8): Needs to be written anyway
> - ls(1), or lscap(1): Has to be done each way
> - find(1) needs to be capability-aware
>
> Anything essential missing here?
tar, cp, cpio, gzip, bzip2, NFS, CODA, rdist and many more, I'm
sure. I've got a backup programme written in C which would lose
capability information unless I went in an added a Linux-specific hack
to it. I'm sure there are dozens or hundreds of similar "personal"
programmes out there that will break.
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/