Casey Schaufler writes:
> --- "Serge E. Hallyn" <[email protected]> wrote:
>> + bprm->cap_effective = fscaps[0];
>> + bprm->cap_inheritable = fscaps[1];
>> + bprm->cap_permitted = fscaps[2];
>
> It does not appear that you're attempting
> to maintain the POSIX exec semantics for
> capability sets. (If you're doing it
> elsewhere in the code, nevermind) I don't
> know if this is intentional or not.
Stop right there. No such POSIX semantics exist.
There is no POSIX standard for this. Out in the
wild there are numerous dangerously incompatible
ideas about this concept:
a. SGI IRIX, and one draft of a failed POSIX proposal
b. Linux (half done), and a very different draft
c. DG-UX, which actually had a workable system
d. Solaris, which is workable and getting used
My rant from 4 years ago mostly applies today.
http://lkml.org/lkml/2003/10/22/135
(yes, we have a lame SGI-style set of bits with
a set of equations that is not compatible)
Something has changed though: people are actually
using this type of thing on Solaris. Probably the
sanest thing to do is to copy Solaris: equations,
tools, set of bits, #define names, API, etc. Just
let Sun be the standard, and semi-portable apps
will be able to use the feature. Cross-platform
admins will be very grateful for the consistency.
Quoting Albert Cahalan ([email protected]):
> Casey Schaufler writes:
> >--- "Serge E. Hallyn" <[email protected]> wrote:
>
> >>+ bprm->cap_effective = fscaps[0];
> >>+ bprm->cap_inheritable = fscaps[1];
> >>+ bprm->cap_permitted = fscaps[2];
> >
> >It does not appear that you're attempting
> >to maintain the POSIX exec semantics for
> >capability sets. (If you're doing it
> >elsewhere in the code, nevermind) I don't
> >know if this is intentional or not.
>
> Stop right there. No such POSIX semantics exist.
> There is no POSIX standard for this. Out in the
> wild there are numerous dangerously incompatible
> ideas about this concept:
>
> a. SGI IRIX, and one draft of a failed POSIX proposal
> b. Linux (half done), and a very different draft
> c. DG-UX, which actually had a workable system
> d. Solaris, which is workable and getting used
>
> My rant from 4 years ago mostly applies today.
> http://lkml.org/lkml/2003/10/22/135
>
> (yes, we have a lame SGI-style set of bits with
> a set of equations that is not compatible)
>
> Something has changed though: people are actually
> using this type of thing on Solaris. Probably the
> sanest thing to do is to copy Solaris: equations,
> tools, set of bits, #define names, API, etc. Just
> let Sun be the standard, and semi-portable apps
> will be able to use the feature. Cross-platform
> admins will be very grateful for the consistency.
Does anyone have a security/solaris_prm.ko module they've
been quietly working on or using?
(given the number of fscaps patches out there, it seems a
reasonable question)
thanks,
-serge
--- Albert Cahalan <[email protected]> wrote:
> Casey Schaufler writes:
> > --- "Serge E. Hallyn" <[email protected]> wrote:
>
> >> + bprm->cap_effective = fscaps[0];
> >> + bprm->cap_inheritable = fscaps[1];
> >> + bprm->cap_permitted = fscaps[2];
> >
> > It does not appear that you're attempting
> > to maintain the POSIX exec semantics for
> > capability sets. (If you're doing it
> > elsewhere in the code, nevermind) I don't
> > know if this is intentional or not.
>
> Stop right there. No such POSIX semantics exist.
> There is no POSIX standard for this.
Strictly speaking you are of course correct.
Please accept my appologies and pass them along
to the IEEE.
> Out in the
> wild there are numerous dangerously incompatible
> ideas about this concept:
>
> a. SGI IRIX, and one draft of a failed POSIX
> proposal
There were 17 drafts. I believe the one you
refer to is the last, which was withdrawn
due to lack of participation.
> b. Linux (half done), and a very different draft
A very similar draft. The differences are not
so significant as to matter much.
> c. DG-UX, which actually had a workable system
Opinions vary!
> d. Solaris, which is workable and getting used
Ok.
> Something has changed though: people are actually
> using this type of thing on Solaris. Probably the
> sanest thing to do is to copy Solaris: equations,
> tools, set of bits, #define names, API, etc. Just
> let Sun be the standard, and semi-portable apps
> will be able to use the feature. Cross-platform
> admins will be very grateful for the consistency.
There are worse notions floating about.
I personally prefer the scheme used in
Irix (big surprise there) but I certainly
wouldn't obstruct a concerted effort to
go the Solaris route.
Casey Schaufler
[email protected]