Darrel Goeddel wrote: > Stephen Smalley wrote: > >> On Mon, 2006-10-02 at 15:06 -0400, Linda Knippers wrote: >> >>> Stephen Smalley wrote: >>> >>>> For the translation daemon itself, you might want a libselinux function >>>> that lets you disable all translations (i.e. set a flag that is checked >>>> on entry by selinux_trans_to_raw_context() and >>>> selinux_raw_to_trans_context() and handled in the same manner as the ! >>>> mls_enabled case). Then the translation daemon could just call any >>>> libselinux function without needing to worry about accidentally >>>> triggering a communication to itself. >>> >>> >>> I threw together a couple of patches. Is this what you had in mind? >> >> Essentially, yes. I'd call it selinux_set_translation() instead, since >> it can be used to subsequently re-enable them as well. The libselinux >> patch needs to go to selinux list. > > Agreed.
Yes, much better name. >> On the mcstransd patch, it would be more flexible if we introduced a >> separate class and permission for translations so that one could e.g. >> configure translation-related policy differently than the file access >> policy, although that naturally requires a patch to define the >> class/perm for refpolicy and a patch for libselinux for the regenerated >> headers. > > > Also agreed... We can't really assume that we are translating a file context. > Something that would be translating process domains would then need policy > to allow file:getattr for domain types, and that would look weird. Anyway, > are you thinking about something like: > > - create a class "context" with permission "translate" > - put in an mlsconstraint that says "h1 dom h2" for the above permission > > Now what for the TE... I don't see an easy way to allow a domain to > translate all contexts very easily. We can't say "allow foo_t *:context > translate". What I'd really like is no TE involvement whatsoever (sorry bout > that), along the lines of "allow * *:context translate;". Is there a nice > set of attributes that should cover all types (cc'd Chris in case he has a > quick answer)? I agree it would be more flexible. Darrel, after our call yesterday, is this something you can take a look at? In the meantime, I can fix/post the libselinux patch. --ljk -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
