file.te and tmpfs

file.te and tmpfs

[Russell Coker]

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

The attached patch is needed for correct tty labelling on Fedora.

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

[-- Attachment #2: diff --]
[-- Type: text/x-diff, Size: 398 bytes --]

--- /usr/src/se/policy/types/file.te	2004-09-15 16:31:24.000000000 +1000
+++ types/file.te	2004-09-21 15:20:10.000000000 +1000
@@ -259,7 +259,7 @@
 #
 allow { file_type device_type } fs_t:filesystem associate;
 ifdef(`distro_redhat', `
-allow dev_fs tmpfs_t:filesystem associate;
+allow { dev_fs ttyfile } tmpfs_t:filesystem associate;
 ')
 
 # Allow the pty to be associated with the file system.

Re: file.te and tmpfs

[James Carter]

Merged.

On Tue, 2004-09-21 at 01:26, Russell Coker wrote:
> The attached patch is needed for correct tty labelling on Fedora.
-- 
James Carter <jwcart2@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.

Remove unrestricted_admin

[Daniel J Walsh]

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

Remove unrestricted_admin tunable.  This was a bad idea :^(

Add modutil for targteted to get relabel to work better.


[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 5298 bytes --]

diff --exclude-from=exclude -N -u -r nsapolicy/domains/admin.te policy-1.17.20/domains/admin.te
--- nsapolicy/domains/admin.te	2004-09-09 15:36:12.000000000 -0400
+++ policy-1.17.20/domains/admin.te	2004-09-23 09:29:42.799096131 -0400
@@ -4,7 +4,6 @@
 
 # sysadm_t is the system administrator domain.
 type sysadm_t, domain, privlog, privowner, admin, userdomain, web_client_domain, privhome, etc_writer, privmodule, nscd_client_domain
-ifdef(`unrestricted_admin', `, fs_domain, privmem, sysctl_kernel_writer, auth, auth_write, unrestricted')
 ifdef(`direct_sysadm_daemon', `, priv_system_role')
 ; dnl end of sysadm_t type declaration
 
diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/fsadm.te policy-1.17.20/domains/program/fsadm.te
--- nsapolicy/domains/program/fsadm.te	2004-09-10 10:17:48.000000000 -0400
+++ policy-1.17.20/domains/program/fsadm.te	2004-09-23 09:29:14.470353752 -0400
@@ -49,12 +49,7 @@
 
 type fsadm_exec_t, file_type, sysadmfile, exec_type;
 domain_auto_trans(initrc_t, fsadm_exec_t, fsadm_t)
-ifdef(`unrestricted_admin', `
-allow sysadm_t fixed_disk_device_t:devfile_class_set rw_file_perms;
-allow sysadm_t removable_device_t:devfile_class_set rw_file_perms;
-', `
 domain_auto_trans(sysadm_t, fsadm_exec_t, fsadm_t)
-')
 
 tmp_domain(fsadm)
 
diff --exclude-from=exclude -N -u -r nsapolicy/macros/admin_macros.te policy-1.17.20/macros/admin_macros.te
--- nsapolicy/macros/admin_macros.te	2004-09-21 12:51:06.000000000 -0400
+++ policy-1.17.20/macros/admin_macros.te	2004-09-23 09:28:52.371898273 -0400
@@ -106,14 +106,10 @@
 # allow setting up tunnels
 allow $1_t tun_tap_device_t:chr_file rw_file_perms;
 
-ifdef(`unrestricted_admin', `
-unconfined_domain($1_t) 
-', `
 # run ls -l /dev
 allow $1_t device_t:dir r_dir_perms;
 allow $1_t { device_t device_type }:{ chr_file blk_file } getattr;
 allow $1_t ptyfile:chr_file getattr;
-')
 
 # Run programs from staff home directories.
 # Not ideal, but typical if users want to login as both sysadm_t or staff_t.
diff --exclude-from=exclude -N -u -r nsapolicy/targeted/domains/program/modutil.te policy-1.17.20/targeted/domains/program/modutil.te
--- nsapolicy/targeted/domains/program/modutil.te	1969-12-31 19:00:00.000000000 -0500
+++ policy-1.17.20/targeted/domains/program/modutil.te	2004-09-23 09:26:44.919632619 -0400
@@ -0,0 +1,17 @@
+#DESC Modutil - Dynamic module utilities
+#
+# Authors:  Stephen Smalley <sds@epoch.ncsc.mil> and Timothy Fraser  
+# X-Debian-Packages: modutils
+#
+
+#################################
+#
+# Rules for the module utility domains.
+#
+type modules_dep_t, file_type, sysadmfile;
+type modules_conf_t, file_type, sysadmfile;
+type modules_object_t, file_type, sysadmfile;
+type depmod_exec_t, file_type, exec_type, sysadmfile;
+type insmod_exec_t, file_type, exec_type, sysadmfile;
+type update_modules_exec_t, file_type, exec_type, sysadmfile;
+
diff --exclude-from=exclude -N -u -r nsapolicy/tunables/distro.tun policy-1.17.20/tunables/distro.tun
--- nsapolicy/tunables/distro.tun	2004-09-09 15:36:11.000000000 -0400
+++ policy-1.17.20/tunables/distro.tun	2004-09-23 09:26:44.920632503 -0400
@@ -5,7 +5,7 @@
 # appropriate ifdefs.
 
 
-dnl define(`distro_redhat')
+define(`distro_redhat')
 
 dnl define(`distro_suse')
 
diff --exclude-from=exclude -N -u -r nsapolicy/tunables/tunable.tun policy-1.17.20/tunables/tunable.tun
--- nsapolicy/tunables/tunable.tun	2004-09-23 09:26:36.631594339 -0400
+++ policy-1.17.20/tunables/tunable.tun	2004-09-23 09:27:08.175936391 -0400
@@ -1,51 +1,48 @@
 # Allow all domains to connect to nscd
-dnl define(`nscd_all_connect')
+define(`nscd_all_connect')
 
 # Allow users to control network interfaces (also needs USERCTL=true)
 dnl define(`user_net_control')
 
 # Allow users to execute the mount command
-dnl define(`user_can_mount')
+define(`user_can_mount')
 
 # Allow rpm to run unconfined.
-dnl define(`unlimitedRPM')
+define(`unlimitedRPM')
 
 # Allow privileged utilities like hotplug and insmod to run unconfined.
-dnl define(`unlimitedUtils')
+define(`unlimitedUtils')
 
 # Support NFS home directories
-dnl define(`nfs_home_dirs')
+define(`nfs_home_dirs')
 
 # Allow users to run games
-dnl define(`use_games')
+define(`use_games')
 
 # Allow ypbind to run with NIS
-dnl define(`allow_ypbind')
+define(`allow_ypbind')
 
 # Allow rc scripts to run unconfined, including any daemon
 # started by an rc script that does not have a domain transition
 # explicitly defined.
-dnl define(`unlimitedRC')
+define(`unlimitedRC')
 
 # Allow sysadm_t to directly start daemons
 define(`direct_sysadm_daemon')
 
 # Do not audit things that we know to be broken but which
 # are not security risks
-dnl define(`hide_broken_symptoms')
-
-# Allow sysadm_t to do almost everything
-dnl define(`unrestricted_admin')
+define(`hide_broken_symptoms')
 
 # Allow the read/write/create on any NFS file system
-dnl define(`nfs_export_all_rw')
+define(`nfs_export_all_rw')
 
 # Allow the reading on any NFS file system
 dnl define(`nfs_export_all_ro')
 
 # Allow user_r to reach sysadm_r via su, sudo, or userhelper.
 # Otherwise, only staff_r can do so.
-dnl define(`user_canbe_sysadm')
+define(`user_canbe_sysadm')
 
 # Allow xinetd to run unconfined, including any services it starts
 # that do not have a domain transition explicitly defined.

Re: Remove unrestricted_admin

[James Carter]

Merged.

On Thu, 2004-09-23 at 09:32, Daniel J Walsh wrote:
> Remove unrestricted_admin tunable.  This was a bad idea :^(
> 
> Add modutil for targteted to get relabel to work better.
> 
> 
> ______________________________________________________________________
> diff --exclude-from=exclude -N -u -r nsapolicy/domains/admin.te policy-1.17.20/domains/admin.te
> --- nsapolicy/domains/admin.te	2004-09-09 15:36:12.000000000 -0400
> +++ policy-1.17.20/domains/admin.te	2004-09-23 09:29:42.799096131 -0400
> @@ -4,7 +4,6 @@
>  
>  # sysadm_t is the system administrator domain.
>  type sysadm_t, domain, privlog, privowner, admin, userdomain, web_client_domain, privhome, etc_writer, privmodule, nscd_client_domain
> -ifdef(`unrestricted_admin', `, fs_domain, privmem, sysctl_kernel_writer, auth, auth_write, unrestricted')
>  ifdef(`direct_sysadm_daemon', `, priv_system_role')
>  ; dnl end of sysadm_t type declaration
>  
> diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/fsadm.te policy-1.17.20/domains/program/fsadm.te
> --- nsapolicy/domains/program/fsadm.te	2004-09-10 10:17:48.000000000 -0400
> +++ policy-1.17.20/domains/program/fsadm.te	2004-09-23 09:29:14.470353752 -0400
> @@ -49,12 +49,7 @@
>  
>  type fsadm_exec_t, file_type, sysadmfile, exec_type;
>  domain_auto_trans(initrc_t, fsadm_exec_t, fsadm_t)
> -ifdef(`unrestricted_admin', `
> -allow sysadm_t fixed_disk_device_t:devfile_class_set rw_file_perms;
> -allow sysadm_t removable_device_t:devfile_class_set rw_file_perms;
> -', `
>  domain_auto_trans(sysadm_t, fsadm_exec_t, fsadm_t)
> -')
>  
>  tmp_domain(fsadm)
>  
> diff --exclude-from=exclude -N -u -r nsapolicy/macros/admin_macros.te policy-1.17.20/macros/admin_macros.te
> --- nsapolicy/macros/admin_macros.te	2004-09-21 12:51:06.000000000 -0400
> +++ policy-1.17.20/macros/admin_macros.te	2004-09-23 09:28:52.371898273 -0400
> @@ -106,14 +106,10 @@
>  # allow setting up tunnels
>  allow $1_t tun_tap_device_t:chr_file rw_file_perms;
>  
> -ifdef(`unrestricted_admin', `
> -unconfined_domain($1_t) 
> -', `
>  # run ls -l /dev
>  allow $1_t device_t:dir r_dir_perms;
>  allow $1_t { device_t device_type }:{ chr_file blk_file } getattr;
>  allow $1_t ptyfile:chr_file getattr;
> -')
>  
>  # Run programs from staff home directories.
>  # Not ideal, but typical if users want to login as both sysadm_t or staff_t.
> diff --exclude-from=exclude -N -u -r nsapolicy/targeted/domains/program/modutil.te policy-1.17.20/targeted/domains/program/modutil.te
> --- nsapolicy/targeted/domains/program/modutil.te	1969-12-31 19:00:00.000000000 -0500
> +++ policy-1.17.20/targeted/domains/program/modutil.te	2004-09-23 09:26:44.919632619 -0400
> @@ -0,0 +1,17 @@
> +#DESC Modutil - Dynamic module utilities
> +#
> +# Authors:  Stephen Smalley <sds@epoch.ncsc.mil> and Timothy Fraser  
> +# X-Debian-Packages: modutils
> +#
> +
> +#################################
> +#
> +# Rules for the module utility domains.
> +#
> +type modules_dep_t, file_type, sysadmfile;
> +type modules_conf_t, file_type, sysadmfile;
> +type modules_object_t, file_type, sysadmfile;
> +type depmod_exec_t, file_type, exec_type, sysadmfile;
> +type insmod_exec_t, file_type, exec_type, sysadmfile;
> +type update_modules_exec_t, file_type, exec_type, sysadmfile;
> +
> diff --exclude-from=exclude -N -u -r nsapolicy/tunables/distro.tun policy-1.17.20/tunables/distro.tun
> --- nsapolicy/tunables/distro.tun	2004-09-09 15:36:11.000000000 -0400
> +++ policy-1.17.20/tunables/distro.tun	2004-09-23 09:26:44.920632503 -0400
> @@ -5,7 +5,7 @@
>  # appropriate ifdefs.
>  
> 
> -dnl define(`distro_redhat')
> +define(`distro_redhat')
>  
>  dnl define(`distro_suse')
>  
> diff --exclude-from=exclude -N -u -r nsapolicy/tunables/tunable.tun policy-1.17.20/tunables/tunable.tun
> --- nsapolicy/tunables/tunable.tun	2004-09-23 09:26:36.631594339 -0400
> +++ policy-1.17.20/tunables/tunable.tun	2004-09-23 09:27:08.175936391 -0400
> @@ -1,51 +1,48 @@
>  # Allow all domains to connect to nscd
> -dnl define(`nscd_all_connect')
> +define(`nscd_all_connect')
>  
>  # Allow users to control network interfaces (also needs USERCTL=true)
>  dnl define(`user_net_control')
>  
>  # Allow users to execute the mount command
> -dnl define(`user_can_mount')
> +define(`user_can_mount')
>  
>  # Allow rpm to run unconfined.
> -dnl define(`unlimitedRPM')
> +define(`unlimitedRPM')
>  
>  # Allow privileged utilities like hotplug and insmod to run unconfined.
> -dnl define(`unlimitedUtils')
> +define(`unlimitedUtils')
>  
>  # Support NFS home directories
> -dnl define(`nfs_home_dirs')
> +define(`nfs_home_dirs')
>  
>  # Allow users to run games
> -dnl define(`use_games')
> +define(`use_games')
>  
>  # Allow ypbind to run with NIS
> -dnl define(`allow_ypbind')
> +define(`allow_ypbind')
>  
>  # Allow rc scripts to run unconfined, including any daemon
>  # started by an rc script that does not have a domain transition
>  # explicitly defined.
> -dnl define(`unlimitedRC')
> +define(`unlimitedRC')
>  
>  # Allow sysadm_t to directly start daemons
>  define(`direct_sysadm_daemon')
>  
>  # Do not audit things that we know to be broken but which
>  # are not security risks
> -dnl define(`hide_broken_symptoms')
> -
> -# Allow sysadm_t to do almost everything
> -dnl define(`unrestricted_admin')
> +define(`hide_broken_symptoms')
>  
>  # Allow the read/write/create on any NFS file system
> -dnl define(`nfs_export_all_rw')
> +define(`nfs_export_all_rw')
>  
>  # Allow the reading on any NFS file system
>  dnl define(`nfs_export_all_ro')
>  
>  # Allow user_r to reach sysadm_r via su, sudo, or userhelper.
>  # Otherwise, only staff_r can do so.
> -dnl define(`user_canbe_sysadm')
> +define(`user_canbe_sysadm')
>  
>  # Allow xinetd to run unconfined, including any services it starts
>  # that do not have a domain transition explicitly defined.
-- 
James Carter <jwcart2@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: Remove unrestricted_admin

[Russell Coker]

On Thu, 23 Sep 2004 23:32, Daniel J Walsh <dwalsh@redhat.com> wrote:
> Remove unrestricted_admin tunable.  This was a bad idea :^(

-allow sysadm_t fixed_disk_device_t:devfile_class_set rw_file_perms;

I think that perhaps we should add that line back.

Of the times that I temporarily enable permissive mode to execute a command, 
in 99% of them it's because of access to a fixed disk.

-- 
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: Remove unrestricted_admin

[Christopher J. PeBenito]

On Sat, 2004-09-25 at 01:05 +1000, Russell Coker wrote:
> -allow sysadm_t fixed_disk_device_t:devfile_class_set rw_file_perms;
> 
> I think that perhaps we should add that line back.
> 
> Of the times that I temporarily enable permissive mode to execute a command, 
> in 99% of them it's because of access to a fixed disk.

Why would you need to directly access the disk as sysadm_t?  All the
applicable tools should be transitioning to fsadm_t.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150



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

Re: Remove unrestricted_admin

[Russell Coker]

On Sat, 25 Sep 2004 03:50, "Christopher J. PeBenito" <cpebenito@tresys.com> 
wrote:
> On Sat, 2004-09-25 at 01:05 +1000, Russell Coker wrote:
> > -allow sysadm_t fixed_disk_device_t:devfile_class_set rw_file_perms;
> >
> > I think that perhaps we should add that line back.
> >
> > Of the times that I temporarily enable permissive mode to execute a
> > command, in 99% of them it's because of access to a fixed disk.
>
> Why would you need to directly access the disk as sysadm_t?  All the
> applicable tools should be transitioning to fsadm_t.

dd if=/dev/hda of=/dev/hdb

file -s /dev/hda

Using an LVM snapshot to backup a disk onto a DVD.

-- 
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: Remove unrestricted_admin

[Joshua Brindle]

Russell Coker wrote:

> On Thu, 23 Sep 2004 23:32, Daniel J Walsh <dwalsh@redhat.com> wrote:
> 
>>Remove unrestricted_admin tunable.  This was a bad idea :^(
> 
> 
> -allow sysadm_t fixed_disk_device_t:devfile_class_set rw_file_perms;
> 
> I think that perhaps we should add that line back.
> 
> Of the times that I temporarily enable permissive mode to execute a command, 
> in 99% of them it's because of access to a fixed disk.
> 

*ahem* non-bypassability anyone?

The strict policy is suppose to be getting stricter, this corner case 
shouldn't be considered at all.

Joshua Brindle

--
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: Remove unrestricted_admin

[Christopher J. PeBenito]

On Sat, 2004-09-25 at 04:27 +1000, Russell Coker wrote:
> On Sat, 25 Sep 2004 03:50, "Christopher J. PeBenito" <cpebenito@tresys.com> 
> wrote:
> > On Sat, 2004-09-25 at 01:05 +1000, Russell Coker wrote:
> > > -allow sysadm_t fixed_disk_device_t:devfile_class_set rw_file_perms;
> > >
> > > I think that perhaps we should add that line back.
> > >
> > > Of the times that I temporarily enable permissive mode to execute a
> > > command, in 99% of them it's because of access to a fixed disk.
> >
> > Why would you need to directly access the disk as sysadm_t?  All the
> > applicable tools should be transitioning to fsadm_t.
> 
> dd if=/dev/hda of=/dev/hdb
> 
> file -s /dev/hda
> 
> Using an LVM snapshot to backup a disk onto a DVD.

Yes these are reasons; however, this is supposed to be the strict
policy, and these are not compelling enough to loosen the policy this
way, in my opinion. 

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150



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

Re: Remove unrestricted_admin

[Russell Coker]

On Sat, 25 Sep 2004 04:59, "Christopher J. PeBenito" <cpebenito@tresys.com> 
wrote:
> > > Why would you need to directly access the disk as sysadm_t?  All the
> > > applicable tools should be transitioning to fsadm_t.
> >
> > dd if=/dev/hda of=/dev/hdb
> >
> > file -s /dev/hda
> >
> > Using an LVM snapshot to backup a disk onto a DVD.
>
> Yes these are reasons; however, this is supposed to be the strict
> policy, and these are not compelling enough to loosen the policy this
> way, in my opinion.

How do you suggest that we address those needs then?

-- 
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: Remove unrestricted_admin

[Luke Kenneth Casson Leighton]

On Sat, Sep 25, 2004 at 05:13:29AM +1000, Russell Coker wrote:
> On Sat, 25 Sep 2004 04:59, "Christopher J. PeBenito" <cpebenito@tresys.com> 
> wrote:
> > > > Why would you need to directly access the disk as sysadm_t?  All the
> > > > applicable tools should be transitioning to fsadm_t.
> > >
> > > dd if=/dev/hda of=/dev/hdb
> > >
> > > file -s /dev/hda
> > >
> > > Using an LVM snapshot to backup a disk onto a DVD.
> >
> > Yes these are reasons; however, this is supposed to be the strict
> > policy, and these are not compelling enough to loosen the policy this
> > way, in my opinion.
> 
> How do you suggest that we address those needs then?
 
 write a small program that does the job, add it to fsadm_t?
 [or is that too obvious an answer]

--
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: Remove unrestricted_admin

[Russell Coker]

On Sat, 25 Sep 2004 08:22, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > > > dd if=/dev/hda of=/dev/hdb
> > > >
> > > > file -s /dev/hda
> > > >
> > > > Using an LVM snapshot to backup a disk onto a DVD.
> > >
> > > Yes these are reasons; however, this is supposed to be the strict
> > > policy, and these are not compelling enough to loosen the policy this
> > > way, in my opinion.
> >
> > How do you suggest that we address those needs then?
>
>  write a small program that does the job, add it to fsadm_t?
>  [or is that too obvious an answer]

So you are saying we should write special programs to copy block devices to 
other block devices, to/from DVD, copying raw partition tables, and all the 
other things that administrators usually do?  I don't think that is viable.

One possibility is to run things in fsadm_t, this means that fsadm_t needs a 
heap of extra access which probably isn't desired.

Another possibility is to have multiple domains in the sysadm_r role, only one 
of which has such privs and then have the administrator use runcon to perform 
such tasks.

-- 
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: Remove unrestricted_admin

[Luke Kenneth Casson Leighton]

On Sat, Sep 25, 2004 at 08:39:01PM +1000, Russell Coker wrote:

> > > How do you suggest that we address those needs then?
> >
> >  write a small program that does the job, add it to fsadm_t?
> >  [or is that too obvious an answer]
> 
> So you are saying we should write special programs to copy block devices to 
> other block devices, to/from DVD, copying raw partition tables, and all the 
> other things that administrators usually do?  

 hah, i walked into that one :)

 btw i _have_ written a policy for cdrecord, if anyone's interested.

 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: Remove unrestricted_admin

[Christopher J. PeBenito]

On Sat, 2004-09-25 at 20:39 +1000, Russell Coker wrote:
> On Sat, 25 Sep 2004 08:22, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > > > > dd if=/dev/hda of=/dev/hdb
> > > > >
> > > > > file -s /dev/hda
> > > > >
> > > > > Using an LVM snapshot to backup a disk onto a DVD.
> > > >
> > > > Yes these are reasons; however, this is supposed to be the strict
> > > > policy, and these are not compelling enough to loosen the policy this
> > > > way, in my opinion.
> > >
> > > How do you suggest that we address those needs then?
> >
> >  write a small program that does the job, add it to fsadm_t?
> >  [or is that too obvious an answer]
> 
> So you are saying we should write special programs to copy block devices to 
> other block devices, to/from DVD, copying raw partition tables, and all the 
> other things that administrators usually do?  I don't think that is viable.

I still believe that the first two are more like corner cases.  I see it
much more likely that an admin would be using a regular backup solution
with tapes and autoloaders (bigger systems) and the like for backups
with tools seem to be fit for backup_t or similar domain.

I believe that the corner cases should be left broken, as it loosens the
strict policy too much.

> One possibility is to run things in fsadm_t, this means that fsadm_t needs a 
> heap of extra access which probably isn't desired.

Since I'm not familiar with LVM, I'm curious as to why doing a snapshot
doesn't fit into a domain of its own or fsadm_t.

> Another possibility is to have multiple domains in the sysadm_r role, only one 
> of which has such privs and then have the administrator use runcon to perform 
> such tasks.

Well we'd probably want the binaries to be specifically labeled to
control the entrypoint, but if we do that, then domain_auto_trans() will
work.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


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

Re: Remove unrestricted_admin

[Russell Coker]

On Sat, 25 Sep 2004 23:30, "Christopher J. PeBenito" <cpebenito@tresys.com> 
wrote:
> > So you are saying we should write special programs to copy block devices
> > to other block devices, to/from DVD, copying raw partition tables, and
> > all the other things that administrators usually do?  I don't think that
> > is viable.
>
> I still believe that the first two are more like corner cases.  I see it

Corner cases that happen to be a regular part of any sys-admin's job.

Post to any sys-admin mailing list and ask the subscribers how they would like 
a security system that prevents them from copying a block device to a file on 
a larger file system or that prevents them from using dd to copy one block 
device to another.  You will not get a positive response.

> much more likely that an admin would be using a regular backup solution
> with tapes and autoloaders (bigger systems) and the like for backups
> with tools seem to be fit for backup_t or similar domain.

Tapes and auto-loaders don't make these problems go away.

> > One possibility is to run things in fsadm_t, this means that fsadm_t
> > needs a heap of extra access which probably isn't desired.
>
> Since I'm not familiar with LVM, I'm curious as to why doing a snapshot
> doesn't fit into a domain of its own or fsadm_t.

The snapshot device is just like any other fixed disk device.  To use it for a 
backup you need a process that has permissions to read it and to write to 
wherever the backup may be stored.  We could allow backup_t to read 
fixed_disk_device_t for this case.

-- 
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: Remove unrestricted_admin

[Chris PeBenito]

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

On Sun, 2004-09-26 at 01:21 +1000, Russell Coker wrote:
> On Sat, 25 Sep 2004 23:30, "Christopher J. PeBenito" <cpebenito@tresys.com> 
> wrote:

> > much more likely that an admin would be using a regular backup solution
> > with tapes and autoloaders (bigger systems) and the like for backups
> > with tools seem to be fit for backup_t or similar domain.
> 
> Tapes and auto-loaders don't make these problems go away.

They're more likely to use backup software to run it, which is what I
meant, then it will be using a program that can be put in its own domain
to do its work.  Raw access could be added to that domain if needed.

> > Since I'm not familiar with LVM, I'm curious as to why doing a snapshot
> > doesn't fit into a domain of its own or fsadm_t.
> 
> The snapshot device is just like any other fixed disk device.  To use it for a 
> backup you need a process that has permissions to read it and to write to 
> wherever the backup may be stored.  We could allow backup_t to read 
> fixed_disk_device_t for this case.

Does this not require a program to do a snapshotting?  If it does, why
does it not fit in its own domain?

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer,
Hardened Gentoo Linux
Embedded Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Remove unrestricted_admin

[Russell Coker]

On Sun, 26 Sep 2004 03:09, Chris PeBenito <pebenito@gentoo.org> wrote:
> > > much more likely that an admin would be using a regular backup solution
> > > with tapes and autoloaders (bigger systems) and the like for backups
> > > with tools seem to be fit for backup_t or similar domain.
> >
> > Tapes and auto-loaders don't make these problems go away.
>
> They're more likely to use backup software to run it, which is what I
> meant, then it will be using a program that can be put in its own domain
> to do its work.  Raw access could be added to that domain if needed.

So every time you add a new disk and want to migrate a file system you use a 
backup program instead of dd?

> > > Since I'm not familiar with LVM, I'm curious as to why doing a snapshot
> > > doesn't fit into a domain of its own or fsadm_t.
> >
> > The snapshot device is just like any other fixed disk device.  To use it
> > for a backup you need a process that has permissions to read it and to
> > write to wherever the backup may be stored.  We could allow backup_t to
> > read fixed_disk_device_t for this case.
>
> Does this not require a program to do a snapshotting?  If it does, why
> does it not fit in its own domain?

lvm creates the snapshot which looks just like any other block device to the 
system.  Then something else has to access 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: Remove unrestricted_admin

[Dale Amon]

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

On Sun, Sep 26, 2004 at 01:21:10AM +1000, Russell Coker wrote:
> Corner cases that happen to be a regular part of any sys-admin's job.

I massively agree. Lots of people do 'ghosting'; lots
of people back up entire disk images before doing
something dangerous. Now I've got ways around a lot
of the problems anyway because I've a root boot floppy
I use. Boot a machine off an nfs root; mount a Real Big
Disk over nfs, and then dd the whole frigging host
system disk to the destination system where it
can be worked on. 

Although it is not my primary use for this (mostly I
do R&D), think forensics too. Think of all the various
tools in use for setting up a master image and dupping
it to N other machines.

Also, dd with a decent block speed is an awesomely 
fast way to back up a disk.

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

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

Re: Remove unrestricted_admin

[Joe Nall]

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


On Sep 24, 2004, at 1:59 PM, Christopher J. PeBenito wrote:

> On Sat, 2004-09-25 at 04:27 +1000, Russell Coker wrote:
>> On Sat, 25 Sep 2004 03:50, "Christopher J. PeBenito" 
>> <cpebenito@tresys.com>
>> wrote:
>>> On Sat, 2004-09-25 at 01:05 +1000, Russell Coker wrote:
>>>> -allow sysadm_t fixed_disk_device_t:devfile_class_set rw_file_perms;
>>>>
>>>> I think that perhaps we should add that line back.
>>>>
>>>> Of the times that I temporarily enable permissive mode to execute a
>>>> command, in 99% of them it's because of access to a fixed disk.
>>>
>>> Why would you need to directly access the disk as sysadm_t?  All the
>>> applicable tools should be transitioning to fsadm_t.
>>
>> dd if=/dev/hda of=/dev/hdb
>>
>> file -s /dev/hda
>>
>> Using an LVM snapshot to backup a disk onto a DVD.
>
> Yes these are reasons; however, this is supposed to be the strict
> policy, and these are not compelling enough to loosen the policy this
> way, in my opinion.

dd has other options (seek, skip, count) that allow arbitrary editing of
a raw disk. If you can dd (or write in general) the root raw disk 
partition,
you can do anything.

joe


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2353 bytes --]

Re: Remove unrestricted_admin

[Joshua Brindle]

Dale Amon wrote:

>On Sun, Sep 26, 2004 at 01:21:10AM +1000, Russell Coker wrote:
>  
>
>>Corner cases that happen to be a regular part of any sys-admin's job.
>>    
>>
>
>I massively agree. Lots of people do 'ghosting'; lots
>of people back up entire disk images before doing
>something dangerous. Now I've got ways around a lot
>of the problems anyway because I've a root boot floppy
>I use. Boot a machine off an nfs root; mount a Real Big
>Disk over nfs, and then dd the whole frigging host
>system disk to the destination system where it
>can be worked on. 
>
>Although it is not my primary use for this (mostly I
>do R&D), think forensics too. Think of all the various
>tools in use for setting up a master image and dupping
>it to N other machines.
>
>Also, dd with a decent block speed is an awesomely 
>fast way to back up a disk.
>
>  
>
I _really_ hope you aren't suggesting that you do a dd from a host disk 
to something else while a machine is in production. This _will_ lead to 
an inconsistant image and I don't think I need to explain why.

This corner case shouldn't determine what is in the default policy, but 
I'm not even sure that is what we are talking about here, Russell never 
said how he wants this implemented (keep the unrestricted_admin macro or 
put that unrestricted fixed disk access in the standard policy. At any 
rate, I hope very much that noone expects or desires that this be put in 
unconditionally. Raw disk access is a very obvious attack vector and 
must be treated as such, period.

Again, these backup kinds of activities are always privileged and thus 
need to be in a domain where they can do only backup procedures, whether 
that be reading the on-disk files (preferable and correct if you use 
real backup software) or raw disk access.


Joshua Brindle

--
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: Remove unrestricted_admin

[Dale Amon]

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

On Sat, Sep 25, 2004 at 08:13:33PM -0400, Joshua Brindle wrote:
> I _really_ hope you aren't suggesting that you do a dd from a host disk 
> to something else while a machine is in production. This _will_ lead to 
> an inconsistant image and I don't think I need to explain why.

No, I umount the partition first. For system disks
I do the backup as described, with a root-nfs floppy
boot.

Last year I recovered data off a badly bolloxed Thinkpad
disk after someone knocked my laptop off a sofa while
I was travelling for several months. Lots of work had
to be recovered. I used the ability to seek to pull
all the undamaged blocks off and step around the 
blocks which locked up the IDE controller; then I
used a program to reassemble the saved blocks in
order with zero blocks where the destroyed areas
were... and then I loopback mounted the result and
recovered about 99.999%. Actually I recoverd 100%
of what matters.

Since I did this with an NFS boot, it doesn't 
matter to selinux (hell, last spring I was building
selinux into a ghost loopback and then dd'ing it to
the very slow test machines; only the
issue of umount/dd backup/mount of partitions matters
in general usage.

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

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

Re: Remove unrestricted_admin

[Russell Coker]

On Sun, 26 Sep 2004 10:13, Joshua Brindle <jbrindle@tresys.com> wrote:
> I _really_ hope you aren't suggesting that you do a dd from a host disk
> to something else while a machine is in production. This _will_ lead to
> an inconsistant image and I don't think I need to explain why.

Unless you use LVM snapshots or a split RAID-1.

> This corner case shouldn't determine what is in the default policy, but
> I'm not even sure that is what we are talking about here, Russell never
> said how he wants this implemented (keep the unrestricted_admin macro or
> put that unrestricted fixed disk access in the standard policy. At any
> rate, I hope very much that noone expects or desires that this be put in
> unconditionally. Raw disk access is a very obvious attack vector and
> must be treated as such, period.

Restrictions don't matter that much to any domain which can do
"echo 0 > /selinux/enforce".

-- 
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: Remove unrestricted_admin

[Luke Kenneth Casson Leighton]

On Sat, Sep 25, 2004 at 11:07:08PM +0100, Dale Amon wrote:
> On Sun, Sep 26, 2004 at 01:21:10AM +1000, Russell Coker wrote:
> > Corner cases that happen to be a regular part of any sys-admin's job.
> 
> I massively agree. Lots of people do 'ghosting'; lots
> of people back up entire disk images before doing
> something dangerous. Now I've got ways around a lot
> of the problems anyway because I've a root boot floppy
> I use. Boot a machine off an nfs root; mount a Real Big
> Disk over nfs, and then dd the whole frigging host
> system disk to the destination system where it
> can be worked on. 

 i'm doing something similar using rsync to do backups and restores
 (i did use dd but had to save space).

 it's a boot cd, and on a restore it runs in "permissive" mode,
 sets up the partitions on /target/, /target/boot, /target/var etc.
 chroots to /target and then does a make -C /etc/selinux/src relabel.

 that seems to "do the job".

 i am certain that lots of people can come up with alternative schemes,
 all of which will work "offline" where you have physical access to the
 machine.

 what i believe russell to be concerned about is that there _are_ so
 many "alternative" schemes that people use [during live operation]
 e.g. _yes_ people really do do "dd backups" usually at 3am on a cron
 job to a spare disk.

 therefore, making a decision about, how do we say "which
 one(s)" - if at all - should go into the "strict" policy is
 of some concern.

 ...if this was microsoft, you'd write your own backup program and then
 lock the OS to that.

 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: Remove unrestricted_admin

[Russell Coker]

On Sun, 26 Sep 2004 09:06, Joe Nall <joe@nall.com> wrote:
> > Yes these are reasons; however, this is supposed to be the strict
> > policy, and these are not compelling enough to loosen the policy this
> > way, in my opinion.
>
> dd has other options (seek, skip, count) that allow arbitrary editing of
> a raw disk. If you can dd (or write in general) the root raw disk
> partition,
> you can do anything.

If you can put SE Linux in permissive mode (as sysadm_t can) then as far as SE 
Linux is concerned you can do anything.

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