From: Ted X Toth <txtoth@gmail.com>
To: SE Linux <selinux@tycho.nsa.gov>
Subject: [Fwd: Re: [Fwd: f8 X policy]]
Date: Mon, 17 Dec 2007 16:08:04 -0600 [thread overview]
Message-ID: <4766F344.6040404@gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 42 bytes --]
Sorry I should have put this on the list.
[-- Attachment #2: Re: [Fwd: f8 X policy].eml --]
[-- Type: message/rfc822, Size: 3583 bytes --]
From: "Christopher J. PeBenito" <cpebenito@tresys.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Eamon Walsh <ewalsh@tycho.nsa.gov>, Ted X Toth <txtoth@gmail.com>
Subject: Re: [Fwd: f8 X policy]
Date: Mon, 17 Dec 2007 15:45:09 -0500
Message-ID: <1197924309.12626.270.camel@gorn>
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@gmail.com>
> > > To: Eamon Walsh <ewalsh@tycho.nsa.gov>
> > >
> > >
> > >
> > > 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
reply other threads:[~2007-12-17 22:10 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4766F344.6040404@gmail.com \
--to=txtoth@gmail.com \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.