Re: Fedora Core 7 has frozen and Fedora 8 Development has started

On Tue, 2007-05-22 at 11:14 -0400, Joshua Brindle wrote:
> Todd Miller wrote:
> > Joshua Brindle wrote:
> >
> >> How would the client get that kind of information? apol is the only
> >> app I know if that does any kind of relabel analysis to see what who
> >> can relabel what-to-what and that would be a pretty high level
> >> dependency for nautilus (and it also uses the policy on disk instead
> >> of the one loaded into the kernel). Also the list would be completely
> >> unusable when run from unconfined_t, which is the normal use case.
> >>
> >
> > There was a proof of concept file label utility in SEDarwin that used a
> > sysctl to get the list of allowable file contexts for a user. Like you
> > say, it was basically useless from unconfined_t (it was initially
> > written for the old example policy).
> >
>
> What does allowable file context mean?
>

This doesn't have to be an exhaustive list of contexts - but a list of the most likely contexts that the user might want would be helpful.

> You need to be able to do an analysis on the policy to see what user can
> relabelfrom and what they can relabelto. If they can't relabelfrom the
> file being modified in nautilus then nothing should appear, otherwise
> the types they can relabelto would appear.
>

1. The analysis isn't that complicated - no reason it can't be done in libsepol if it is useful.
2. It could be data driven from the policy - types could be marked in refpolicy as likely candidates for relabeling by different domains.

The larger point, I think, is that users often directly interact with types / contexts, particularly when dealing with the filesystem. These types should be documented (just like interfaces) and users should be given help determining appropriate types / contexts when labeling is needed (and users can mean unprivileged users or admins).

Basically - the refpolicy notion that types are private resources of modules is broken. There is no encapsulation - so we need docs, etc.

Karl

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.