[cap-talk] [Apparmor-dev] Re: execve() and CLOEXEC

[Mark Seaborn]

Crispin Cowan <crispin at mercenarylinux.com> wrote:

> That it is fairly easy to produce a safe way to program this stuff does
> not instantly make all of the existing vulnerable software go away. So
> while I encourage techniques like safe wrappers for execve() to address
> this problem, that doesn't remove the need for an AppArmor policy
> mechanism to block this vulnerability.

There is a need for a mechanism to block this vulnerability but it is
not necessarily a need for an AppArmor mechanism or a policy
mechanism.  e.g. Closing FDs could be done in glibc.  You might prefer
to centralise the information on whether FDs should be closed on exec.
In that case, the kernel could pass in a flag via the auxv.  I'm not
saying that is the best approach, but let's at least consider it.


> > If you have a program that does not need to pass FDs across execve()
> > (other than stdin/stdout/stderr), you could change its execve() call
> > to close any offending FDs (perhaps logging a warning) or halt with an
> > error if there are any offending FDs.  Again, that can be done in the
> > kernel or in glibc.
> >   
> This is essentially what I propose: if the profile for a program does
> not permit implicit delegation, the it closes the FDs on exec() whether
> that was specified or not.

Are you proposing to do a closefrom(3)?  i.e. Close all FDs except
stdin/stdout/stderr.

My understanding was that you were proposing to close FDs that the
callee executable's profile would not normally allow it to access.

I would much prefer to do closefrom(3).  It's simpler and more
predictable.  Though it would break code that passes FDs across
execve() sooner, that can be positive because it would make
problematic code easier to discover.

> But we can do that in AppArmor policy by making FD delegation
> selectable, rather than by changing the programs or libraries.

Yes, but that's coarse-grained.  What if you have a process that
should exec one executable while passing FDs, and another executable
it should not pass FDs to?  Ultimately you need to fix programs, and
do to that you need an upgrade path -- in this case, a safe interface
that you can tell programmers to use instead of the unsafe interface.


> >> I've made this complaint before, it is an unfortunate habit of the OC
> >> community to overload the meaning of common words such as "authority",
> >> "permission", and in this case "designation" with specific technical
> >> meanings. It confuses people from outside the community, and because the
> >> technical terms are all common words, it makes it hard to google for.
> >>     
> > Perhaps you should raise this issue on the cap-talk mailing list?
> > (CC'ing cap-talk)
> >   
> Complaining about well-established jargon in a discipline as old and
> entrenched as Object Capabilities, is not going to do anything. I'm just
> being a whiner because I didn't know what he meant.

OK, but the discipline was originally known as "capability security",
and we've had to switch to the term "object-capability" because other
people (including you :-) ) have been stealing the term "capability"
(e.g. "POSIX capabilities").  Even the term "object-capability" is not
precisely defined because I believe some take it to exclude weak
capabilities (aka. password capabilities, as in Amoeba).

Please subscribe to cap-talk though or at least look at the archives
because there have been some posts in this cross-list thread that
didn't make it to apparmor-dev, and your posts don't make it to
cap-talk.  BTW, is there an archive for apparmor-dev other than
<http://marc.info/?l=apparmor-dev&r=1&w=2>?


> > When Rob says that this is a designation problem rather than a
> > delegation problem he means that the problem is that calls to execve()
> > do not designate the FDs to pass.
> >   
> So "designation" in OC means the way you specify (designate) the
> capabilities to be delegated?

Yes.  The slogan is that capabilities unify designation and
authorisation.  A capability designates a specific object, and passing
a capability to another process authorises that process to access the
object.

> I find there is often simple translations of OC terminology. The most
> important such observation of mine is that "authority" is precisely the
> transitive closure via communications of permissions.

That's not what authority means.  From "Paradigm Regained:
Abstraction Mechanisms for Access Control"
(http://www.hpl.hp.com/techreports/2003/HPL-2003-222.pdf):
"Authority describes effects a program may cause on objects it can
access, either directly by permission, or indirectly by permitted
interactions with other programs. To understand authority, we must
reason about the interaction of program behavior and the arrangement
of permissions."

For example, suppose we have a file object F and we wrap it to give a
read-only proxy object F2:

F2 = ReadOnlyProxy(F)

F2 only conveys authority to read file F, not to write to it.
Determining that depends on analysing the behaviour of the
implementation of ReadOnlyProxy.  If you know nothing about
ReadOnlyProxy's behaviour, you can make a worst-case approximation and
say that F2 might convey write access to F.

So "transitive closure via communications of permissions" is a
worst-case approximation of authority.

Here is a real implementation of a ReadOnlyProxy:
http://svn.gna.org/viewcvs/plash/trunk/src/filesysobj-readonly.c?rev=621&view=auto

Regards,
Mark