Date: Tue, 30 May 2000 17:15:56 -0700
From: Casey Schaufler <casey@sgi.com>
> 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
system.
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:27 EST