xpra printer forwarding currently requires a change to the core policy

[Antoine Martin]

xpra printer forwarding works by adding a PDF or PS virtual printer via a cups backend.
This cups backend then connects to the local xpra server via a unix domain socket and the server then forwards the PDF or PS file to the xpra client for printing.

The problem is connecting to the xpra server socket, which is currently forbidden by the core policy.

Here's what we have to add to make it work at the moment with the server socket in "~/.xpra/":
    userdom_manage_user_home_content_files(cupsd_t)
    userdom_manage_user_home_content_symlinks(cupsd_t)
    userdom_manage_user_home_content_pipes(cupsd_t)
    userdom_manage_user_home_content_sockets(cupsd_t)

Alternatively, if that helps, we can also place the server socket in /run/user/$UID/xpra, but then we still get:
    type=AVC msg=audit(1470902846.451:911): avc:  denied  { write } for  pid=9644 comm="xpra" name="desktop-100" dev="tmpfs" ino=74293 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=1
    type=AVC msg=audit(1470902846.451:912): avc:  denied  { connectto } for  pid=9644 comm="xpra" path="/run/user/1000/xpra/desktop-100" scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=1

What is the preferred way forward to allow users to have both selinux in enforcing mode and printing to work with xpra by default?

[Miroslav Grepl]

On 08/11/2016 10:18 AM, [e-mail] wrote:
> xpra printer forwarding works by adding a PDF or PS virtual printer via a cups backend.
> This cups backend then connects to the local xpra server via a unix domain socket and the server then forwards the PDF or PS file to the xpra client for printing.
>
> The problem is connecting to the xpra server socket, which is currently forbidden by the core policy.
>
> Here's what we have to add to make it work at the moment with the server socket in "~/.xpra/":
>     userdom_manage_user_home_content_files(cupsd_t)
>     userdom_manage_user_home_content_symlinks(cupsd_t)
>     userdom_manage_user_home_content_pipes(cupsd_t)
>     userdom_manage_user_home_content_sockets(cupsd_t)
>
> Alternatively, if that helps, we can also place the server socket in /run/user/$UID/xpra, but then we still get:
>     type=AVC msg=audit(1470902846.451:911): avc:  denied  { write } for  pid=9644 comm="xpra" name="desktop-100" dev="tmpfs" ino=74293 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=1
>     type=AVC msg=audit(1470902846.451:912): avc:  denied  { connectto } for  pid=9644 comm="xpra" path="/run/user/1000/xpra/desktop-100" scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=1
> What is the preferred way forward to allow users to have both selinux in enforcing mode and printing to work with xpra by default?
>
> selinux mailing list
> [e-mail]
> https://lists.fedoraproject.org/admin/lists/[e-mail]

We could try to label xpra by a label to get it running in a different
CUPS domain.

What is a path to xpra?

What does

chcon -t cups_pdf_exec_t PATHTO/xpra

[Antoine Martin]

On 11/08/16 22:10, Miroslav Grepl wrote:
> On 08/11/2016 10:18 AM, [e-mail] wrote:
> > xpra printer forwarding works by adding a PDF or PS virtual printer via a cups backend.
> > This cups backend then connects to the local xpra server via a unix domain socket and the server then forwards the PDF or PS file to the xpra client for printing.
> >
> > The problem is connecting to the xpra server socket, which is currently forbidden by the core policy.
> >
> > Here's what we have to add to make it work at the moment with the server socket in "~/.xpra/":
> >     userdom_manage_user_home_content_files(cupsd_t)
> >     userdom_manage_user_home_content_symlinks(cupsd_t)
> >     userdom_manage_user_home_content_pipes(cupsd_t)
> >     userdom_manage_user_home_content_sockets(cupsd_t)
> >
> > Alternatively, if that helps, we can also place the server socket in /run/user/$UID/xpra, but then we still get:
> >     type=AVC msg=audit(1470902846.451:911): avc:  denied  { write } for  pid=9644 comm="xpra" name="desktop-100" dev="tmpfs" ino=74293 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=1
> >     type=AVC msg=audit(1470902846.451:912): avc:  denied  { connectto } for  pid=9644 comm="xpra" path="/run/user/1000/xpra/desktop-100" scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=1
> > What is the preferred way forward to allow users to have both selinux in enforcing mode and printing to work with xpra by default?
> >
> > selinux mailing list
> > [e-mail]
> > https://lists.fedoraproject.org/admin/lists/[e-mail]
>
> We could try to label xpra by a label to get it running in a different
> CUPS domain.
>
> What is a path to xpra?

The main script is:
$ ls -aZl /usr/bin/xpra
-rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 186 Aug  9 23:44
/usr/bin/xpra
The cups backend is:
$ ls -aZl /usr/lib/cups/backend/xpraforwarder
-rwx------. 1 root root system_u:object_r:bin_t:s0 5146 Aug 11 14:57
/usr/lib/cups/backend/xpraforwarder
> What does
>
> chcon -t cups_pdf_exec_t PATHTO/xpra

Xpra does a lot more than just printer forwarding, it acts as a
compositing window manager, talks to X11, etc.. Printer forwarding is
only a secondary feature, so unless I misunderstand what this change is
meant to do, I don't think we want to go down that route?

Eventually I would like to have a policy for the whole of xpra:
http://xpra.org/trac/ticket/815
But for now, getting printing to work without having to tell users to
"disable SELinux" would be a good start.

So maybe do something similar to cups_pdf_exec_t for xpraforwarder, with
the extra privileges needed for accessing the socket?

Thanks
Antoine

[Miroslav Grepl]

On 08/11/2016 06:05 PM, Antoine Martin wrote:
> On 11/08/16 22:10, Miroslav Grepl wrote:
> > On 08/11/2016 10:18 AM, [e-mail] wrote:
> > > xpra printer forwarding works by adding a PDF or PS virtual printer via a cups backend.
> > > This cups backend then connects to the local xpra server via a unix domain socket and the server then forwards the PDF or PS file to the xpra client for printing.
> > >
> > > The problem is connecting to the xpra server socket, which is currently forbidden by the core policy.
> > >
> > > Here's what we have to add to make it work at the moment with the server socket in "~/.xpra/":
> > >     userdom_manage_user_home_content_files(cupsd_t)
> > >     userdom_manage_user_home_content_symlinks(cupsd_t)
> > >     userdom_manage_user_home_content_pipes(cupsd_t)
> > >     userdom_manage_user_home_content_sockets(cupsd_t)
> > >
> > > Alternatively, if that helps, we can also place the server socket in /run/user/$UID/xpra, but then we still get:
> > >     type=AVC msg=audit(1470902846.451:911): avc:  denied  { write } for  pid=9644 comm="xpra" name="desktop-100" dev="tmpfs" ino=74293 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=1
> > >     type=AVC msg=audit(1470902846.451:912): avc:  denied  { connectto } for  pid=9644 comm="xpra" path="/run/user/1000/xpra/desktop-100" scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=1
> > > What is the preferred way forward to allow users to have both selinux in enforcing mode and printing to work with xpra by default?
> > >
> > > selinux mailing list
> > > [e-mail]
> > > https://lists.fedoraproject.org/admin/lists/[e-mail]
> >
> > We could try to label xpra by a label to get it running in a different
> > CUPS domain.
> >
> > What is a path to xpra?
>
> The main script is:
> $ ls -aZl /usr/bin/xpra
> -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 186 Aug  9 23:44
> /usr/bin/xpra
> The cups backend is:
> $ ls -aZl /usr/lib/cups/backend/xpraforwarder
> -rwx------. 1 root root system_u:object_r:bin_t:s0 5146 Aug 11 14:57
> /usr/lib/cups/backend/xpraforwarder
> > What does
> >
> > chcon -t cups_pdf_exec_t PATHTO/xpra
>
> Xpra does a lot more than just printer forwarding, it acts as a
> compositing window manager, talks to X11, etc.. Printer forwarding is
> only a secondary feature, so unless I misunderstand what this change is
> meant to do, I don't think we want to go down that route?
>
> Eventually I would like to have a policy for the whole of xpra:
> http://xpra.org/trac/ticket/815
> But for now, getting printing to work without having to tell users to
> "disable SELinux" would be a good start.
>
> 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?

Thank you.
> Thanks
> Antoine
> --
> selinux mailing list
> [e-mail]
> https://lists.fedoraproject.org/admin/lists/[e-mail]

[Antoine Martin]

> > > 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
> > [e-mail]
> > https://lists.fedoraproject.org/admin/lists/[e-mail]

[mark]

Antoine Martin wrote:
> > > > 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

<snip>
PLEASE be aware that's not permanent. To make it go through reboots, you
need to do:
semanage fcontext -a -t cups_pdf_exec_t /usr/lib/cups/backend/xpraforwarder

AND THEN follow that with
restorecon -v /usr/lib/cups/backend/

mark

[Miroslav Grepl]

On 08/12/2016 02:27 PM, Antoine Martin wrote:
> > > > 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?

You can use

"policy_module(cups_xpra, 1.0)"

which means you generate module policy using reference policy and you
don't need to require all these classes with permissions. Together that
look for *.if to avoid the "require" section if possible.

So for example

----

policy_module(cups_xpra, 1.0)

type cups_xpra_t;
type cups_xpra_exec_t;
cups_backend(cups_xpra_t, cups_xpra_exec_t)

#
# interfaces are placed in /usr/share/selinux/devel/
#
unconfined_stream_connect(cups_xpra_t)

---

and

# make -f /usr/share/selinux/devel/Makefile cups_xpra.pp
# semodule -i cups_xpra.pp

Also https://github.com/TresysTechnology/refpolicy/wiki could be helpful.
> Thanks
> Antoine
> > Thank you.
> > > Thanks
> > > Antoine
> > > --
> > > selinux mailing list
> > > [e-mail]
> > > https://lists.fedoraproject.org/admin/lists/[e-mail]
>
> --
> selinux mailing list
> [e-mail]
> https://lists.fedoraproject.org/admin/lists/[e-mail]