file_contexts patch

file_contexts patch

[Thomas Bleher]

[-- Attachment #1.1: Type: text/plain, Size: 266 bytes --]

The attached patch adds some file_contexts and most importantly labels
libs under /opt correctly.

Please apply.

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 #1.2: file_contexts.patch --]
[-- Type: text/plain, Size: 3322 bytes --]

diff -urN orig/file_contexts/program/hotplug.fc mod/file_contexts/program/hotplug.fc
--- orig/file_contexts/program/hotplug.fc	2004-06-19 10:31:43.000000000 +0200
+++ mod/file_contexts/program/hotplug.fc	2004-07-16 22:10:08.000000000 +0200
@@ -5,4 +5,5 @@
 /etc/hotplug/.*agent	--	system_u:object_r:sbin_t
 /etc/hotplug/.*rc	-- 	system_u:object_r:sbin_t
 /etc/hotplug/hotplug.functions --	system_u:object_r:sbin_t
+/var/run/usb(/.*)?		system_u:object_r:hotplug_var_run_t
 
diff -urN orig/file_contexts/program/screensaver.fc mod/file_contexts/program/screensaver.fc
--- orig/file_contexts/program/screensaver.fc	2004-05-24 00:55:04.000000000 +0200
+++ mod/file_contexts/program/screensaver.fc	2004-07-16 22:10:08.000000000 +0200
@@ -1,5 +1,7 @@
 # screensaver
 /usr/X11R6/bin/xscreensaver		--	system_u:object_r:screensaver_exec_t
-/usr/X11R6/bin/xscreensaver-demo		--	system_u:object_r:screensaver_exec_t
+/usr/X11R6/bin/xscreensaver-demo	--      system_u:object_r:screensaver_exec_t
+/opt/kde3/bin/kdesktop_lock		--	system_u:object_r:screensaver_exec_t
+/usr/bin/kdesktop_lock			--	system_u:object_r:screensaver_exec_t
 /usr/X11R6/lib(64)?/xscreensaver(.*)?	system_u:object_r:bin_t
 HOME_DIR/\.xscreensaver	system_u:object_r:ROLE_screensaver_rw_t
diff -urN orig/file_contexts/program/xdm.fc mod/file_contexts/program/xdm.fc
--- orig/file_contexts/program/xdm.fc	2004-06-19 10:31:44.000000000 +0200
+++ mod/file_contexts/program/xdm.fc	2004-07-16 22:12:17.000000000 +0200
@@ -17,7 +17,7 @@
 /etc/kde/kdm/Xsession	--	system_u:object_r:xsession_exec_t
 /var/run/xdmctl(/.*)?		system_u:object_r:xdm_var_run_t
 /var/run/console.*		system_u:object_r:xdm_var_run_t
-/var/lib/[kw]dm(/.*)?		system_u:object_r:xdm_var_lib_t
+/var/lib/[xkw]dm(/.*)?		system_u:object_r:xdm_var_lib_t
 /usr/lib/qt-3.3/etc/settings/qtrc(/.*)? system_u:object_r:xdm_var_lib_t
 
 #
diff -urN orig/file_contexts/types.fc mod/file_contexts/types.fc
--- orig/file_contexts/types.fc	2004-07-12 23:41:14.000000000 +0200
+++ mod/file_contexts/types.fc	2004-07-16 22:10:08.000000000 +0200
@@ -177,6 +177,7 @@
 /u?dev/input/event.*	-c	system_u:object_r:event_device_t
 /u?dev/input/mice	-c	system_u:object_r:mouse_device_t
 /u?dev/input/js.*	-c	system_u:object_r:mouse_device_t
+/u?dev/js.*		-c	system_u:object_r:mouse_device_t
 /u?dev/ptmx		-c	system_u:object_r:ptmx_t
 /u?dev/sequencer	-c	system_u:object_r:misc_device_t
 /u?dev/fb[0-9]*		-c	system_u:object_r:framebuf_device_t
@@ -207,6 +208,7 @@
 /u?dev/ht[0-1]		-b	system_u:object_r:tape_device_t
 /u?dev/n?osst[0-3].*	-c	system_u:object_r:tape_device_t
 /u?dev/n?pt[0-9]+	-c	system_u:object_r:tape_device_t
+/u?dev/usbscanner	-c	system_u:object_r:scanner_device_t
 /u?dev/usb/scanner.*	-c	system_u:object_r:scanner_device_t
 /u?dev/usb/dc2xx.*	-c	system_u:object_r:scanner_device_t
 /u?dev/usb/mdc800.*	-c	system_u:object_r:scanner_device_t
@@ -220,7 +222,10 @@
 /opt(/.*)?			system_u:object_r:usr_t
 /opt/[^/]*/bin(/.*)?		system_u:object_r:bin_t
 /opt/[^/]*/lib(/.*)?		system_u:object_r:lib_t
+/opt/[^/]*/lib/lib[^/]*\.so(\.[^/]*)*	--	system_u:object_r:shlib_t
+/opt/[^/]*/lib/.*/lib[^/]*\.so(\.[^/]*)*	--	system_u:object_r:shlib_t
 /opt/[^/]*/man(/.*)?		system_u:object_r:man_t
+/opt/[^/]*/libexec(/.*)?	system_u:object_r:bin_t
 
 #
 # /etc

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

Re: file_contexts patch

[Russell Coker]

On Sat, 17 Jul 2004 06:15, Thomas Bleher <bleher@informatik.uni-muenchen.de> 
wrote:
> The attached patch adds some file_contexts and most importantly labels
> libs under /opt correctly.

Why does kdesktop_lock need to be labelled as screensaver_exec_t?  The problem 
that caused the creation of the screen saver policy has only been reported 
under GNOME, and kdesktop_lock has been working well for me for years without 
such policy.

What is /dev/usbscanner?  It's not in devices.txt in the kernel source and not 
installed by default on any Debian or Fedora system.

The other stuff seems 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: file_contexts patch

[Thomas Bleher]

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

* Russell Coker <russell@coker.com.au> [2004-07-17 00:02]:
> On Sat, 17 Jul 2004 06:15, Thomas Bleher <bleher@informatik.uni-muenchen.de> 
> wrote:
> > The attached patch adds some file_contexts and most importantly labels
> > libs under /opt correctly.
> 
> Why does kdesktop_lock need to be labelled as screensaver_exec_t?  The problem 
> that caused the creation of the screen saver policy has only been reported 
> under GNOME, and kdesktop_lock has been working well for me for years without 
> such policy.

The screensaver policy has auth_chkpwd which is needed when locking the
screen IIRC. The only problem is that kdesktop_lock doesn't use
unix_chkpwd but has its own program (kcheckpass). I have labeled it
chkpwd_exec_t which works fine, but unfortunately kcheckpass needs some
additional permissions (from macros/program/chkpwd_macros.te):

ifelse($1, `system', `', `allow $1_chkpwd_t $1_t:unix_stream_socket { read write };')
# read KDesktop
allow system_chkpwd_t $1_home_t:dir read;
# write to .xsession-errors
allow system_chkpwd_t $1_home_t:file write;
(Or something like that. I live on NFS and just converted the rules)

I do not know if this is mergable into mainline.
 
> What is /dev/usbscanner?  It's not in devices.txt in the kernel source and not 
> installed by default on any Debian or Fedora system.

Call it a SuSE oddity:
# ls -l /dev/usbscanner /dev/usb/scanner0
crw-rw----    1 root     root     180,  48 Sep  9  2002 /dev/usb/scanner0
crw-r--r--    1 root     root     180,  48 Sep  9  2002 /dev/usbscanner
(why they have different permissions there I can't imagine)

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: file_contexts patch

[Russell Coker]

On Sat, 17 Jul 2004 08:42, Thomas Bleher <bleher@informatik.uni-muenchen.de> 
wrote:
> > Why does kdesktop_lock need to be labelled as screensaver_exec_t?  The
> > problem that caused the creation of the screen saver policy has only been
> > reported under GNOME, and kdesktop_lock has been working well for me for
> > years without such policy.
>
> The screensaver policy has auth_chkpwd which is needed when locking the
> screen IIRC. The only problem is that kdesktop_lock doesn't use
> unix_chkpwd but has its own program (kcheckpass). I have labeled it
> chkpwd_exec_t which works fine, but unfortunately kcheckpass needs some
> additional permissions (from macros/program/chkpwd_macros.te):

kcheckpass should use PAM and therefore use unix_chkpwd.

> ifelse($1, `system', `', `allow $1_chkpwd_t $1_t:unix_stream_socket { read
> write };') # read KDesktop
> allow system_chkpwd_t $1_home_t:dir read;
> # write to .xsession-errors
> allow system_chkpwd_t $1_home_t:file write;
> (Or something like that. I live on NFS and just converted the rules)
>
> I do not know if this is mergable into mainline.

It's not something that we want to do if we can avoid it.

> > What is /dev/usbscanner?  It's not in devices.txt in the kernel source
> > and not installed by default on any Debian or Fedora system.
>
> Call it a SuSE oddity:
> # ls -l /dev/usbscanner /dev/usb/scanner0
> crw-rw----    1 root     root     180,  48 Sep  9  2002 /dev/usb/scanner0
> crw-r--r--    1 root     root     180,  48 Sep  9  2002 /dev/usbscanner
> (why they have different permissions there I can't imagine)

Could you file a bug report in the SUSE bug tracking system about this?

I suggest that you request that /dev/usbscanner become a sym-link 
to /dev/usb/scanner0.  Then it will match the devices.txt in the kernel 
source, have no problems with consistency of permissions, and not need any 
modifications to the SE Linux policy.

Maybe we should have a suse.te and suse.fc for such things?  One thing we want 
to avoid if possible is having entries in types.fc for distribution specific 
names which bloat types.fc and make setfiles run more slowly.

-- 
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: file_contexts patch

[Thomas Bleher]

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

* Russell Coker <russell@coker.com.au> [2004-07-17 05:16]:
> On Sat, 17 Jul 2004 08:42, Thomas Bleher <bleher@informatik.uni-muenchen.de> 
> wrote:
> > > Why does kdesktop_lock need to be labelled as screensaver_exec_t?  The
> > > problem that caused the creation of the screen saver policy has only been
> > > reported under GNOME, and kdesktop_lock has been working well for me for
> > > years without such policy.
> >
> > The screensaver policy has auth_chkpwd which is needed when locking the
> > screen IIRC. The only problem is that kdesktop_lock doesn't use
> > unix_chkpwd but has its own program (kcheckpass). I have labeled it
> > chkpwd_exec_t which works fine, but unfortunately kcheckpass needs some
> > additional permissions (from macros/program/chkpwd_macros.te):
> 
> kcheckpass should use PAM and therefore use unix_chkpwd.

Doh. Of course you are right. I checked again and kcheckpass does the
right thing and calls PAM but the SuSE PAM implementation doesn't use
unix_chkpwd yet.
So you can dismiss that part of my patch.

> > > What is /dev/usbscanner?  It's not in devices.txt in the kernel source
> > > and not installed by default on any Debian or Fedora system.
> >
> > Call it a SuSE oddity:
> > # ls -l /dev/usbscanner /dev/usb/scanner0
> > crw-rw----    1 root     root     180,  48 Sep  9  2002 /dev/usb/scanner0
> > crw-r--r--    1 root     root     180,  48 Sep  9  2002 /dev/usbscanner
> > (why they have different permissions there I can't imagine)
> 
> Could you file a bug report in the SUSE bug tracking system about this?

Done.
 
> Maybe we should have a suse.te and suse.fc for such things?  One thing we want 
> to avoid if possible is having entries in types.fc for distribution specific 
> names which bloat types.fc and make setfiles run more slowly.

I think this is a good idea. I have a few other policy snippets which
are needed on SuSE but won't be suitable for general policy.
As a start, I have attached a small suse.te and suse.fc.
Can this be included in CVS?

Thomas

PS: Thanks for your feedback and advise!

-- 
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: suse.te --]
[-- Type: text/plain, Size: 888 bytes --]

# DESC: SuSE-specific policy
#
# Author: Thomas Bleher <ThomasBleher@gmx.de>
#
# Note: For many of these permissions it would be better to change the scripts

# policy for cron
# ===============
create_dir_file(system_crond_t, tetex_data_t)

# backup of the rpm-database (/var/backup...)
allow system_crond_t var_t:dir { add_name remove_name write };
allow system_crond_t var_t:file { create unlink write };

# policy for initrc
# =================
# move /var/log/boot.msg
allow initrc_t var_log_t:dir { add_name remove_name write };
# /usr/sbin/zic wants to link /etc/localtime
allow initrc_t locale_t:file { link unlink };
# for /tmp/.X11-unix and so on (see /etc/init.d/boot.localnet)
allow initrc_t { xdm_xserver_tmp_t tmp_t }:dir { setattr };

# other stuff
# ===========
# gpg (when called from rpm) wants this so it doesn't dump core on errors
allow rpm_t self:process setrlimit;

[-- Attachment #3: suse.fc --]
[-- Type: text/plain, Size: 502 bytes --]

# suse specific file_contexts

/var/lib/samba/bin(/.*)?                                system_u:object_r:bin_t
/var/lib/samba/bin/.*\.so(\.[^/]*)*             -l      system_u:object_r:lib_t
/usr/lib/samba/classic/.*                       --      system_u:object_r:bin_t
/usr/lib/samba/classic/[^/]*\.so(\.[^/]*)*      --      system_u:object_r:shlib_t

/u?dev/usbscanner	-c	system_u:object_r:scanner_device_t

# suse puts shell scripts there :-(
/usr/share/apache2/.*  --      system_u:object_r:bin_t

Re: file_contexts patch

[Russell Coker]

On Sun, 18 Jul 2004 05:53, Thomas Bleher <bleher@informatik.uni-muenchen.de> 
wrote:
> > kcheckpass should use PAM and therefore use unix_chkpwd.
>
> Doh. Of course you are right. I checked again and kcheckpass does the
> right thing and calls PAM but the SuSE PAM implementation doesn't use
> unix_chkpwd yet.
> So you can dismiss that part of my patch.

http://cvs.sourceforge.net/viewcvs.py/pam/Linux-PAM/modules/pam_unix/unix_chkpwd.c

unix_chkpwd has been around for years, I can't believe that it's something 
that they haven't got to it yet.

Are you running kcheckpass as root (maybe SETUID)?  If so then SUSE would be 
using PAM without my patch to pam_unix.so which allows unix_chkpwd to be 
called if /etc/shadow can't be opened as root (without that patch it just 
aborts).  Also does SUSE have unix_verify (again part of my patch) installed?  
If not then the default policy will not work in all situations...

> > Maybe we should have a suse.te and suse.fc for such things?  One thing we
> > want to avoid if possible is having entries in types.fc for distribution
> > specific names which bloat types.fc and make setfiles run more slowly.
>
> I think this is a good idea. I have a few other policy snippets which
> are needed on SuSE but won't be suitable for general policy.
> As a start, I have attached a small suse.te and suse.fc.
> Can this be included in CVS?

I'll put it in my tree, Steve will have to decide about CVS when he next does 
an update.

# Depends: rpm.te

suse.te needs the above line.

-- 
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: file_contexts patch

[Thomas Bleher]

* Russell Coker <russell@coker.com.au> [2004-07-18 06:33]:
> On Sun, 18 Jul 2004 05:53, Thomas Bleher <bleher@informatik.uni-muenchen.de> 
> wrote:
> > > kcheckpass should use PAM and therefore use unix_chkpwd.
> >
> > Doh. Of course you are right. I checked again and kcheckpass does the
> > right thing and calls PAM but the SuSE PAM implementation doesn't use
> > unix_chkpwd yet.
> > So you can dismiss that part of my patch.
> 
> http://cvs.sourceforge.net/viewcvs.py/pam/Linux-PAM/modules/pam_unix/unix_chkpwd.c
> 
> unix_chkpwd has been around for years, I can't believe that it's something 
> that they haven't got to it yet.

unix_chkpwd is included in the PAM package, it's just that suse has
developed their own pam module (pam_unix2.so) which doesn't use
unix_chkpwd AFAIK.
 
> Are you running kcheckpass as root (maybe SETUID)?  
It's sgid shadow.

> If so then SUSE would be 
> using PAM without my patch to pam_unix.so which allows unix_chkpwd to be 
> called if /etc/shadow can't be opened as root (without that patch it just 
> aborts).  Also does SUSE have unix_verify (again part of my patch) installed?  
> If not then the default policy will not work in all situations...

Yeah, I had to give login, ssh, kdm, ... the auth attribute.
I do not know which part of the patch is missing, it's been a while
since I looked at the PAM code.
At the time I made the packages I simply gave up on PAM after a while
because it was too complicated and I didn't want to find out how suse's
module differed from the rest of the world...
I guess it's time I dig again into this mess, sigh.
I really wish there was someone actively maintaining this code.

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: file_contexts patch

[Russell Coker]

On Mon, 19 Jul 2004 01:03, Thomas Bleher <bleher@informatik.uni-muenchen.de> 
wrote:
> > unix_chkpwd has been around for years, I can't believe that it's
> > something that they haven't got to it yet.
>
> unix_chkpwd is included in the PAM package, it's just that suse has
> developed their own pam module (pam_unix2.so) which doesn't use
> unix_chkpwd AFAIK.

Why can't you just use pam_unix.so instead?

Also it shouldn't be that difficult to fix the SUSE code.

> > Are you running kcheckpass as root (maybe SETUID)?
>
> It's sgid shadow.

That's entirely the wrong approach.  Any bug in kcheckpass on a SUSE system 
will give full access to /etc/shadow.

> > If so then SUSE would be
> > using PAM without my patch to pam_unix.so which allows unix_chkpwd to be
> > called if /etc/shadow can't be opened as root (without that patch it just
> > aborts).  Also does SUSE have unix_verify (again part of my patch)
> > installed? If not then the default policy will not work in all
> > situations...
>
> Yeah, I had to give login, ssh, kdm, ... the auth attribute.
> I do not know which part of the patch is missing, it's been a while
> since I looked at the PAM code.
> At the time I made the packages I simply gave up on PAM after a while
> because it was too complicated and I didn't want to find out how suse's
> module differed from the rest of the world...
> I guess it's time I dig again into this mess, sigh.
> I really wish there was someone actively maintaining this code.

-- 
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: file_contexts patch

[Thomas Bleher]

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

* Russell Coker <russell@coker.com.au> [2004-07-19 03:25]:
> On Mon, 19 Jul 2004 01:03, Thomas Bleher <bleher@informatik.uni-muenchen.de> 
> wrote:
> > > unix_chkpwd has been around for years, I can't believe that it's
> > > something that they haven't got to it yet.
> >
> > unix_chkpwd is included in the PAM package, it's just that suse has
> > developed their own pam module (pam_unix2.so) which doesn't use
> > unix_chkpwd AFAIK.
> 
> Why can't you just use pam_unix.so instead?

At the time I installed SELinux on the computers here my primary focus
was to get a working system without breaking too much so I didn't want
to muck around with pam config if possible.

After this mail exchange I looked at the code again. And indeed, the
patch Russell mentioned earlier (to make pam_unix use unix_chkpwd if it
can't access /etc/shadow) was missing. After adding this patch, pam now
runs fine without every login program needing the auth attribute.

So, for everyone who uses my packages, please update to the latest pam,
which you can get from my site. After that, replace every occurrence of
pam_unix.so or pam_unix2.so under /etc/pam.d with pam_unix_auth.so,
pam_unix_acct.so, pam_unix_passwd.so or pam_unix_session.so,
respectively.

Thomas

PS: Thanks to Russell for nudging me to this.

-- 
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: file_contexts patch

[Stephen Smalley]

On Sat, 2004-07-17 at 15:53, Thomas Bleher wrote:
> * Russell Coker <russell@coker.com.au> [2004-07-17 05:16]:
> > Maybe we should have a suse.te and suse.fc for such things?  One thing we want 
> > to avoid if possible is having entries in types.fc for distribution specific 
> > names which bloat types.fc and make setfiles run more slowly.
> 
> I think this is a good idea. I have a few other policy snippets which
> are needed on SuSE but won't be suitable for general policy.
> As a start, I have attached a small suse.te and suse.fc.
> Can this be included in CVS?

Would it be better to make the distro a tunable (e.g.
policy/tunables/distro.te) and use ifdef's in the individual .te files
and .fc files for the distro-specific changes to a given domain?  I'd
particularly like to see all of the RedHat-specific changes moved from
rpm.{te,fc} into something that is clearly specific to RedHat.

-- 
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: file_contexts patch

[Thomas Bleher]

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

* Stephen Smalley <sds@epoch.ncsc.mil> [2004-07-26 22:26]:
> On Sat, 2004-07-17 at 15:53, Thomas Bleher wrote:
> > * Russell Coker <russell@coker.com.au> [2004-07-17 05:16]:
> > > Maybe we should have a suse.te and suse.fc for such things?  One thing we want 
> > > to avoid if possible is having entries in types.fc for distribution specific 
> > > names which bloat types.fc and make setfiles run more slowly.
> > 
> > I think this is a good idea. I have a few other policy snippets which
> > are needed on SuSE but won't be suitable for general policy.
> > As a start, I have attached a small suse.te and suse.fc.
> > Can this be included in CVS?
> 
> Would it be better to make the distro a tunable (e.g.
> policy/tunables/distro.te) and use ifdef's in the individual .te files
> and .fc files for the distro-specific changes to a given domain?  I'd
> particularly like to see all of the RedHat-specific changes moved from
> rpm.{te,fc} into something that is clearly specific to RedHat.

That would be okay with me.

To support distro-specific file contexts we would have to modify the
build to include the tunables when creating the file_contexts file (it
is already run through m4). Something like the following quick patch:

--- orig/Makefile
+++ mod/Makefile
@@ -139,9 +139,9 @@
 	@mkdir -p $(CONTEXTPATH)/files
 	install -m 644 $(FC) $(FCPATH)
 
-$(FC): $(FCFILES) domains/program domains/misc file_contexts/program file_contexts/misc users /etc/passwd
+$(FC): $(FCFILES) $(ALL_TUNABLES) domains/program domains/misc file_contexts/program file_contexts/misc users /etc/passwd
 	@echo "Building file_contexts ..."
-	@m4 $(FCFILES) > $@.tmp
+	@m4 $(ALL_TUNABLES) $(FCFILES) > $@.tmp
 	@grep -v "^/root" $@.tmp > $@.root
 	@/usr/sbin/genhomedircon . $@.root  > $@
 	@grep "^/root" $@.tmp >> $@


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: file_contexts patch

[Russell Coker]

On Tue, 27 Jul 2004 08:06, Thomas Bleher <bleher@informatik.uni-muenchen.de> 
wrote:
> To support distro-specific file contexts we would have to modify the
> build to include the tunables when creating the file_contexts file (it
> is already run through m4). Something like the following quick patch:

Good idea.  I've put it in my tree.

-- 
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: file_contexts patch

[Stephen Smalley]

On Mon, 2004-07-26 at 18:06, Thomas Bleher wrote:
> That would be okay with me.
> 
> To support distro-specific file contexts we would have to modify the
> build to include the tunables when creating the file_contexts file (it
> is already run through m4). Something like the following quick patch:

Merged.  Also added a tunables/distro.te file.

-- 
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: file_contexts patch

[Valdis.Kletnieks]

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

On Mon, 26 Jul 2004 16:25:53 EDT, Stephen Smalley said:

> Would it be better to make the distro a tunable (e.g.
> policy/tunables/distro.te) and use ifdef's in the individual .te files
> and .fc files for the distro-specific changes to a given domain?  I'd
> particularly like to see all of the RedHat-specific changes moved from
> rpm.{te,fc} into something that is clearly specific to RedHat.

Go for it.  Especially if we start using m4 to handle the case where the files
are the same, but different distros put them elsewhere - so file_contexts would have

$distro_foobar_dir/foobar.conf -- <whatever>

and then the distro.te could set $distro_foobar_dir as needed.

All the distros that use RPM but aren't RedHat (And I'll argue that for this
purpose, RHEL and Fedora have diverged enough to count) will be happy with
rpm.* not being abused....

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

Re: file_contexts patch

[Stephen Smalley]

On Mon, 2004-07-26 at 16:25, Stephen Smalley wrote:
> Would it be better to make the distro a tunable (e.g.
> policy/tunables/distro.te) and use ifdef's in the individual .te files
> and .fc files for the distro-specific changes to a given domain?  I'd
> particularly like to see all of the RedHat-specific changes moved from
> rpm.{te,fc} into something that is clearly specific to RedHat.

Note that in addition to reviewing the contents of rpm.te and rpm.fc for
RedHat-specific customizations, this change would require reviewing all
uses of ifdef(`rpm.te') throughout the various .te files, as some of
those conditional blocks are for RedHat-specific customizations while
others are for rules that should always be included when the rpm domain
is enabled in the policy (and thus should still be included for other
rpm-using distros).

-- 
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: file_contexts patch

[Valdis.Kletnieks]

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

On Tue, 27 Jul 2004 09:38:03 EDT, Stephen Smalley said:

> Note that in addition to reviewing the contents of rpm.te and rpm.fc for
> RedHat-specific customizations, this change would require reviewing all
> uses of ifdef(`rpm.te') throughout the various .te files, as some of
> those conditional blocks are for RedHat-specific customizations while
> others are for rules that should always be included when the rpm domain
> is enabled in the policy (and thus should still be included for other
> rpm-using distros).

But still.. <Insert sound clip of Wilford Brimley "It's the right thing to do"> :)

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

Re: file_contexts patch

[Russell Coker]

On Tue, 27 Jul 2004 23:38, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> On Mon, 2004-07-26 at 16:25, Stephen Smalley wrote:
> > Would it be better to make the distro a tunable (e.g.
> > policy/tunables/distro.te) and use ifdef's in the individual .te files
> > and .fc files for the distro-specific changes to a given domain?  I'd
> > particularly like to see all of the RedHat-specific changes moved from
> > rpm.{te,fc} into something that is clearly specific to RedHat.
>
> Note that in addition to reviewing the contents of rpm.te and rpm.fc for
> RedHat-specific customizations, this change would require reviewing all
> uses of ifdef(`rpm.te') throughout the various .te files, as some of
> those conditional blocks are for RedHat-specific customizations while
> others are for rules that should always be included when the rpm domain
> is enabled in the policy (and thus should still be included for other
> rpm-using distros).

Almost all instances of ifdef(`rpm.te' are for Red Hat specific issues, it's 
probably best to just globally change such ifdef's to check for red_hat or 
whatever the new macro will be and then change back anything that seems 
necessary after testing on SUSE.

-- 
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: file_contexts patch

[Stephen Smalley]

On Tue, 2004-07-27 at 22:53, Russell Coker wrote:
> Almost all instances of ifdef(`rpm.te' are for Red Hat specific issues, it's 
> probably best to just globally change such ifdef's to check for red_hat or 
> whatever the new macro will be and then change back anything that seems 
> necessary after testing on SUSE.

Ok, I've replaced ifdef's for rpm.te and dpkg.te with ifdefs for the new
distro tunables that can be defined in tunables/distro.te, and have also
adjusted rpm.fc to use these distro tunables and moved the
RedHat-specific inetd-related entries to inetd.fc, wrapped with an
ifdef(`redhat').  So I would suggest breaking up suse.te and suse.fc
among the individual domain .te and .fc files, and wrapping with
ifdef(`suse').  Naturally, anything from suse.te that might be generally
applicable to other distros should be considered for inclusion outside
of any ifdef.

-- 
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: file_contexts patch

[Luke Kenneth Casson Leighton]

thomas,

i note the addition of /var/run/usb here.

is that because SuSE has modified the hotplug package
to place state information in that directory?

please advise, because i have raised a bug-request with
the debian hotplug maintainers, and i believe that the
upstream maintainers favour the use of /etc/hotplug/run
rather than /var/run/something.

the reason stated is because /var could be on a different partition
that may not have been mounted (bearing in mind that
/etc/init.d/mountall.sh is called first to mount local
partitions, and hotplug is pretty much immediately next,
and pretty much everything else is tertiary).

personally i think that reason is not good enough, because
if say you have /var on a firmware-based usb memory stick
(requiring a hotplug-generated event to load the firmware),
or /var is nfs-mounted over a firmware-based usb network card,
then you're really asking for a lot of trouble.

so, _if_ SuSE have made that decision, it would be good to know
the reasoning and to have some way of arm-twisting the hotplug
maintainers to a more sensible decision [that is FHS compliant
aside from anything else].

l.

On Fri, Jul 16, 2004 at 10:15:31PM +0200, Thomas Bleher wrote:
> The attached patch adds some file_contexts and most importantly labels
> libs under /opt correctly.
> 
> Please apply.
> 
> Thomas
> 
> -- 
> http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages
> GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA  D09E C562 2BAE B2F4 ABE7

> diff -urN orig/file_contexts/program/hotplug.fc mod/file_contexts/program/hotplug.fc
> --- orig/file_contexts/program/hotplug.fc	2004-06-19 10:31:43.000000000 +0200
> +++ mod/file_contexts/program/hotplug.fc	2004-07-16 22:10:08.000000000 +0200
> @@ -5,4 +5,5 @@
>  /etc/hotplug/.*agent	--	system_u:object_r:sbin_t
>  /etc/hotplug/.*rc	-- 	system_u:object_r:sbin_t
>  /etc/hotplug/hotplug.functions --	system_u:object_r:sbin_t
> +/var/run/usb(/.*)?		system_u:object_r:hotplug_var_run_t
>  

--
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: file_contexts patch

[Thomas Bleher]

[Note: I do not know hotplug very much; neither do I speak for SuSE]

* Luke Kenneth Casson Leighton <lkcl@lkcl.net> [2004-07-17 13:35]:
> thomas,
> 
> i note the addition of /var/run/usb here.
> 
> is that because SuSE has modified the hotplug package
> to place state information in that directory?

It does indeed store scripts there to be run on device removal - see
/etc/hotplug/usb.agent. (SuSE 9.1 also has /var/run/hotplug, as I just
discovered)

However, it does not seem like SuSE has modified the package at all,
they seem to use the vanilla package from
http://linux-hotplug.sourceforge.net/
Both upstream and suse use /var/run/usb for variable data.
And while Debian has modified /etc/hotplug/usb.agent a bit, it still
stores its scripts under /var/run/usb.

> please advise, because i have raised a bug-request with
> the debian hotplug maintainers, and i believe that the
> upstream maintainers favour the use of /etc/hotplug/run
> rather than /var/run/something.

The script you are probably talking about (/etc/hotplug/net.rc) is
specific to Debian. I do not know of other hotplug scripts which write
to /etc, but then I do not know hotplug all that much.

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.