Eamon Walsh wrote:
Glenn Faden wrote:
Eamon Walsh wrote:
Xavier Toth wrote:
I'm curious as to why you chose the route of specifying which
properties are polyinstantiated instead of which are not bearing in
mind what Glenn said in a previous post?
The server will check the "property" lines first and if it doesn't
find a match it will check the "poly_property" lines. So, as long
as the wildcard entry in the x_contexts file is changed from
property to poly_property, the default will be to polyinstantiate.
However I wasn't planning on treating the root window any
differently from other windows, so this behavior would apply to all
windows.
I've never seen a requirement for polyinstantiation of properties on
per-client windows. I've seen requirements for relabeling properties,
however. For example, the trusted selection manager needs to create
properties that are readable by the client who requests a
ConvertSelection. We do this by calling a new X protocol extension.
SELinux protocol extension allows clients to create windows and
properties with different security contexts.
How do you plan to have trusted clients act on behalf of other
clients with different security contexts?
I haven't done the polyinstantiation for selections yet, but my
current plan is to implement a trusted clipboard manager that will
display the various clipboard contents and allow users to upgrade or
downgrade, which means that the clipboard manager will take ownership
of the selection at the target level and just pipe the data through.
This scheme shouldn't require tweaking properties on the fly. However
this would not be point-to-point but would make the selection
available to all applications at the target level.
This is extremely high on our list of 'must have's and it is critical
that this be targeted for RHEL6 is this your goal too?
Similarly, how can a trusted client read/write a polyinstantiated
property with a different security context?
By launching a helper process at the appropriate level.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
