Here is what I've been playing with so far to get some of our X
applications to run without any X related avcs. This is not meant to
be a real solution just one to get an idea of the scope of the problem
and to hopefully get other thinking about it. The newrole_t stuff is
because I'm using newrole to run these apps at level.
# X
gen_require(`type xdm_xserver_t, user_t;');
mls_socket_read_all_levels(xdm_xserver_t)
mls_socket_write_all_levels(xdm_xserver_t)
allow xdm_xserver_t security_t:file { read write };
allow xdm_xserver_t security_t:security { compute_create compute_av };
allow xdm_xserver_t user_t:dir { search };
allow xdm_xserver_t user_t:file { read };
allow xdm_xserver_t self:netlink_selinux_socket { read };
mls_file_read_all_levels(xdm_xserver_t)
mls_file_write_within_range(xdm_xserver_t)
gen_require(`type xdm_tmp_t;');
mls_trusted_object(xdm_tmp_t)
allow user_t xdm_tmp_t:lnk_file { read };
gen_require(`type newrole_t;');
allow newrole_t xdm_tmp_t:sock_file { getattr write };
allow newrole_t xdm_tmp_t:file { read getattr };
On Dec 17, 2007 2:45 PM, Christopher J. PeBenito <cpebenito@xxxxxxxxxx> wrote:
>
> On Mon, 2007-12-17 at 15:32 -0500, Stephen Smalley wrote:
> > On Mon, 2007-12-17 at 15:18 -0500, Christopher J. PeBenito wrote:
> > > On Mon, 2007-12-17 at 14:59 -0500, Eamon Walsh wrote:
> > > > -------- Original Message --------
> > > > Subject: f8 X policy
> > > > Date: Mon, 17 Dec 2007 13:37:54 -0600
> > > > From: Xavier Toth <txtoth@xxxxxxxxx>
> > > > To: Eamon Walsh <ewalsh@xxxxxxxxxxxxx>
> > > >
> > > >
> > > >
> > > > I'm starting to look more closely at X related avcs and have some
> > > > questions related to file contexts. Looking at the xserver.fc I see
> > > > that there are defaults for tmp files and directories with level s0.
> > > > So when clients at level try to write X0 avcs like:
> > > >
> > > > type=AVC msg=audit(1197913061.254:3125): avc: denied { write } for
> > > > pid=15405 comm="QBrowser" name="X0" dev=dm-0 ino=25853956
> > > > scontext=user_u:user_r:user_t:s2:c0.c254
> > > > tcontext=system_u:object_r:xdm_tmp_t:s0 tclass=sock_file
> > > >
> > > > occur. I'm thinking this is an mls constraint violation and I'm trying
> > > > to figure out how to deal with it. What do you think?
> > >
> > > It is indeed a MLS denial, so the options would be:
> > >
> > > 1. make xdm_tmp_t ranged
> > > 2. make xdm_tmp_t a trusted object
> > >
> > > The more I look at it, the more they look like the same option.
> > > Opinions?
> >
> > Can we get a discrete type applied to that socket file that is not used
> > for any other file? So that we are only making that socket a MLS
> > trusted object and no other /tmp file created by X?
>
> Yes, I that is another option. Only seems useful in the MLS policy
> though. We could add a xdm_socket_t that is an alias of xdm_tmp_t in
> the standard (TE-only) or mcs configs. Or is there a reason to keep it
> separate in all cases?
>
> --
> Chris PeBenito
> Tresys Technology, LLC
> (410) 290-1411 x150
>
>
--
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.
