Quoting Markku Savela (msa@moth.iki.fi):

quoted text
> > From: Theodore Tso

>

> > The reason for that was to avoid bugs where a program that wasn't

> > expecting to be setuid (or just written by a stupid progammer) exec's

> > some program which wasn't expecting to have root privileges then bad

> > things happen.  The classic example of this was running the mail

> > program, which was setuid or setgid to the mail user/group, and then

> > typing "!/bin/sh" which would exec a shell running with those

> > privileges (because the mail program didn't know to drop its

> > privileges).

>

> Considering the current case, without the file capabilites, I note

>

> - if the caller of /bin/sh is ROOT, the capabities are inherited. Thus

>   my request has no relevance in that case.

You're misinterpreting the empirical evidence.
If the caller is root, then capabilities are not "inherited."  Rather,

if you are running in !issecure(SECURE_NOROOT) (which everyone is right

now), then we fake an all-powerful root by filling the file capability

sets at exec.  So it's not that the task's capabliities are inherited.

Rather, it's that as the capabilities are recalculated, we pretend that

the file had full capability sets.
That's very different, but leads to the same results in your example

above.
> - if the caller does first setuid to non-root, the capabilities are

quoted text
>   cleared, unless KEEP_CAPS is explicitly set. Thus, my requested

>   change would not cause problems with your buggy mail program.

>

> - if the caller goes through all the trouble of setting KEEP_CAPS and

>   changing to non-root, I would expect it to be sensible that the

>   caller also intends the execve code to inherit capabilities.

>

> As an experiment and example, I made a small patch to Ubuntu 2.6.24

> kernel, to make it work like I think it should: if KEEP_CAPS is set,

> they are inherited (see at end).

>

> I'm ok with the current kernel code, which seems to clear the

> KEEP_CAPS on execve. Thus, each executable must again re-enable it, if

> it needs capabilities inherited further...

>

>

> > So in the capabilities model, the capabilities do *not* inherit unless

> > the a particular file explicitly states that it should inherit the

> > capabilities.  It's the principle of least privilege taken to its

> > logical conclusion.

>

> I'm looking at network oriented devices, where executables or

> interpreted content from network sources is executed by helper

> applications or directly as executables. Depending on the source of

> the "code", the helper application or the downloaded exectuable may be

> allowed to run with different permissions (capabilities, uid/gid

> etc). [For example, look at android security model with manifests of

> requested and declared permissions, but applied to everything

> downloaded or installed].

>

> File capabilities (nor selinux) won't work, because the "helper

> applications" need to be executed with different capabilities and

> permissions, depending on the "manifests" of the downloaded

> "code". Obviously, serious permissions are granted only to properly

> verified "code" (signed).

Both capabilities and selinux will allow:
	1. the same binaries to be executed with different

	   privileges/permissions depending on the context of

	   the caller.
	2. different binaries to be executed by the same caller

	   resulting in different privileges/permissions.
(that answers your next question)
>   [Any ideas how selinux would help to enforce a permission which is

quoted text
>   dynamically defined by installing application?]

-serge

--

unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please read the FAQ at  http://www.tux.org/lkml/