Access to xdm_t

Access to xdm_t

[Thomas Bleher]

I have a question about access to xdm_t:
With KDM 3.3 I am seeing a lot of accesses to xdm_t:fd and
xdm_t:fifo_file from user processes (say user_lpr_t and user_gpg_t)
Should these be allowed?
If yes, should xdm_t get the attribute privfd?

Also, is it OK to dontaudit access to .xsession-errors (on SuSE it lives
under ~ and I do not want to give all derived user domains access to user's
home dir). Or will this cause errors with some programs?

Thanks for your answers,
Thomas

-- 
http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages
GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA  D09E C562 2BAE B2F4 ABE7

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Access to xdm_t

[Russell Coker]

On Thu, 30 Sep 2004 02:32, Thomas Bleher <bleher@informatik.uni-muenchen.de> 
wrote:
> I have a question about access to xdm_t:
> With KDM 3.3 I am seeing a lot of accesses to xdm_t:fd and
> xdm_t:fifo_file from user processes (say user_lpr_t and user_gpg_t)
> Should these be allowed?
> If yes, should xdm_t get the attribute privfd?

I don't think that is necessary.  gpg and lpr are both text based programs and 
have no need of direct communication with xdm_t.  I think that the wide 
inheritance of that file handle is a bug.

> Also, is it OK to dontaudit access to .xsession-errors (on SuSE it lives
> under ~ and I do not want to give all derived user domains access to user's
> home dir). Or will this cause errors with some programs?

That should be fine.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Access to xdm_t

[Luke Kenneth Casson Leighton]

On Thu, Sep 30, 2004 at 03:50:06AM +1000, Russell Coker wrote:

> > Also, is it OK to dontaudit access to .xsession-errors (on SuSE it lives
> > under ~ and I do not want to give all derived user domains access to user's
> > home dir). Or will this cause errors with some programs?
> 
> That should be fine.
 
 thomas, when you've done that could you kindly send an appropriate
 patch in, and could it please be considered for inclusion in the
 strict policy, because i'm fed up of hacking in the audit messages
 to get rid of xsession-errors access all the time!

 ... that having been said, what happens when you _need_ to know what
 errors a program (kvm - a program in development) is generating?

 l.

-- 
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love.  If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Access to xdm_t

[Colin Walters]

On Wed, 2004-09-29 at 18:32 +0200, Thomas Bleher wrote:
> I have a question about access to xdm_t:
> With KDM 3.3 I am seeing a lot of accesses to xdm_t:fd and
> xdm_t:fifo_file from user processes (say user_lpr_t and user_gpg_t)

For Fedora we modified GDM to log the X session errors to 
/tmp/xses-$USER.$RANDOM, you could probably do something similar with
KDM.

> Should these be allowed?
> If yes, should xdm_t get the attribute privfd?

I think it'd be better to move the X errors to /tmp.  It's more 
NFS-homedir friendly anyways.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Access to xdm_t

[Thomas Bleher]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

* Colin Walters <walters@verbum.org> [2004-09-30 09:53]:
> On Wed, 2004-09-29 at 18:32 +0200, Thomas Bleher wrote:
> > I have a question about access to xdm_t:
> > With KDM 3.3 I am seeing a lot of accesses to xdm_t:fd and
> > xdm_t:fifo_file from user processes (say user_lpr_t and user_gpg_t)
> 
> For Fedora we modified GDM to log the X session errors to 
> /tmp/xses-$USER.$RANDOM, you could probably do something similar with
> KDM.

This seems like the right thing to do; however, this is not possible
with current kdm, at least not without patching.
Just bugzillad: http://bugs.kde.org/show_bug.cgi?id=90552

Thomas

-- 
http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages
GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA  D09E C562 2BAE B2F4 ABE7

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Access to xdm_t

[Colin Walters]

On Wed, 2004-09-29 at 18:32 +0200, Thomas Bleher wrote:

> If yes, should xdm_t get the attribute privfd?

Actually even moving the log to /tmp you'll still get programs wanting
access to the xdm_t fd.  Ideally we would have a little program run in
its own domain (xdm_launcher_t say) that would simply close all of its
file descriptors, open up the tmp file itself for logging and exec the
user session.  Then you could make the xdm_launcher_t privfd, without
giving users access to any random fd that xdm forgot to close or that
one of PAM libraries xdm is using forgot to close...



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Access to xdm_t

[Luke Kenneth Casson Leighton]

On Thu, Sep 30, 2004 at 12:32:07PM -0400, Colin Walters wrote:
> On Wed, 2004-09-29 at 18:32 +0200, Thomas Bleher wrote:
> 
> > If yes, should xdm_t get the attribute privfd?
> 
> Actually even moving the log to /tmp you'll still get programs wanting
> access to the xdm_t fd.  Ideally we would have a little program run in
> its own domain (xdm_launcher_t say) that would simply close all of its
> file descriptors, open up the tmp file itself for logging and exec the
> user session.  

 /usr/bin/startkde for example?


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Access to xdm_t

[Russell Coker]

On Fri, 1 Oct 2004 02:32, Colin Walters <walters@verbum.org> wrote:
> On Wed, 2004-09-29 at 18:32 +0200, Thomas Bleher wrote:
> > If yes, should xdm_t get the attribute privfd?
>
> Actually even moving the log to /tmp you'll still get programs wanting
> access to the xdm_t fd.  Ideally we would have a little program run in
> its own domain (xdm_launcher_t say) that would simply close all of its
> file descriptors, open up the tmp file itself for logging and exec the
> user session.  Then you could make the xdm_launcher_t privfd, without

Why not just have the xdm program launch a script in the user context which 
opens the file and redirects output to it?  If the file handle is opened as 
user_t then it won't cause any problems for any program.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Access to xdm_t

[Russell Coker]

On Fri, 1 Oct 2004 05:29, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> On Thu, Sep 30, 2004 at 12:32:07PM -0400, Colin Walters wrote:
> > On Wed, 2004-09-29 at 18:32 +0200, Thomas Bleher wrote:
> > > If yes, should xdm_t get the attribute privfd?
> >
> > Actually even moving the log to /tmp you'll still get programs wanting
> > access to the xdm_t fd.  Ideally we would have a little program run in
> > its own domain (xdm_launcher_t say) that would simply close all of its
> > file descriptors, open up the tmp file itself for logging and exec the
> > user session.
>
>  /usr/bin/startkde for example?

Yes, that sounds good for it.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Access to xdm_t

[Colin Walters]

On Thu, 2004-09-30 at 20:29 +0100, Luke Kenneth Casson Leighton wrote:
> On Thu, Sep 30, 2004 at 12:32:07PM -0400, Colin Walters wrote:
> > On Wed, 2004-09-29 at 18:32 +0200, Thomas Bleher wrote:
> > 
> > > If yes, should xdm_t get the attribute privfd?
> > 
> > Actually even moving the log to /tmp you'll still get programs wanting
> > access to the xdm_t fd.  Ideally we would have a little program run in
> > its own domain (xdm_launcher_t say) that would simply close all of its
> > file descriptors, open up the tmp file itself for logging and exec the
> > user session.  
> 
>  /usr/bin/startkde for example?

I think the idea with doing it inside ?dm was to keep common
functionality inside the display manager; also it ensures you get an
error log even if your session script fails early on (and gdm will offer
to display the error log for example if your session lasts less than 10
seconds, which it can really only do if it knows the name of the error
log).

So putting it inside each session script is generally wrong I think.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Access to xdm_t

[Luke Kenneth Casson Leighton]

On Thu, Sep 30, 2004 at 08:47:28PM -0400, Colin Walters wrote:

> >  /usr/bin/startkde for example?
> 
> I think the idea with doing it inside ?dm was to keep common
> functionality inside the display manager; also it ensures you get an
> error log even if your session script fails early on (and gdm will offer
> to display the error log for example if your session lasts less than 10
> seconds, which it can really only do if it knows the name of the error
> log).

 if the log file goes into a common directory, that same functionality
 can be achieved.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Access to xdm_t

[Russell Coker]

On Fri, 1 Oct 2004 10:47, Colin Walters <walters@verbum.org> wrote:
> I think the idea with doing it inside ?dm was to keep common
> functionality inside the display manager; also it ensures you get an
> error log even if your session script fails early on (and gdm will offer
> to display the error log for example if your session lasts less than 10
> seconds, which it can really only do if it knows the name of the error
> log).
>
> So putting it inside each session script is generally wrong I think.

OK, we can have another script which just creates the error log file and 
launches the session script.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.