list of permissions created by allow2audit: what do i do now?

list of permissions created by allow2audit: what do i do now?

[Luke Kenneth Casson Leighton]

help, help, i discovered the existence of allow2audit, and _finally_
i now have a tool that i can use to understand avc messages in terms
of audit permissions: hooray!

would someone mind advising me which of these is reasonable/safe
to allow, or should i just bung them all in and see what happens?

i am running with debian/unstable which was built from debian/unstable
packages about a month ago.

from the list, below, i've removed me editing syslog as root without
doing newrole -r system_r :)

from this list, i just get the impression that something's broken,
but haven't the experience yet to tell what it is.

for example, with wdm installed, surely these two shouldn't be
missed, along with the other wdm_config ones?

	allow initrc_t xdm_rw_etc_t:dir { add_name remove_name write };
	allow initrc_t xdm_rw_etc_t:file { create ioctl rename unlink write };

i mean, i see in domains/programs/xdm.te that there _are_
allow initrc_t xdm_rw_etc_t permissions for create (create_file_perms)
and also a comment that init scripts want to check for update
windowmanagerlist so they get getattr and read allowed.

... so what's going on?? why am i getting these messages?

if i am using wdm (the patched version) is there anything i need to
do to get it to work / be accepted?

i'll try removing wdm and installing xdm instead, see what difference
it makes.


allow cupsd_t usbfs_t:dir { search };
allow cupsd_t usbfs_t:file { getattr read };
allow dmesg_t etc_t:file { getattr read };
allow dpkg_t init_t:fd { use };
allow hotplug_t cupsd_t:file { read };
allow hotplug_t dbusd_t:file { read };
allow hotplug_t dbusd_var_run_t:dir { search };
allow hotplug_t dbusd_var_run_t:sock_file { write };
allow hotplug_t etc_runtime_t:file { relabelfrom relabelto };
allow hotplug_t inetd_t:file { read };
allow hotplug_t insmod_t:file { read };
allow hotplug_t klogd_t:file { read };
allow hotplug_t lib_t:file { execute execute_no_trans };
allow hotplug_t portmap_t:file { read };
allow hotplug_t romfs_t:chr_file { ioctl read write };
allow hotplug_t romfs_t:dir { search };
allow hotplug_t sshd_t:file { read };
allow hotplug_t syslogd_t:file { read };
allow initrc_t dbusd_var_run_t:sock_file { write };
allow initrc_t device_t:fifo_file { setattr };
allow initrc_t initrc_t:tcp_socket { ioctl };
allow initrc_t usbfs_t:file { getattr read };
allow initrc_t usr_t:file { execute execute_no_trans };
allow initrc_t xdm_rw_etc_t:dir { add_name remove_name write };
allow initrc_t xdm_rw_etc_t:file { create ioctl rename unlink write };
allow insmod_t romfs_t:chr_file { getattr read write };
allow sshd_t sshd_t:file { getattr };
allow sshd_t staff_home_t:dir { search };
allow staff_chkpwd_t sshd_devpts_t:chr_file { read write };
allow staff_chkpwd_t staff_chkpwd_t:file { getattr };
allow staff_su_t sshd_devpts_t:chr_file { ioctl };
allow staff_su_t sysadm_home_dir_t:dir { search };
allow staff_t sshd_devpts_t:chr_file { ioctl read setattr write };
allow staff_t staff_t:capability { dac_override };
allow staff_t sysadm_home_dir_t:dir { add_name read remove_name write };
allow staff_t sysadm_home_dir_t:file { create getattr read rename setattr unlink write };
allow staff_t var_log_t:dir { add_name getattr read remove_name search write };
allow staff_t var_log_t:file { create getattr read unlink write };
allow syslogd_t device_t:fifo_file { ioctl read write };
allow syslogd_t innd_log_t:file { append ioctl };
allow system_chkpwd_t sshd_t:tcp_socket { read write };
allow system_chkpwd_t sshd_t:unix_stream_socket { read write };
allow system_chkpwd_t system_chkpwd_t:file { getattr };
allow xdm_t memory_device_t:chr_file { read };
allow xdm_xserver_t usr_t:file { getattr read };
allow xdm_xserver_t xdm_var_lib_t:file { write };
allow cupsd_t usbfs_t:dir { search };
	#EXE=/usr/lib/cups/backend/canon   :  search

allow cupsd_t usbfs_t:file { getattr read };
	#EXE=/usr/lib/cups/backend/canon  NAME=devices   :  read
	#EXE=/usr/lib/cups/backend/canon  PATH=/proc/bus/usb/devices   :  getattr

allow dpkg_t init_t:fd { use };
	#EXE=/usr/lib/dpkg/enoent  PATH=/dev/console   :  use

allow hotplug_t cupsd_t:file { read };
	#EXE=/bin/ps  NAME=stat   :  read

allow hotplug_t dbusd_t:file { read };
	#EXE=/bin/ps  NAME=stat   :  read

allow hotplug_t dbusd_var_run_t:dir { search };
	#EXE=/usr/lib/hal/hal.hotplug  NAME=dbus   :  search

allow hotplug_t dbusd_var_run_t:sock_file { write };
	#EXE=/usr/lib/hal/hal.hotplug  NAME=system_bus_socket   :  write

allow hotplug_t etc_runtime_t:file { relabelfrom relabelto };
	#EXE=/bin/cp  NAME=ifstate.hotplug   :  relabelfrom
	#EXE=/bin/cp  NAME=ifstate.hotplug   :  relabelto

allow hotplug_t inetd_t:file { read };
	#EXE=/bin/ps  NAME=stat   :  read

allow hotplug_t insmod_t:file { read };
	#EXE=/bin/ps  NAME=stat   :  read

allow hotplug_t klogd_t:file { read };
	#EXE=/bin/ps  NAME=stat   :  read

allow hotplug_t lib_t:file { execute execute_no_trans };
	#EXE=/bin/bash  NAME=hal.hotplug   :  execute
	#EXE=/bin/bash  PATH=/usr/lib/hal/hal.hotplug   :  execute_no_trans

allow hotplug_t portmap_t:file { read };
	#EXE=/bin/ps  NAME=stat   :  read

allow hotplug_t romfs_t:chr_file { ioctl read write };
	#EXE=/bin/bash  PATH=/initrd/dev/console   :  read write
	#EXE=/bin/bash  PATH=/initrd/dev/console   :  ioctl

allow hotplug_t romfs_t:dir { search };
	#EXE=/bin/bash   :  search

allow hotplug_t sshd_t:file { read };
	#EXE=/bin/ps  NAME=stat   :  read

allow hotplug_t syslogd_t:file { read };
	#EXE=/bin/ps  NAME=stat   :  read

allow initrc_t dbusd_var_run_t:sock_file { write };
	#EXE=/usr/sbin/hald  NAME=system_bus_socket   :  write

allow initrc_t initrc_t:tcp_socket { ioctl };
	#EXE=/usr/bin/perl  PATH=socket   :  ioctl

allow initrc_t usbfs_t:file { getattr read };
	#EXE=/usr/sbin/hald  NAME=devices   :  read
	#EXE=/usr/sbin/hald  PATH=/proc/bus/usb/devices   :  getattr

allow initrc_t usr_t:file { execute execute_no_trans };
	#EXE=/sbin/start-stop-daemon  NAME=miniserv.pl   :  execute
	#EXE=/sbin/start-stop-daemon  PATH=/usr/share/webmin/miniserv.pl   :  execute_no_trans

allow initrc_t xdm_rw_etc_t:dir { add_name remove_name write };
	#EXE=/usr/bin/perl  NAME=wdm   :  write
	#EXE=/usr/bin/perl  NAME=wdm-config.new   :  add_name
	#EXE=/usr/bin/perl  NAME=wdm-config.new   :  remove_name

allow initrc_t xdm_rw_etc_t:file { create ioctl rename unlink write };
	#EXE=/usr/bin/perl  PATH=/etc/X11/wdm/wdm-config   :  ioctl
	#EXE=/usr/bin/perl  NAME=wdm-config.new   :  create
	#EXE=/usr/bin/perl  PATH=/etc/X11/wdm/wdm-config.new   :  write
	#EXE=/usr/bin/perl  NAME=wdm-config.new   :  rename
	#EXE=/usr/bin/perl  NAME=wdm-config   :  unlink

allow insmod_t romfs_t:chr_file { getattr read write };
	#EXE=/sbin/modprobe  PATH=/initrd/dev/console   :  read write
	#EXE=/sbin/modprobe  PATH=/initrd/dev/console   :  getattr

allow sshd_t sshd_t:file { getattr };
	#EXE=/usr/sbin/sshd  PATH=/proc/1513/mounts   :  getattr

allow sshd_t staff_home_t:dir { search };
	#EXE=/usr/sbin/sshd  NAME=.ssh   :  search

allow system_chkpwd_t sshd_t:tcp_socket { read write };
	#EXE=/sbin/unix_verify  PATH=socket   :  read write

allow system_chkpwd_t sshd_t:unix_stream_socket { read write };
	#EXE=/sbin/unix_verify  PATH=socket   :  read write

allow system_chkpwd_t system_chkpwd_t:file { getattr };
	#EXE=/sbin/unix_verify  PATH=/proc/1516/mounts   :  getattr
	#EXE=/sbin/unix_verify  PATH=/proc/1540/mounts   :  getattr

allow xdm_t memory_device_t:chr_file { read };
	#EXE=/usr/X11R6/bin/wdm  NAME=mem   :  read

allow xdm_xserver_t usr_t:file { getattr read };
	#EXE=/usr/X11R6/bin/XFree86  PATH=/usr/local/share/fonts/fonts.dir   :  getattr
	#EXE=/usr/X11R6/bin/XFree86  NAME=fonts.dir   :  read

allow xdm_xserver_t xdm_var_lib_t:file { write };
	#EXE=/usr/X11R6/bin/X  PATH=/var/lib/wdm/authdir/authfiles/A:0-rhABmk   :  write

-- 
-- 
expecting email to be received and understood is a bit like
picking up the telephone and immediately dialing without
checking for a dial-tone; speaking immediately without listening
for either an answer or ring-tone; hanging up immediately and
believing that you have actually started a conversation.
--
<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: list of permissions created by allow2audit: what do i do now?

[Stephen Smalley]

On Tue, 2004-05-18 at 06:40, Luke Kenneth Casson Leighton wrote:
> from the list, below, i've removed me editing syslog as root without
> doing newrole -r system_r :)

sysadm_r, not system_r.

> 	allow initrc_t xdm_rw_etc_t:dir { add_name remove_name write };
> 	allow initrc_t xdm_rw_etc_t:file { create ioctl rename unlink write };
> 
> i mean, i see in domains/programs/xdm.te that there _are_
> allow initrc_t xdm_rw_etc_t permissions for create (create_file_perms)
> and also a comment that init scripts want to check for update
> windowmanagerlist so they get getattr and read allowed.
> 
> ... so what's going on?? why am i getting these messages?

In the upstream policy, I see:
$ grep 'allow initrc_t xdm_rw_etc_t' policy.conf
allow initrc_t xdm_rw_etc_t:file { getattr read };

So initrc_t is presently only allowed to stat and read those files. 
Now, there are other rules for xdm_t:
$ grep 'allow xdm_t xdm_rw_etc_t' policy.conf
allow xdm_t xdm_rw_etc_t:dir { read getattr lock search ioctl add_name remove_name write };
allow xdm_t xdm_rw_etc_t:file { create ioctl read getattr lock write setattr append link unlink rename };

And the xdm.te source file does have a comment prior to the
corresponding source statements that says that this is for wdm.
But perhaps someone erred and submitted the wrong rules for wdm (we
don't use it ourselves).

> if i am using wdm (the patched version) is there anything i need to
> do to get it to work / be accepted?

Don't know, as I've never used it.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: list of permissions created by allow2audit: what do i do now?

[Luke Kenneth Casson Leighton]

On Tue, May 18, 2004 at 10:40:28AM +0000, Luke Kenneth Casson Leighton wrote:

> help, help, i discovered the existence of allow2audit, and _finally_
> i now have a tool that i can use to understand avc messages in terms
> of audit permissions: hooray!
> 
> would someone mind advising me which of these is reasonable/safe
> to allow, or should i just bung them all in and see what happens?

well i tried the bung-it-in-and-see approach, and i got a build error
due to some global policy violations at make policy time because
of this (and one other):

> allow hotplug_t etc_runtime_t:file { relabelfrom relabelto };

... but what is even stranger is that even though i add in these
things into a new package (i called it domains/programs/localstuff.te)
the avc messages _still don't go away_.

i watched the make policy, it read the newly created file
(localstuff.te) and the stuff is in policy.conf.

what am i doing wrong?

l.


--
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: list of permissions created by allow2audit: what do i do now?

[Luke Kenneth Casson Leighton]

On Tue, May 18, 2004 at 08:40:47AM -0400, Stephen Smalley wrote:
> On Tue, 2004-05-18 at 06:40, Luke Kenneth Casson Leighton wrote:
> > from the list, below, i've removed me editing syslog as root without
> > doing newrole -r system_r :)
> 
> sysadm_r, not system_r.
 
 hey, given that i haven't allowed my useraccount to do newrole
 to _either_ of those...

> > 	allow initrc_t xdm_rw_etc_t:dir { add_name remove_name write };
> > 	allow initrc_t xdm_rw_etc_t:file { create ioctl rename unlink write };
> > 
> > i mean, i see in domains/programs/xdm.te that there _are_
> > allow initrc_t xdm_rw_etc_t permissions for create (create_file_perms)
> > and also a comment that init scripts want to check for update
> > windowmanagerlist so they get getattr and read allowed.
> > 
> > ... so what's going on?? why am i getting these messages?
> 
> In the upstream policy, I see:
> $ grep 'allow initrc_t xdm_rw_etc_t' policy.conf
> allow initrc_t xdm_rw_etc_t:file { getattr read };
> 
> So initrc_t is presently only allowed to stat and read those files. 
> Now, there are other rules for xdm_t:
> $ grep 'allow xdm_t xdm_rw_etc_t' policy.conf
> allow xdm_t xdm_rw_etc_t:dir { read getattr lock search ioctl add_name remove_name write };
> allow xdm_t xdm_rw_etc_t:file { create ioctl read getattr lock write setattr append link unlink rename };
> 
> And the xdm.te source file does have a comment prior to the
> corresponding source statements that says that this is for wdm.
> But perhaps someone erred and submitted the wrong rules for wdm (we
> don't use it ourselves).

 okay, maybe this is a silly question.

 given the number of errors i am seeing, and given that they won't
 go away, perhaps there is some breakdown in communication between
 the rules being in the policy.conf file and their application to
 packages.

 for example, should i be doing a make relabel every time i add
 some new rules?

 should i force setfiles usage just like there is in
 /etc/dpkg/postinst.d/selinux?

 am i on the right track, here?

> > if i am using wdm (the patched version) is there anything i need to
> > do to get it to work / be accepted?
> 
> Don't know, as I've never used it.

 ah.  then i will try.... xdm, and see what happens.

 (wdm is the patched one from daniel walsh).

--
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: list of permissions created by allow2audit: what do i do now?

[Stephen Smalley]

On Tue, 2004-05-18 at 08:56, Luke Kenneth Casson Leighton wrote:
> well i tried the bung-it-in-and-see approach, and i got a build error
> due to some global policy violations at make policy time because
> of this (and one other):
> 
> > allow hotplug_t etc_runtime_t:file { relabelfrom relabelto };
> 
> ... but what is even stranger is that even though i add in these
> things into a new package (i called it domains/programs/localstuff.te)
> the avc messages _still don't go away_.
> 
> i watched the make policy, it read the newly created file
> (localstuff.te) and the stuff is in policy.conf.
> 
> what am i doing wrong?

Did you successfully perform a make load with the new policy?
To do that, you obviously would have to address the assertion failures;
otherwise, checkpolicy won't compile policy.conf to a binary policy that
can be loaded.

Also, denials can occur for reasons other than missing TE allow rules,
as noted in the Configuring the SELinux policy report, e.g.:
- violation of a constraint from policy/constraints
- type not authorized for role
- role not authorized for user
- role transition not authorized

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: list of permissions created by allow2audit: what do i do now?

[Stephen Smalley]

On Tue, 2004-05-18 at 09:02, Luke Kenneth Casson Leighton wrote:
>  given the number of errors i am seeing, and given that they won't
>  go away, perhaps there is some breakdown in communication between
>  the rules being in the policy.conf file and their application to
>  packages.

They aren't applied until you compile that policy.conf via checkpolicy
and load the resulting binary policy into the kernel.  make load in the
policy directory will do that for you.

>  for example, should i be doing a make relabel every time i add
>  some new rules?

No.  You only have to relabel if you have altered the file contexts
configuration in some manner (but note that this is true if you enable
additional .te files, as that automatically requires their .fc files).

>  ah.  then i will try.... xdm, and see what happens.
> 
>  (wdm is the patched one from daniel walsh).

Are you sure?  I'm not aware of any patched wdm from Dan Walsh, just one
by Tom Vogt that was upstreamed.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: list of permissions created by allow2audit: what do i do now?

[Stephen Smalley]

On Tue, 2004-05-18 at 09:20, Stephen Smalley wrote:
> On Tue, 2004-05-18 at 09:02, Luke Kenneth Casson Leighton wrote:
> >  ah.  then i will try.... xdm, and see what happens.
> > 
> >  (wdm is the patched one from daniel walsh).
> 
> Are you sure?  I'm not aware of any patched wdm from Dan Walsh, just one
> by Tom Vogt that was upstreamed.

BTW, my intent is not to scare you away from using the patched wdm.  I'd
rather see any issues with it worked out so that other people can use it
with SELinux too.

Tom Vogt developed the patch for wdm and upstreamed it.  I think Manoj
developed a patch for xdm and was going to try to upstream it; don't
know if he succeeded.  Dan originally patched gdm for SELinux, but I
think they may have migrated to using pam_selinux for it instead.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: list of permissions created by allow2audit: what do i do now?

[Stephen Smalley]

On Tue, 2004-05-18 at 09:30, Stephen Smalley wrote:
> Tom Vogt developed the patch for wdm and upstreamed it.  I think Manoj
> developed a patch for xdm and was going to try to upstream it; don't
> know if he succeeded.  Dan originally patched gdm for SELinux, but I
> think they may have migrated to using pam_selinux for it instead.

Ok, it looks like the SELinux patch for gdm is also upstream.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: list of permissions created by allow2audit: what do i do now?

[Russell Coker]

On Tue, 18 May 2004 20:40, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> for example, with wdm installed, surely these two shouldn't be
> missed, along with the other wdm_config ones?
>
> 	allow initrc_t xdm_rw_etc_t:dir { add_name remove_name write };
> 	allow initrc_t xdm_rw_etc_t:file { create ioctl rename unlink write };
>
> i mean, i see in domains/programs/xdm.te that there _are_
> allow initrc_t xdm_rw_etc_t permissions for create (create_file_perms)
> and also a comment that init scripts want to check for update
> windowmanagerlist so they get getattr and read allowed.

xdm_t is allowed to create files but initrc_t is only allowed to read them.

It seems that wdm has an perl script used as part of it's startup to create a 
new config file.  I guess that we have to grant initrc_t write access to the 
file for that.  :(

As for the other stuff, some of it should be fixed in later policy versions.  
I'm doing a merge of the latest stuff now and should have a new tree 
available soon.

-- 
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: list of permissions created by allow2audit: what do i do now?

[Luke Kenneth Casson Leighton]

On Tue, May 18, 2004 at 09:30:58AM -0400, Stephen Smalley wrote:
> On Tue, 2004-05-18 at 09:20, Stephen Smalley wrote:
> > On Tue, 2004-05-18 at 09:02, Luke Kenneth Casson Leighton wrote:
> > >  ah.  then i will try.... xdm, and see what happens.
> > > 
> > >  (wdm is the patched one from daniel walsh).
> > 
> > Are you sure?  I'm not aware of any patched wdm from Dan Walsh, just one
> > by Tom Vogt that was upstreamed.
 
 oh, right: yes, it was referenced from selinux.lemuria.org/walsh


--
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: list of permissions created by allow2audit: what do i do now?

[Russell Coker]

On Tue, 18 May 2004 22:56, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> domains/programs/localstuff.te

Use domains/misc/localstuff.te .  Anything in domains/programs needs a 
matching .fc file.

-- 
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: list of permissions created by allow2audit: what do i do now?

[Luke Kenneth Casson Leighton]

On Tue, May 18, 2004 at 09:20:03AM -0400, Stephen Smalley wrote:
> On Tue, 2004-05-18 at 09:02, Luke Kenneth Casson Leighton wrote:
> >  given the number of errors i am seeing, and given that they won't
> >  go away, perhaps there is some breakdown in communication between
> >  the rules being in the policy.conf file and their application to
> >  packages.
> 
> They aren't applied until you compile that policy.conf via checkpolicy
> and load the resulting binary policy into the kernel.  make load in the
> policy directory will do that for you.
 
 okay, yes, done that.

> >  for example, should i be doing a make relabel every time i add
> >  some new rules?
> 
> No.  You only have to relabel if you have altered the file contexts
> configuration in some manner (but note that this is true if you enable
> additional .te files, as that automatically requires their .fc files).

 okay, so i... didn't add anything to file_contexts, i only
 created a domain/program/localstuff.te and ... hm, well i
 _did_ create a blank file_contexts/programs/localstuff.fc,
 so i'm doing a make relabel anyway, just in case.

 as i understand it, the domains define what is allowed, and the
 file_contexts define if you will... the starting points of those
 "allowances" [ i know that's clumsily put ].

 e.g. file_contexts/program/xdm.fc has as its first line:

 /usr/bin/[xgkw]dm       -- system_u:object_r:xdm_exec_t

 therefore, the programs gdm, xdm, kdm and wdm all have type xdm_exec_t
 therefore, according to line 24 of domains/programs/xdm.te, gdm,
 xdm, kdm and wdm are all allowed to automatically transition from
 the initialisation context into a new context named xdm_t.

 therefore, the programs gdm, xdm, kdm and wdm are all allowed to do
 the things that are mentioned as allow xdm_t etc.

 ... so why, if i [appear to be] doing things correctly, do i still
 get errors, for example, when i have explicitly added:

 allow xdm_xserver_t var_lib_t:file { getattr read };

 okay, just a guess: when you declare an allow, are the relevant
 permissions added or replaced if there already exists, say,
 allow xdm_xserver_t var_lib_t:file { read };

 and i then add, in a following line to policy.conf : 
 allow xdm_xserver_t var_lib_t:file { getattr };

 do i end up with _only_ getattr permissions or do i end up
 with both read _and_ getattr?

 l.


--
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: list of permissions created by allow2audit: what do i do now?

[Luke Kenneth Casson Leighton]

On Tue, May 18, 2004 at 09:14:39AM -0400, Stephen Smalley wrote:
> On Tue, 2004-05-18 at 08:56, Luke Kenneth Casson Leighton wrote:
> > well i tried the bung-it-in-and-see approach, and i got a build error
> > due to some global policy violations at make policy time because
> > of this (and one other):
> > 
> > > allow hotplug_t etc_runtime_t:file { relabelfrom relabelto };
> > 
> > ... but what is even stranger is that even though i add in these
> > things into a new package (i called it domains/programs/localstuff.te)
> > the avc messages _still don't go away_.
> > 
> > i watched the make policy, it read the newly created file
> > (localstuff.te) and the stuff is in policy.conf.
> > 
> > what am i doing wrong?
> 
> Did you successfully perform a make load with the new policy?

 yes.

> To do that, you obviously would have to address the assertion failures;
> otherwise, checkpolicy won't compile policy.conf to a binary policy that
> can be loaded.

 yes, i did address the assertions by removing things from
 localstuff.te, in the hope that i can address them later or
 perhaps investigate them.

> Also, denials can occur for reasons other than missing TE allow rules,
> as noted in the Configuring the SELinux policy report, e.g.:
> - violation of a constraint from policy/constraints
> - type not authorized for role
> - role not authorized for user
> - role transition not authorized
 
 hm: this is system context (boot time), and i have a bog-standard
 debian / unstable install, so i don't believe i have done anything
 to cause, say XFree86 to continue to not play ball.

 i _have_ noticed that /var/lib/wdm/authfiles is accessed and have
 changed file_contexts/program/xserver.fc the line that mentions
 /var/lib(64)?/kdm to /var/lib(64)?/[kw]dm.

 l.


--
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: list of permissions created by allow2audit: what do i do now?

[Luke Kenneth Casson Leighton]

On Wed, May 19, 2004 at 12:29:31AM +1000, Russell Coker wrote:
> On Tue, 18 May 2004 22:56, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > domains/programs/localstuff.te
> 
> Use domains/misc/localstuff.te .  Anything in domains/programs needs a 
> matching .fc file.
 
 ah ha!  okay.


--
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: list of permissions created by allow2audit: what do i do now?

[Valdis.Kletnieks]

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

On Tue, 18 May 2004 13:02:44 -0000, Luke Kenneth Casson Leighton said:

>  given the number of errors i am seeing, and given that they won't
>  go away, perhaps there is some breakdown in communication between
>  the rules being in the policy.conf file and their application to
>  packages.
> 
>  for example, should i be doing a make relabel every time i add
>  some new rules?

If you add new *rules* (allow foo_t bar_t...), you need to do a 'make reload'
to get the new policy in place.

If you add new file contexts, that requires a 'make relabel'.

Remember :  *.te changes -> make reload;  *.fc changes -> make relabel.

(If you're clever, you'll invoke setfiles by hand so you only relabel the
file system(s) you need to - if all the stuff you need is on /usr, you don't
need to redo all the other file systems...)

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

Re: list of permissions created by allow2audit: what do i do now?

[Stephen Smalley]

On Tue, 2004-05-18 at 11:11, Luke Kenneth Casson Leighton wrote:
>  okay, so i... didn't add anything to file_contexts, i only
>  created a domain/program/localstuff.te and ... hm, well i
>  _did_ create a blank file_contexts/programs/localstuff.fc,
>  so i'm doing a make relabel anyway, just in case.

Not necessary.

>  as i understand it, the domains define what is allowed, and the
>  file_contexts define if you will... the starting points of those
>  "allowances" [ i know that's clumsily put ].

We call them entrypoint executables for the domains.  Note that file
contexts includes more than just the entrypoint executables; it
specifies the file contexts for all files (ultimately, everything will
match at least one pathname regex, since the /.* entry at the beginning
of types.fc will cover anything that lacks a more specific entry).

>  e.g. file_contexts/program/xdm.fc has as its first line:
> 
>  /usr/bin/[xgkw]dm       -- system_u:object_r:xdm_exec_t
> 
>  therefore, the programs gdm, xdm, kdm and wdm all have type xdm_exec_t
>  therefore, according to line 24 of domains/programs/xdm.te, gdm,
>  xdm, kdm and wdm are all allowed to automatically transition from
>  the initialisation context into a new context named xdm_t.
> 
>  therefore, the programs gdm, xdm, kdm and wdm are all allowed to do
>  the things that are mentioned as allow xdm_t etc.

Right.

>  ... so why, if i [appear to be] doing things correctly, do i still
>  get errors, for example, when i have explicitly added:
> 
>  allow xdm_xserver_t var_lib_t:file { getattr read };
> 
>  okay, just a guess: when you declare an allow, are the relevant
>  permissions added or replaced if there already exists, say,
>  allow xdm_xserver_t var_lib_t:file { read };
> 
>  and i then add, in a following line to policy.conf : 
>  allow xdm_xserver_t var_lib_t:file { getattr };
> 
>  do i end up with _only_ getattr permissions or do i end up
>  with both read _and_ getattr?

checkpolicy takes the union of all such allow rules, so you end up with
both read and getattr.  You can check at runtime via compute_av.  So you
shouldn't still get denials, unless you aren't truly loading the new
policy into the kernel or another factor (e.g. policy/constraints) is
coming into play.  One common mistake is if your kernel isn't up-to-date
and doesn't accept the latest policy version, you may be loading an
older policy version, not the one you just compiled with your new
checkpolicy.


-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: list of permissions created by allow2audit: what do i do now?

[Russell Coker]

On Wed, 19 May 2004 01:11, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>  /usr/bin/[xgkw]dm       -- system_u:object_r:xdm_exec_t
>
>  therefore, the programs gdm, xdm, kdm and wdm all have type xdm_exec_t
>  therefore, according to line 24 of domains/programs/xdm.te, gdm,
>  xdm, kdm and wdm are all allowed to automatically transition from
>  the initialisation context into a new context named xdm_t.

Yes, and they can also transition from initrc_t by line 21.  This is important 
because in Debian xdm is not started directly from init.

>  therefore, the programs gdm, xdm, kdm and wdm are all allowed to do
>  the things that are mentioned as allow xdm_t etc.

Yes.

>  okay, just a guess: when you declare an allow, are the relevant
>  permissions added or replaced if there already exists, say,
>  allow xdm_xserver_t var_lib_t:file { read };

Added.

>  and i then add, in a following line to policy.conf :
>  allow xdm_xserver_t var_lib_t:file { getattr };
>
>  do i end up with _only_ getattr permissions or do i end up
>  with both read _and_ getattr?

Both.

-- 
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: list of permissions created by allow2audit: what do i do now?

[Luke Kenneth Casson Leighton]

On Tue, May 18, 2004 at 01:18:26PM -0400, Stephen Smalley wrote:
> On Tue, 2004-05-18 at 11:11, Luke Kenneth Casson Leighton wrote:
> >  okay, so i... didn't add anything to file_contexts, i only
> >  created a domain/program/localstuff.te and ... hm, well i
> >  _did_ create a blank file_contexts/programs/localstuff.fc,
> >  so i'm doing a make relabel anyway, just in case.
> 
> Not necessary.
> 
> >  as i understand it, the domains define what is allowed, and the
> >  file_contexts define if you will... the starting points of those
> >  "allowances" [ i know that's clumsily put ].
> 
> We call them entrypoint executables for the domains.  Note that file
> contexts includes more than just the entrypoint executables; it
> specifies the file contexts for all files (ultimately, everything will
> match at least one pathname regex, since the /.* entry at the beginning
> of types.fc will cover anything that lacks a more specific entry).
> 
> >  e.g. file_contexts/program/xdm.fc has as its first line:
> > 
> >  /usr/bin/[xgkw]dm       -- system_u:object_r:xdm_exec_t
> > 
> >  therefore, the programs gdm, xdm, kdm and wdm all have type xdm_exec_t
> >  therefore, according to line 24 of domains/programs/xdm.te, gdm,
> >  xdm, kdm and wdm are all allowed to automatically transition from
> >  the initialisation context into a new context named xdm_t.
> > 
> >  therefore, the programs gdm, xdm, kdm and wdm are all allowed to do
> >  the things that are mentioned as allow xdm_t etc.
> 
> Right.
> 
> >  ... so why, if i [appear to be] doing things correctly, do i still
> >  get errors, for example, when i have explicitly added:
> > 
> >  allow xdm_xserver_t var_lib_t:file { getattr read };
> > 
> >  okay, just a guess: when you declare an allow, are the relevant
> >  permissions added or replaced if there already exists, say,
> >  allow xdm_xserver_t var_lib_t:file { read };
> > 
> >  and i then add, in a following line to policy.conf : 
> >  allow xdm_xserver_t var_lib_t:file { getattr };
> > 
> >  do i end up with _only_ getattr permissions or do i end up
> >  with both read _and_ getattr?
> 
> checkpolicy takes the union of all such allow rules, so you end up with
> both read and getattr.  You can check at runtime via compute_av.  

 ah ha.  man compute_av equals undocumented oops okay, let's see
 google "selinux tcontext" and google "selinux scontext" ah ha!
 you mean the three things that are in an avc log message okay,
 let's try this, from:

 May 18 14:35:43 tv kernel: avc:  denied  { destroy } for  pid=1522
 exe=/usr/X11R6/bin/wdmLogin key=0 scontext=system_u:system_r:initrc_t
 tcontext=system_u:syste
 m_r:initrc_t tclass=shm

 try:

	tv:/etc/selinux# compute_av system_u:system_r:xdm_xserver_t
								system_u:system_r:initrc_t shm
	allowed= null

 uhn???


 okay, let's try this:

	tv:/etc/selinux# compute_av lkcl:sysadm_r:sysadm_t
                            system_u:object_r:xserver_exec_t file

	allowed= { ioctl read write create getattr setattr lock relabelfrom
	relabelto append unlink link rename execute execute_no_trans entrypoint
	}

 hm, so there is light, but what colour.

 so lkcl as a sysadm can run the xserver, but the xserver being run
 from xdm as system, at initialisation time, is banned???

 ???  okay, what have i done :)



> So you
> shouldn't still get denials, unless you aren't truly loading the new
> policy into the kernel or another factor (e.g. policy/constraints) is
> coming into play.  One common mistake is if your kernel isn't up-to-date
> and doesn't accept the latest policy version, you may be loading an
> older policy version, not the one you just compiled with your new
> checkpolicy.
 
 ..o*??  mmm... erhm.... so... given that i am building on a system
 with a 2.6.5 non-selinux kernel and then installing that on a 2.6.4
 system which i am trying really hard to upgrade to 2.6.6...

 okay, i'll first try to get the target system onto the 2.6.6 kernel
 again (build just completed) and then attempt a build on that
 machine.
 
 l.


--
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: list of permissions created by allow2audit: what do i do now?

[Luke Kenneth Casson Leighton]

On Tue, May 18, 2004 at 12:25:51PM -0400, Valdis.Kletnieks@vt.edu wrote:

> On Tue, 18 May 2004 13:02:44 -0000, Luke Kenneth Casson Leighton said:
> 
> >  given the number of errors i am seeing, and given that they won't
> >  go away, perhaps there is some breakdown in communication between
> >  the rules being in the policy.conf file and their application to
> >  packages.
> > 
> >  for example, should i be doing a make relabel every time i add
> >  some new rules?
> 
> If you add new *rules* (allow foo_t bar_t...), you need to do a 'make reload'
> to get the new policy in place.
> 
> If you add new file contexts, that requires a 'make relabel'.
> 
> Remember :  *.te changes -> make reload;  *.fc changes -> make relabel.
 
 ta.

> (If you're clever, you'll invoke setfiles by hand so you only relabel the
> file system(s) you need to - if all the stuff you need is on /usr, you don't
> need to redo all the other file systems...)

i'd noticed the technique employed by /etc/dpkg/postinst.d/selinux.



--
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: list of permissions created by allow2audit: what do i do now?

[Luke Kenneth Casson Leighton]

On Tue, May 18, 2004 at 01:18:26PM -0400, Stephen Smalley wrote:
> >  do i end up with _only_ getattr permissions or do i end up
> >  with both read _and_ getattr?
> 
> checkpolicy takes the union of all such allow rules, so you end up with
> both read and getattr.  You can check at runtime via compute_av.  So you
> shouldn't still get denials, unless you aren't truly loading the new
> policy into the kernel or another factor (e.g. policy/constraints) is
> coming into play.  One common mistake is if your kernel isn't up-to-date
> and doesn't accept the latest policy version, you may be loading an
> older policy version, not the one you just compiled with your new
> checkpolicy.

 ah ha!

	tv:/etc/selinux# compute_av system_u:system_r:xdm_xserver_t
	system_u:system_r:initrc_t shm
	allowed= { getattr read write associate unix_read unix_write }

 ha ha!

 okay, one lot disappeared, have another lot to deal with.

 so i think i might be on track, now.

 okay, this is what i get from audit2allow when the selinux programs
 (latest cvs, head tag) are compiled on the same kernel as wot i install
 on:


	allow crond_t lib_t:file { execute };
		#PATH=/lib/libselinux.so.1   :  execute

	allow hotplug_t dbusd_t:unix_stream_socket { connectto };
		#EXE=/usr/lib/hal/hal.hotplug  PATH=/var/run/dbus/system_bus_socket   :  connectto

	allow hotplug_t sysctl_net_t:file { getattr write };
		#EXE=/bin/bash  PATH=/proc/sys/net/ipv4/conf/all/rp_filter   :  getattr
		#EXE=/bin/bash  NAME=rp_filter   :  write

	allow hotplug_t unlabeled_t:file { getattr };
		#EXE=/bin/bash  PATH=/usr/sbin/usbmodules   :  getattr

	allow inetd_t smtp_port_t:tcp_socket { name_bind };
		#EXE=/usr/sbin/inetd   :  name_bind

	allow initrc_t dbusd_t:unix_stream_socket { connectto };
		#EXE=/usr/sbin/hald  PATH=/var/run/dbus/system_bus_socket   :  connectto

	allow initrc_t fonts_t:dir { read };
		#EXE=/usr/bin/gdmlogin  NAME=TrueType   :  read

	allow initrc_t fonts_t:file { read };
		#EXE=/usr/X11R6/bin/xfs-xtt  NAME=fonts.dir   :  read

	allow initrc_t initrc_t:tcp_socket { bind create listen setopt };
		#EXE=/usr/sbin/famd   :  create
		#EXE=/usr/sbin/famd   :  bind
		#EXE=/usr/sbin/famd  LADDR=127.0.0.1  LPORT=834   :  listen
		#EXE=/usr/bin/perl   :  setopt

	allow initrc_t initrc_t:udp_socket { listen };
		#EXE=/usr/bin/perl  LPORT=10000   :  listen

	allow initrc_t netif_lo_t:netif { udp_recv udp_send };
		#EXE=/usr/sbin/famd  SADDR=127.0.0.1  SRC=835  DADDR=127.0.0.1  DEST=111   :  udp_send
		#EXE=/sbin/portmap  SADDR=127.0.0.1  SRC=111  DADDR=127.0.0.1  DEST=835   :  udp_recv

	allow initrc_t node_inaddr_any_t:tcp_socket { node_bind };
		#EXE=/usr/bin/perl  SRC=10000   :  node_bind

	allow initrc_t node_inaddr_any_t:udp_socket { node_bind };
		#EXE=/usr/sbin/famd  SRC=835   :  node_bind
		#EXE=/usr/sbin/famd  SRC=836   :  node_bind

	allow initrc_t node_lo_t:node { udp_recv udp_send };
		#EXE=/usr/sbin/famd  SADDR=127.0.0.1  SRC=835  DADDR=127.0.0.1  DEST=111  NETIF=lo   :  udp_send
		#EXE=/sbin/portmap  SADDR=127.0.0.1  SRC=111  DADDR=127.0.0.1  DEST=835  NETIF=lo   :  udp_recv

	allow initrc_t node_lo_t:tcp_socket { node_bind };
		#EXE=/usr/sbin/famd  SADDR=127.0.0.1  SRC=834   :  node_bind

	allow initrc_t port_t:tcp_socket { name_bind };
		#EXE=/usr/sbin/famd   :  name_bind
		#EXE=/usr/bin/perl   :  name_bind

	allow initrc_t port_t:udp_socket { name_bind };
		#EXE=/usr/sbin/famd   :  name_bind
		#EXE=/usr/bin/perl   :  name_bind

	allow initrc_t portmap_port_t:udp_socket { recv_msg send_msg };
		#EXE=/usr/sbin/famd  SADDR=127.0.0.1  SRC=835  DADDR=127.0.0.1  DEST=111  NETIF=lo   :  send_msg
		#EXE=/sbin/portmap  SADDR=127.0.0.1  SRC=111  DADDR=127.0.0.1  DEST=835  NETIF=lo   :  recv_msg

	allow initrc_t readable_t:file { read };
		#EXE=/usr/bin/gdmlogin  NAME=fonts.conf   :  read

	allow initrc_t readable_t:lnk_file { read };
		#EXE=/usr/bin/gdmlogin  NAME=Bitstream-Vera-Sans.ttf   :  read

	allow initrc_t unlabeled_t:file { execute execute_no_trans ioctl read };
		#EXE=/bin/bash  NAME=makedev   :  execute
		#EXE=/bin/bash  PATH=/etc/init.d/makedev   :  execute_no_trans
		#EXE=/bin/bash  PATH=/etc/init.d/makedev   :  read
		#EXE=/bin/bash  PATH=/etc/init.d/makedev   :  ioctl

	allow initrc_t var_lib_t:dir { setattr };
		#EXE=/usr/bin/gdm  NAME=gdm   :  setattr

	allow initrc_t var_lib_t:fifo_file { create read setattr write };
		#EXE=/usr/bin/gdm  NAME=.gdmfifo   :  create
		#EXE=/usr/bin/gdm  NAME=.gdmfifo   :  read write
		#EXE=/usr/bin/gdm  NAME=.gdmfifo   :  setattr

	allow initrc_t var_log_t:dir { remove_name };
		#EXE=/usr/bin/gdm  NAME=:0.log   :  remove_name

	allow initrc_t var_log_t:file { link unlink };
		#EXE=/usr/bin/gdm  NAME=:0.log   :  link
		#EXE=/usr/bin/gdm  NAME=:0.log   :  unlink

	allow initrc_t var_spool_t:dir { read };
		#EXE=/usr/sbin/atd  NAME=atjobs   :  read

	allow initrc_t xdm_xserver_tmp_t:dir { setattr };
		#EXE=/usr/bin/gdm  NAME=.ICE-unix   :  setattr

	allow initrc_t xdm_xserver_t:unix_stream_socket { connectto };
		#EXE=/usr/bin/gdm  PATH=/tmp/.X11-unix/X0   :  connectto

	allow klogd_t boot_t:file { getattr read };
		#EXE=/sbin/klogd  NAME=System.map-2.6.6-selinux1   :  read
		#EXE=/sbin/klogd  PATH=/boot/System.map-2.6.6-selinux1   :  getattr

	allow local_login_t lib_t:file { execute };
		#PATH=/lib/libselinux.so.1   :  execute
		#PATH=/lib/libselinux.so.1   :  execute

	allow mount_t security_t:dir { mounton };
		#EXE=/bin/mount  PATH=/selinux   :  mounton

	allow syslogd_t unlabeled_t:dir { search };
		#EXE=/sbin/syslogd  NAME=news   :  search

	allow syslogd_t unlabeled_t:file { append ioctl };
		#EXE=/sbin/syslogd  NAME=news.crit   :  append
		#EXE=/sbin/syslogd  PATH=/var/log/news/news.crit   :  ioctl

	allow system_chkpwd_t lib_t:file { execute };
		#PATH=/lib/libselinux.so.1   :  execute

	allow system_chkpwd_t var_run_t:dir { search };
		#EXE=/sbin/unix_verify  NAME=run   :  search

	allow user_t staff_home_t:file { getattr read };
		#EXE=/bin/bash  NAME=.bash_profile   :  read
		#EXE=/bin/bash  PATH=/home/lkcl/.bash_profile   :  getattr

	allow xdm_xserver_t tmpfs_t:file { read write };
		#PATH=/SYSV00000000   :  read write


wheeee :)

--
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: list of permissions created by allow2audit: what do i do now?

[Stephen Smalley]

On Tue, 2004-05-18 at 14:51, Luke Kenneth Casson Leighton wrote:
>tv:/etc/selinux# compute_av system_u:system_r:xdm_xserver_t system_u:system_r:initrc_t shm
> 	allowed= null
> 
>  uhn???

You asked what the X server (started from xdm) (xdm_xserver_t) can do to
a shared memory object (shm) created by a system initialization script
(initrc_t).  And the answer was nothing.  Why is that surprising?

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: list of permissions created by allow2audit: what do i do now?

[Luke Kenneth Casson Leighton]

On Tue, May 18, 2004 at 03:54:22PM -0400, Stephen Smalley wrote:
> On Tue, 2004-05-18 at 14:51, Luke Kenneth Casson Leighton wrote:
> >tv:/etc/selinux# compute_av system_u:system_r:xdm_xserver_t system_u:system_r:initrc_t shm
> > 	allowed= null
> > 
> >  uhn???
> 
> You asked what the X server (started from xdm) (xdm_xserver_t) can do to
> a shared memory object (shm) created by a system initialization script
> (initrc_t).  And the answer was nothing.  Why is that surprising?

 okay, well, i think it sensible to start again, because now i have
 compiled the selinux utils and libs on a system with the same
 kernel as the target machine.

 l.


--
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: list of permissions created by allow2audit: what do i do now?

[Russell Coker]

On Wed, 19 May 2004 04:51, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > checkpolicy takes the union of all such allow rules, so you end up with
> > both read and getattr.  You can check at runtime via compute_av.
>
>  ah ha.  man compute_av equals undocumented oops okay, let's see

I'll start work on man pages for that program and the others that go with it.  
I think that help2man is the correct solution.

>  May 18 14:35:43 tv kernel: avc:  denied  { destroy } for  pid=1522
>  exe=/usr/X11R6/bin/wdmLogin key=0 scontext=system_u:system_r:initrc_t
>  tcontext=system_u:syste
>  m_r:initrc_t tclass=shm
>
>  try:
>
> 	tv:/etc/selinux# compute_av system_u:system_r:xdm_xserver_t
> 								system_u:system_r:initrc_t shm
> 	allowed= null
>
>  uhn???

If you want to match the AVC message then try the following:
compute_av system_u:system_r:initrc_t system_u:system_r:initrc_t shm

>  okay, let's try this:
>
> 	tv:/etc/selinux# compute_av lkcl:sysadm_r:sysadm_t
>                             system_u:object_r:xserver_exec_t file
>
> 	allowed= { ioctl read write create getattr setattr lock relabelfrom
> 	relabelto append unlink link rename execute execute_no_trans entrypoint
> 	}
>
>  hm, so there is light, but what colour.
>
>  so lkcl as a sysadm can run the xserver, but the xserver being run
>  from xdm as system, at initialisation time, is banned???

The tests you have done show that when sysadm_t runs xserver_exec_t it may be 
an entrypoint into another domain, also that xdm_xserver_t has no access to 
shared memory regions created by initrc_t.  Not that it matters as your real 
problem seems to be having a wdm executable labeled with the wrong type such 
that it doesn't transition into xdm_t when it is run from initrc_t.

-- 
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: list of permissions created by allow2audit: what do i do now?

[Luke Kenneth Casson Leighton]

On Wed, May 19, 2004 at 06:48:52AM +1000, Russell Coker wrote:
> On Wed, 19 May 2004 04:51, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > > checkpolicy takes the union of all such allow rules, so you end up with
> > > both read and getattr.  You can check at runtime via compute_av.
> >
> >  ah ha.  man compute_av equals undocumented oops okay, let's see
> 
> I'll start work on man pages for that program and the others that go with it.  
> I think that help2man is the correct solution.
> 
> >  May 18 14:35:43 tv kernel: avc:  denied  { destroy } for  pid=1522
> >  exe=/usr/X11R6/bin/wdmLogin key=0 scontext=system_u:system_r:initrc_t
> >  tcontext=system_u:syste
> >  m_r:initrc_t tclass=shm
> >
> >  try:
> >
> > 	tv:/etc/selinux# compute_av system_u:system_r:xdm_xserver_t
> > 								system_u:system_r:initrc_t shm
> > 	allowed= null
> >
> >  uhn???
> 
> If you want to match the AVC message then try the following:
> compute_av system_u:system_r:initrc_t system_u:system_r:initrc_t shm

allowed= { create destroy read write unix_read unix_write }

> >  okay, let's try this:
> >
> > 	tv:/etc/selinux# compute_av lkcl:sysadm_r:sysadm_t
> >                             system_u:object_r:xserver_exec_t file
> >
> > 	allowed= { ioctl read write create getattr setattr lock relabelfrom
> > 	relabelto append unlink link rename execute execute_no_trans entrypoint
> > 	}
> >
> >  hm, so there is light, but what colour.
> >
> >  so lkcl as a sysadm can run the xserver, but the xserver being run
> >  from xdm as system, at initialisation time, is banned???
> 
> The tests you have done show that when sysadm_t runs xserver_exec_t it may be 
> an entrypoint into another domain, also that xdm_xserver_t has no access to 
> shared memory regions created by initrc_t.  Not that it matters as your real 
> problem seems to be having a wdm executable labeled with the wrong type such 
> that it doesn't transition into xdm_t when it is run from initrc_t.

 i don't pretend to understand everything yet in order to appreciate
 what you say, however i successfully built a debian selinux 2.6.6
 kernel (faked up a debian/rules etc in order to convince make-kpkg to run)
 and installed it on both the build and target system: suddenly
 things have got a lot better...


--
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.