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.