>>> We could try to label xpra by a label to get it running in a different
>>> CUPS domain.
>>>
(snip)
>>
>> So maybe do something similar to cups_pdf_exec_t for xpraforwarder, with
>> the extra privileges needed for accessing the socket?
>
> Yes, I was looking for the backend. Could you try to label the backend
> by cups_pdf_exec_t to see how it works?
That didn't work, but this does:
chcon -t cups_pdf_exec_t /usr/lib/cups/backend/xpraforwarder
And then load this module on top:
module xpraforwarder 1.0;
require {
type user_tmp_t;
type cups_pdf_t;
type unconfined_t;
class unix_dgram_socket create;
class unix_dgram_socket connect;
class sock_file write;
class unix_stream_socket connectto;
}
allow cups_pdf_t self:unix_dgram_socket { create connect };
allow cups_pdf_t user_tmp_t:sock_file write;
allow cups_pdf_t unconfined_t:unix_stream_socket connectto;
Full details here:
http://xpra.org/trac/ticket/815#comment:7
I then tried to extract the bits from the cups / cups_pdf policy to try
to come with something more self-contained for xpra and although I did
come up with something that works OK and does not depend on cups_pdf_t,
the resulting policy is a lot bigger than I would like (but it works!):
http://xpra.org/trac/changeset/13317
Any feedback would be most appreciated, I'm sure there are glaring
mistakes in there.
I often find myself wondering how I can reduce those long winded
statements to more helpful macros - that is, without spending hours
figuring it all out. How can I get it done more efficiently?
Thanks
Antoine
>
> Thank you.
>
>>
>> Thanks
>> Antoine
>> --
>> selinux mailing list
>> selinux@xxxxxxxxxxxxxxxxxxxxxxx
>> https://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx
>>
>
>
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx
