Re: Bug in how capability inheritance is handled in "fs/exec.c", 2.3.99

From: Theodore Y. Ts'o (tytso@MIT.EDU)
Date: Wed May 31 2000 - 09:32:23 EST

   Date: Tue, 30 May 2000 17:15:56 -0700
   From: Casey Schaufler <>

> Sigh. This stuff reads like a bad physics text. This discussion would
> REALLY benefit from all of us being in the same room together with a
> good chalkboard and some good beer. I've tried discussing capabilities
> via e-mail before, but it just stinks.

   I concur*. It is unfortunate that the POSIX work died, and that
   another forum hasn't presented itself to replace it. If someone
   (NIST? SGI? Casey's Capability Clearance Center?) held a workshop
   would anyone show up? How about if I supplied the beer?

   * Especially the part about good beer!

Hi Casey,

        I'd be interested. A lot of innocent bits have been deforested
while trying work out the differences between what Linux is doing (which
is basically following Draft 17), and what Trusted Irix is doing (which
apparently is following Draft 16).

        On of the problems is that the draft doesn't state how the bits
would typically get used. For example, what would the PIE permissions
be on a typical system after login is run? What should the file capsets
be on executables if certain privileges should be forced, or if certain
privileges should be should allowed to be inherited?

        Many of Linda's long diatribes about how Draft 17 is "broken"
seems to be based on assumptions of how Trusted Irix sets up its initial
conditions after login and the PIE settings on trusted executables. Yet
if you change the initial conditions used after login and after PIE
settings, Draft 17 is quite reasonable. In fact, it seems to provide
better defaults for the inheritance of newly raised privileges (it
doesn't allow them to be inherited unless the process explicitly allows
them to be inherited).

        Yet both Linda's assumptions of what the appropriate
configuration should be and what my assumptions of what the appropriate
configuration should be are not documented in the POSIX specifications
at all! There is no question that Linda is right that if you use the
configuration parameters that you might use for Draft 16, the results
are disastrous if applied to a Draft 17 system. But the configuration
parameters which Linda is assuming are documented nowhere in any of the
specifications. (Of course, neither are mine --- but they make D17
work, so I think they should be considered. :-)

        In many ways, this reminds me of cryptographic algorithms, where
a few changes in the boolean algorithms (change an AND to an OR here,
move a few parameters around or a few changes in the initial vectors)
result in a massive change in the semantics and security of the overall

        If we have such a meeting, I would propose the following two
agenda items:

      * Should Linux continue to follow the specification found in Posix.1e
        Draft 17, the last version of the specification? Or should it
        use some other system, such as Draft 16, which apparently
        Trusted Irix is using?

        Key questions to help us answer this question are:

        (1) What are the security properties of D16 vs. D17?
        (2) What are the other Trusted Unices implementing? Even if D17
        is better, if the rest of the world have implemented D16, being
        the same is sometimes better than being different.
        (3) Is it possible for the Linux development community to get a
        copy of Draft 16. If we're going to implement to a
        specification, we might as well implement the whole thing. I'm
        very suspicious of implementing a frankensteinish mix between
        D16 and D17, since as we've seen, differences in assumptions can
        have vast security impliciations. Also, implementing from a
        single vendor's man pages seems like a bad idea.

      * What are the appropriate settings of PIE masks of executables
        and processes? This needs to be documented, with a rationale
        about why things are the way they are.

Also, if people are interested in having on the east coast, I can
probably arrange to host a meeting at a Boston area hotel. (Anything to
get out of Yet Another Cross Country plane trip. :-)

                                                - Ted

P.S. I'm going to be in Sunnyvale June 9-18th and will have some free
time on June 15th and 16th, or on the weekends of the 10th and 17th. So
there's any interest in having an informal discusion, preferably in a
room with plenty of whiteboard space and a good selection of microbrews,
I'll be available and interested.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:27 EST