Ask for comments about some patches for refpolicy-2.20091117

Ask for comments about some patches for refpolicy-2.20091117

[TaurusHarry]

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


Hi SELinux experts,

I have come up with some patches for the latest refpolicy-2.20091117 and would like to ask for opinions about whether they make sense or not. 

Please help review when convenient, any comment is greatly welcomed!

Best regards,
Harry
 		 	   		  
_________________________________________________________________
Windows Live社区两周年，拿奖过新年！
http://events.livetome.cn/2010/2birthday

[-- Attachment #1.2: Type: text/html, Size: 620 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: refpolicy-strict-crond_t-domtrans-hostname.patch --]
[-- Type: text/x-diff, Size: 1519 bytes --]

crond_t would require necessary privilege to execute the /bin/hostname 
program, otherwise we will run into below error messages during system boots up:

type=1400 audit(1264604461.360:50): avc:  denied  { getattr } for  pid=2435 comm="logcheck.sh" path="/bin/hostname" dev=sda1 ino=73500 scontext=system_u:system_r:crond_t:s0-s15:c0.c255 tcontext=system_u:object_r:hostname_exec_t:s0 tclass=file
type=1400 audit(1264604461.407:51): avc:  denied  { execute } for  pid=2435 comm="logcheck.sh" name="hostname" dev=sda1 ino=73500 scontext=system_u:system_r:crond_t:s0-s15:c0.c255 tcontext=system_u:object_r:hostname_exec_t:s0 tclass=file
type=1400 audit(1264604461.453:52): avc:  denied  { read } for  pid=2435 comm="logcheck.sh" name="hostname" dev=sda1 ino=73500 scontext=system_u:system_r:crond_t:s0-s15:c0.c255 tcontext=system_u:object_r:hostname_exec_t:s0 tclass=file
type=1400 audit(1264604461.499:53): avc:  denied  { open } for  pid=2435 comm="logcheck.sh" name="hostname" dev=sda1 ino=73500 scontext=system_u:system_r:crond_t:s0-s15:c0.c255 tcontext=system_u:object_r:hostname_exec_t:s0 tclass=file

Signed-off-by: Harry Ciao<qingtao.cao@windriver.com>
---
 policy/modules/services/cron.te |    2 ++
 1 file changed, 2 insertions(+)

--- a/policy/modules/services/cron.te
+++ b/policy/modules/services/cron.te
@@ -229,6 +229,8 @@ userdom_list_user_home_dirs(crond_t)
 
 mta_send_mail(crond_t)
 
+hostname_domtrans(crond_t)
+
 ifdef(`distro_debian',`
 	# pam_limits is used
 	allow crond_t self:process setrlimit;

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: refpolicy-strict-crond_t-manipulate-bin.patch --]
[-- Type: text/x-diff, Size: 1979 bytes --]

crond_t would require necessary privilege to manage and execute bin_t files,
otherwise we will run into below error messages during system boots up:

type=1400 audit(1264604461.068:44): avc:  denied  { getattr } for  pid=2429 comm="bash" path="/usr/bin/run-parts" dev=sda1 ino=115396 scontext=system_u:system_r:crond_t:s0-s15:c0.c255 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=1400 audit(1264604461.114:45): avc:  denied  { execute } for  pid=2429 comm="bash" name="run-parts" dev=sda1 ino=115396 scontext=system_u:system_r:crond_t:s0-s15:c0.c255 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=1400 audit(1264604461.159:46): avc:  denied  { read } for  pid=2429 comm="bash" name="run-parts" dev=sda1 ino=115396 scontext=system_u:system_r:crond_t:s0-s15:c0.c255 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=1400 audit(1264604461.203:47): avc:  denied  { open } for  pid=2429 comm="bash" name="run-parts" dev=sda1 ino=115396 scontext=system_u:system_r:crond_t:s0-s15:c0.c255 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=1400 audit(1264604461.248:48): avc:  denied  { execute_no_trans } for  pid=2429 comm="bash" path="/usr/bin/run-parts" dev=sda1 ino=115396 scontext=system_u:system_r:crond_t:s0-s15:c0.c255 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=1400 audit(1264604461.296:49): avc:  denied  { ioctl } for  pid=2429 comm="run-parts" path="/usr/bin/run-parts" dev=sda1 ino=115396 scontext=system_u:system_r:crond_t:s0-s15:c0.c255 tcontext=system_u:object_r:bin_t:s0 tclass=file

Signed-off-by: Harry Ciao<qingtao.cao@windriver.com>
---
 policy/modules/services/cron.te |    3 ++
 1 file changed, 3 insertions(+)

--- a/policy/modules/services/cron.te
+++ b/policy/modules/services/cron.te
@@ -195,6 +195,9 @@ corecmd_exec_shell(crond_t)
 corecmd_list_bin(crond_t)
 corecmd_read_bin_symlinks(crond_t)
 
+corecmd_exec_bin(crond_t)
+corecmd_manage_bin_files(crond_t)
+
 domain_use_interactive_fds(crond_t)
 
 files_read_usr_files(crond_t)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: refpolicy-strict-dontaudit-quota_t-mmap_zero.patch --]
[-- Type: text/x-diff, Size: 1018 bytes --]

quotaon will try to mmap a low area of the address space, which is explicitly
prohibited by the neverallow rule defined in kernel/domain.te:

neverallow { domain -mmap_low_domain_type } self:memprotect mmap_zero;

So we use a dontaudit rule here to suppress below error message:

type=1400 audit(1263999798.212:5): avc:  denied  { mmap_zero } for  pid=2011 comm="quotaon" scontext=system_u:system_r:quota_t:s0-s15:c0.c255 tcontext=system_u:system_r:quota_t:s0-s15:c0.c255 tclass=memprotect

Signed-off-by: Harry Ciao<qingtao.cao@windriver.com>
---
 policy/modules/admin/quota.te |    1 +
 1 file changed, 1 insertion(+)

--- a/policy/modules/admin/quota.te
+++ b/policy/modules/admin/quota.te
@@ -24,6 +24,7 @@ files_type(quota_flag_t)
 allow quota_t self:capability { sys_admin dac_override };
 dontaudit quota_t self:capability sys_tty_config;
 allow quota_t self:process signal_perms;
+dontaudit quota_t self:memprotect { mmap_zero} ;
 
 # for /quota.*
 allow quota_t quota_db_t:file { manage_file_perms quotaon };

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: refpolicy-strict-getty_t-use-console.patch --]
[-- Type: text/x-diff, Size: 1985 bytes --]

If /sbin/init is to run mingetty against console rather than any tty device such as:
0:2345:respawn:/sbin/mingetty console
#1:2345:respawn:/sbin/mingetty tty1
#2:2345:respawn:/sbin/mingetty tty2
#3:2345:respawn:/sbin/mingetty tty3
#4:2345:respawn:/sbin/mingetty tty4
#5:2345:respawn:/sbin/mingetty tty5
#6:2345:respawn:/sbin/mingetty tty6

Where "console=ttyS0, 115200n8" or the like is specified in kernel bootparams.
This  would require getty_t having necessary privilege in order to use the console.
Otherwise /sbin/mingetty will fail to domain transition to local_login_t
and /sbin/init will end up respawning /sbin/mingetty forever:

INIT: Id "0" respawning too fast: disabled for 5 minutes
INIT: no more processes left in this runlevel
INIT: Id "0" respawning too fast: disabled for 5 minutes
...(repeated)...

If we remove the "term_dontaudit_use_console(getty_t)", we can see the reason
why /sbin/mingetty fails to execuate /bin/login:

type=1400 audit(1264520547.936:68): avc:  denied  { noatsecure } for  pid=2292 comm="login" scontext=system_u:system_r:getty_t:s0-s15:c0.c255 tcontext=system_u:system_r:local_login_t:s0-s15:c0.c255 tclass=process

For system that needs loging in through serial console, the term_use_console() 
interface should be called for the getty_t domain. However, please do note that
/dev/console is not regarded as a secure device and many domains won't have even
the read permission against it, so please remember to log in from ssh after system
properly boots up.

Signed-off-by: Harry Ciao<qingtao.cao@windriver.com>
---
 policy/modules/system/getty.te |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/policy/modules/system/getty.te
+++ b/policy/modules/system/getty.te
@@ -86,7 +86,7 @@ term_use_unallocated_ttys(getty_t)
 term_setattr_all_user_ttys(getty_t)
 term_setattr_unallocated_ttys(getty_t)
 term_setattr_console(getty_t)
-term_dontaudit_use_console(getty_t)
+term_use_console(getty_t)
 
 auth_rw_login_records(getty_t)
 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #6: refpolicy-strict-initrc_t-create-fixed-disk.patch --]
[-- Type: text/x-diff, Size: 1209 bytes --]

initrc_t would require necessary privilege to create /dev/loop*, otherwise
we will run into below error message during system boots up:

type=1400 audit(1264337970.536:5): avc:  denied  { create } for  pid=1012 comm="MAKEDEV" name="loop0-" scontext=system_u:system_r:initrc_t:s0-s15:c0.c255 tcontext=system_u:object_r:fixed_disk_device_t:s15:c0.c255 tclass=blk_file

Note, the security label of /dev/loop* is s15 whereas initrc_t is s0, so we
have to grant mls_file_upgrade() privilege for it too.

Signed-off-by: Harry Ciao<qingtao.cao@windriver.com>
---
 policy/modules/system/init.te |    2 ++
 1 file changed, 2 insertions(+)

--- a/policy/modules/system/init.te
+++ b/policy/modules/system/init.te
@@ -345,6 +345,7 @@ mls_process_read_up(initrc_t)
 mls_process_write_down(initrc_t)
 mls_rangetrans_source(initrc_t)
 mls_fd_share_all_levels(initrc_t)
+mls_file_upgrade(initrc_t)
 
 selinux_get_enforce_mode(initrc_t)
 
@@ -477,6 +478,7 @@ ifdef(`distro_redhat',`
 	storage_manage_fixed_disk(initrc_t)
 	storage_dev_filetrans_fixed_disk(initrc_t)
 	storage_getattr_removable_dev(initrc_t)
+	storage_tmpfs_filetrans_fixed_disk(initrc_t)
 
 	# readahead asks for these
 	auth_dontaudit_read_shadow(initrc_t)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #7: refpolicy-strict-insmod_t-use-console.patch --]
[-- Type: text/x-diff, Size: 805 bytes --]

insmod_t would require necessary privilege to operate /dev/console, otherwise
during boot up modprobe would throw out many error messages such as:

type=1400 audit(1263731962.260:4): avc:  denied  { read } for  pid=960 comm="modprobe" name="console" dev=sda1 ino=244841 scontext=system_u:system_r:insmod_t:s0-s15:c0.c255 tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file

Signed-off-by: Harry Ciao<qingtao.cao@windriver.com>
---
 policy/modules/system/modutils.te |    2 ++
 1 file changed, 2 insertions(+)

--- a/policy/modules/system/modutils.te
+++ b/policy/modules/system/modutils.te
@@ -159,6 +159,8 @@ seutil_read_file_contexts(insmod_t)
 
 userdom_use_user_terminals(insmod_t)
 
+term_use_console(insmod_t)
+
 ifdef(`distro_ubuntu',`
 	optional_policy(`
 		unconfined_domain(insmod_t)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #8: refpolicy-strict-mount_t-manipulate-generic-locks.patch --]
[-- Type: text/x-diff, Size: 2461 bytes --]

The mount_t domain should have enough privilege to create the lock file in
/var/lock, otherwise we will run into below error messages during boot up:

Mounting other filesystems:  
mount: sysfs already mounted or /sys busy
mount: devpts already mounted or /dev/pts busy
can't create lock file /var/lock/mtab~2158: Permission denied (use -n flag to override)

type=1400 audit(1263998153.228:7): avc:  denied  { write } for  pid=2006 comm="mount" name="lock" dev=sda1 ino=318296 scontext=system_u:system_r:mount_t:s0-s15:c0.c255 tcontext=system_u:object_r:var_lock_t:s0 tclass=dir
type=1400 audit(1263998153.228:8): avc:  denied  { add_name } for  pid=2006 comm="mount" name="mtab~2006" scontext=system_u:system_r:mount_t:s0-s15:c0.c255 tcontext=system_u:object_r:var_lock_t:s0 tclass=dir
type=1400 audit(1263998153.228:9): avc:  denied  { create } for  pid=2006 comm="mount" name="mtab~2006" scontext=system_u:system_r:mount_t:s0-s15:c0.c255 tcontext=system_u:object_r:var_lock_t:s0 tclass=file
type=1400 audit(1263998153.232:10): avc:  denied  { write open } for  pid=2006 comm="mount" name="mtab~2006" dev=sda1 ino=318422 scontext=system_u:system_r:mount_t:s0-s15:c0.c255 tcontext=system_u:object_r:var_lock_t:s0 tclass=file
type=1400 audit(1263998153.232:11): avc:  denied  { link } for  pid=2006 comm="mount" name="mtab~2006" dev=sda1 ino=318422 scontext=system_u:system_r:mount_t:s0-s15:c0.c255 tcontext=system_u:object_r:var_lock_t:s0 tclass=file
type=1400 audit(1263998153.232:12): avc:  denied  { lock } for  pid=2006 comm="mount" path="/var/lock/mtab~" dev=sda1 ino=318422 scontext=system_u:system_r:mount_t:s0-s15:c0.c255 tcontext=system_u:object_r:var_lock_t:s0 tclass=file
type=1400 audit(1263998153.232:13): avc:  denied  { remove_name } for  pid=2006 comm="mount" name="mtab~2006" dev=sda1 ino=318422 scontext=system_u:system_r:mount_t:s0-s15:c0.c255 tcontext=system_u:object_r:var_lock_t:s0 tclass=dir

From above AVC denied messages we can see that mount_t should have the ability
to manage var_lock_t.

Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
---
 policy/modules/system/mount.te |    2 +++
 1 file changed, 2 insertions(+)

--- a/policy/modules/system/mount.te
+++ b/policy/modules/system/mount.te
@@ -80,6 +80,8 @@ files_read_isid_type_files(mount_t)
 files_read_usr_files(mount_t)
 files_list_mnt(mount_t)
 
+files_manage_generic_locks(mount_t)
+
 fs_getattr_xattr_fs(mount_t)
 fs_getattr_cifs(mount_t)
 fs_mount_all_fs(mount_t)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #9: refpolicy-strict-newrole_t-use-console.patch --]
[-- Type: text/x-diff, Size: 845 bytes --]

We should grant newrole_t enough privilege to use and relabel the /dev/console
if we want to use newrole after logging in from serial console.

However, if you never logs in from console but on tty or through ssh then this patch
is not needed.

Signed-off-by: Harry Ciao<qingtao.cao@windriver.com>
---
 policy/modules/system/selinuxutil.te      |    3 ++
 1 files changed, 3 insertions(+)

--- a/policy/modules/system/selinuxutil.te
+++ b/policy/modules/system/selinuxutil.te
@@ -260,6 +260,9 @@ term_relabel_all_user_ttys(newrole_t)
 term_relabel_all_user_ptys(newrole_t)
 term_getattr_unallocated_ttys(newrole_t)
 term_dontaudit_use_unallocated_ttys(newrole_t)
+# allow newrole_t to use and relabel /dev/console
+term_use_console(newrole_t)
+term_relabel_console(newrole_t)
 
 auth_use_nsswitch(newrole_t)
 auth_domtrans_chk_passwd(newrole_t)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #10: refpolicy-strict-root-dir-label.patch --]
[-- Type: text/x-diff, Size: 633 bytes --]

Explicitly specify the security context for /root directory to avoid 
it being labeled as default_t.

Signed-off-by: Harry Ciao<qingtao.cao@windriver.com>
---
 policy/modules/system/userdomain.fc |    4 ++++
 1 file changed, 4 insertions(+)

--- a/policy/modules/system/userdomain.fc
+++ b/policy/modules/system/userdomain.fc
@@ -2,3 +2,7 @@ HOME_DIR	-d	gen_context(system_u:object_
 HOME_DIR/.+		gen_context(system_u:object_r:user_home_t,s0)
 
 /tmp/gconfd-USER -d	gen_context(system_u:object_r:user_tmp_t,s0)
+
+/root		-d	gen_context(system_u:object_r:user_home_dir_t,s0)
+/root/.+		gen_context(system_u:object_r:user_home_t,s0)
+

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #11: refpolicy-strict-semanage_t-access-user-home.patch --]
[-- Type: text/x-diff, Size: 2026 bytes --]

semanage_t would require necessary privilege to read the pp created in user
homedir or /tmp, otherwise following error messages would pop up when
updating a pp in permissive mode:

root@cp3020:/root> semodule -u authlogin.pp 
type=1400 audit(1264599291.256:51): avc:  denied  { search } for  pid=2360 comm="semodule" name="root" dev=sda1 ino=579361 scontext=root:secadm_r:semanage_t:s0-s15:c0.c255 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir
type=1400 audit(1264599291.301:52): avc:  denied  { read } for  pid=2360 comm="semodule" name="authlogin.pp" dev=sda1 ino=579366 scontext=root:secadm_r:semanage_t:s0-s15:c0.c255 tcontext=root:object_r:user_home_t:s0 tclass=file
type=1400 audit(1264599291.347:53): avc:  denied  { open } for  pid=2360 comm="semodule" name="authlogin.pp" dev=sda1 ino=579366 scontext=root:secadm_r:semanage_t:s0-s15:c0.c255 tcontext=root:object_r:user_home_t:s0 tclass=file
type=1400 audit(1264599291.392:54): avc:  denied  { getattr } for  pid=2360 comm="semodule" path="/root/authlogin.pp" dev=sda1 ino=579366 scontext=root:secadm_r:semanage_t:s0-s15:c0.c255 tcontext=root:object_r:user_home_t:s0 tclass=file
SELinux: 8192 avtab hash slots, 167322 rules.
SELinux: 8192 avtab hash slots, 167322 rules.
SELinux:  6 users, 13 roles, 3007 types, 105 bools, 16 sens, 256 cats
SELinux:  77 classes, 167322 rules
type=1403 audit(1264599325.456:55): policy loaded auid=4294967295 ses=4294967295
root@cp3020:/root>

Signed-off-by: Harry Ciao<qingtao.cao@windriver.com>
---
 policy/modules/system/selinuxutil.te |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- a/policy/modules/system/selinuxutil.te
+++ b/policy/modules/system/selinuxutil.te
@@ -492,9 +492,8 @@ ifdef(`distro_ubuntu',`
 
 # cjp: need a more general way to handle this:
 ifdef(`enable_mls',`
-	# read secadm tmp files
-',`
 	# Handle pp files created in homedir and /tmp
+	userdom_search_user_home_dirs(semanage_t)
 	userdom_read_user_home_content_files(semanage_t)
 	userdom_read_user_tmp_files(semanage_t)
 ')

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #12: refpolicy-strict-securetty_types-fix.patch --]
[-- Type: text/x-diff, Size: 833 bytes --]

Add the types of /dev/console and /dev/pts/0 to securetty_types file,
so that you can do newrole on these devices.

Signed-off-by: Harry Ciao<qingtao.cao@windriver.com>
---
 config/appconfig-mcs/securetty_types      |    2 ++
 config/appconfig-mls/securetty_types      |    2 ++
 config/appconfig-standard/securetty_types |    2 ++
 3 files changed, 6 insertions(+)

--- a/config/appconfig-mcs/securetty_types
+++ b/config/appconfig-mcs/securetty_types
@@ -1 +1,3 @@
 user_tty_device_t
+console_device_t
+user_devpts_t
--- a/config/appconfig-mls/securetty_types
+++ b/config/appconfig-mls/securetty_types
@@ -1 +1,3 @@
 user_tty_device_t
+console_device_t
+user_devpts_t
--- a/config/appconfig-standard/securetty_types
+++ b/config/appconfig-standard/securetty_types
@@ -1 +1,3 @@
 user_tty_device_t
+console_device_t
+user_devpts_t

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #13: refpolicy-strict-setfiles_t-read-console.patch --]
[-- Type: text/x-diff, Size: 842 bytes --]

setfiles_t would require necessary privilege to read from /dev/console,
otherwise we will run into below error message during boot up:

type=1400 audit(1286905969.676:7): avc:  denied  { read } for  pid=1960 comm="restorecon" name="console" dev=sda1 ino=522248 scontext=system_u:system_r:setfiles_t:s0-s15:c0.c255 tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file

Signed-off-by: Harry Ciao<qingtao.cao@windriver.com>
---
 policy/modules/system/selinuxutil.te |    2 ++
 1 file changed, 2 insertions(+)

--- a/policy/modules/system/selinuxutil.te
+++ b/policy/modules/system/selinuxutil.te
@@ -554,6 +554,8 @@ term_use_all_user_ttys(setfiles_t)
 term_use_all_user_ptys(setfiles_t)
 term_use_unallocated_ttys(setfiles_t)
 
+term_read_console(setfiles_t)
+
 # this is to satisfy the assertion:
 auth_relabelto_shadow(setfiles_t)
 

[refpolicy] Ask for comments about some patches for refpolicy-2.20091117

[TaurusHarry]

Hi SELinux experts,

I have come up with some patches for the latest refpolicy-2.20091117 and would like to ask for opinions about whether they make sense or not. 

Please help review when convenient, any comment is greatly welcomed!

Best regards,
Harry
 		 	   		  
_________________________________________________________________
Windows Live????????????
http://events.livetome.cn/2010/2birthday
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20100203/03701624/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-strict-crond_t-domtrans-hostname.patch
Type: text/x-diff
Size: 1519 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100203/03701624/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-strict-crond_t-manipulate-bin.patch
Type: text/x-diff
Size: 1979 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100203/03701624/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-strict-dontaudit-quota_t-mmap_zero.patch
Type: text/x-diff
Size: 1018 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100203/03701624/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-strict-getty_t-use-console.patch
Type: text/x-diff
Size: 1985 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100203/03701624/attachment-0003.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-strict-initrc_t-create-fixed-disk.patch
Type: text/x-diff
Size: 1209 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100203/03701624/attachment-0004.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-strict-insmod_t-use-console.patch
Type: text/x-diff
Size: 805 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100203/03701624/attachment-0005.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-strict-mount_t-manipulate-generic-locks.patch
Type: text/x-diff
Size: 2461 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100203/03701624/attachment-0006.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-strict-newrole_t-use-console.patch
Type: text/x-diff
Size: 845 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100203/03701624/attachment-0007.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-strict-root-dir-label.patch
Type: text/x-diff
Size: 633 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100203/03701624/attachment-0008.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-strict-semanage_t-access-user-home.patch
Type: text/x-diff
Size: 2026 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100203/03701624/attachment-0009.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-strict-securetty_types-fix.patch
Type: text/x-diff
Size: 833 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100203/03701624/attachment-0010.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-strict-setfiles_t-read-console.patch
Type: text/x-diff
Size: 842 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100203/03701624/attachment-0011.bin 

[refpolicy] Ask for comments about some patches for refpolicy-2.20091117

[Dominick Grift]

On 02/03/2010 10:10 AM, TaurusHarry wrote:
> 
> Hi SELinux experts,
> 
> I have come up with some patches for the latest refpolicy-2.20091117 and would like to ask for opinions about whether they make sense or not. 
> 
> Please help review when convenient, any comment is greatly welcomed!
> 
> Best regards,
> Harry
>  		 	   		  

> crond_t would require necessary privilege to execute the /bin/hostname 
> program, otherwise we will run into below error messages during system boots up:
> 

crond_t does not require it; logcheck.sh does.

I would probably dump the script in /etc/cron.daily or something.
alternatively create cron_system_entry

Else you could confine your script and set up a domain transition from
crond_t to your scripts domain.

> crond_t would require necessary privilege to manage and execute bin_t files,
> otherwise we will run into below error messages during system boots up:

Probably same as above it; not cron but your script.

However i did notice the following:

[root at localhost Desktop]# sesearch -SC --allow -s crond_t -t bin_t
Found 7 semantic av rules:
   allow domain bin_t : dir { getattr search open } ;
   allow crond_t file_type : filesystem getattr ;
   allow crond_t bin_t : dir { ioctl read getattr lock search open } ;
   allow crond_t bin_t : lnk_file { read getattr } ;
ET allow crond_t bin_t : file { ioctl read getattr lock execute
execute_no_trans open } ; [ allow_polyinstantiation ]
ET allow crond_t bin_t : dir { ioctl read getattr lock search open } ; [
allow_polyinstantiation ]
ET allow crond_t bin_t : lnk_file { read getattr } ; [
allow_polyinstantiation ]

Meaning that if boolean allow_polyinstantiation is toggled to true, then
crond_t is allowed to execute bin_t files in its own domain. (i do not
know why)

> quotaon will try to mmap a low area of the address space, which is explicitly
> prohibited by the neverallow rule defined in kernel/domain.te:

I guess you do not have much choice here. ( i never noticed that quotaon
needs this. )

> Where "console=ttyS0, 115200n8" or the like is specified in kernel bootparams.
> This  would require getty_t having necessary privilege in order to use the console.
> Otherwise /sbin/mingetty will fail to domain transition to local_login_t
> and /sbin/init will end up respawning /sbin/mingetty forever:

I guess you do no have much choice here.


> initrc_t would require necessary privilege to create /dev/loop*, otherwise
> we will run into below error message during system boots up:

grep -r MAKEDEV /etc/rc.d/init.d/

See whether MAKEDEV is called from an init script or whether a program
that is not targeted is runs MAKEDEV.

If MAKEDEV is called from some init script, than personally i would file
a bug for the program that installed the init script. There are (in my
opinion), or should be,  limits to the functionality of init scripts.

If some init daemon that is currently not targeted runs MAKEDEV , than i
would start by targeting that init daemon.

> insmod_t would require necessary privilege to operate /dev/console, otherwise
> during boot up modprobe would throw out many error messages such as:

I think these are usually dontaudited but i guess for some reason it
should be allowed:

Found 1 semantic av rules:
   allow insmod_t console_device_t : chr_file { ioctl read write getattr
lock append open } ;

So that looks ok.

> The mount_t domain should have enough privilege to create the lock file in
> /var/lock, otherwise we will run into below error messages during boot up:
> 

Instead of using files_manage_generic_locks(mount_t), i would file type
transition to mount_var_lock_t (after that type is created and made
usable a files_lock_file(). But this is a personal preference.

> We should grant newrole_t enough privilege to use and relabel the /dev/console
> if we want to use newrole after logging in from serial console.
> 
> However, if you never logs in from console but on tty or through ssh then this patch
> is not needed.
> 

I would make this tunable.

> Explicitly specify the security context for /root directory to avoid 
> it being labeled as default_t.
> 

Sure. This is how it is done in Fedora though:

../Policy/3.7.8-6.fc13/serefpolicy-3.7.8/policy/modules/system/userdomain.fc:/root(/.*)?
               gen_context(system_u:object_r:admin_home_t,s0)

Fedora uses type admin_home_t instead of user_home_(dir_)t

> semanage_t would require necessary privilege to read the pp created in user
> homedir or /tmp, otherwise following error messages would pop up when
> updating a pp in permissive mode:

userdom_read_user_home_content_files(semanage_t) should already include
the required permissions to search user home dirs. If it does not, than
in my view that is a bug in userdom_read_user_home_content_files()

> Add the types of /dev/console and /dev/pts/0 to securetty_types file,
> so that you can do newrole on these devices.

This i do not know. I guess if you consider them secure...

> setfiles_t would require necessary privilege to read from /dev/console,
> otherwise we will run into below error message during boot up:
> 

This can be allowed. Fedora has this AV allowed as well:

allow setfiles_t console_device_t : chr_file { ioctl read write getattr
lock append open } ;

Disclaimer: this is my personal view on this. I might be wrong about
some of this.





_____________________________________________________________
> Windows Live????????????
> http://events.livetome.cn/2010/2birthday
> 
> 
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100203/84e80a4a/attachment-0001.bin 

[refpolicy] Ask for comments about some patches for refpolicy-2.20091117

[TaurusHarry]

Hi Dom,

Many thanks for your comments for my patches, I've learned a lot from them. First things first I think I would need to install setools package on my target to analyze the TE rules whenever I get new AVC messages.

I will follow and verify your suggestions and get back to you later.

Have a nice weekend!

Best regards,
Harry

> Date: Wed, 3 Feb 2010 15:28:42 +0100
> From: domg472 at gmail.com
> To: refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Ask for comments about some patches for	refpolicy-2.20091117
> 
> On 02/03/2010 10:10 AM, TaurusHarry wrote:
> > 
> > Hi SELinux experts,
> > 
> > I have come up with some patches for the latest refpolicy-2.20091117 and would like to ask for opinions about whether they make sense or not. 
> > 
> > Please help review when convenient, any comment is greatly welcomed!
> > 
> > Best regards,
> > Harry
> >  		 	   		  
> 
> > crond_t would require necessary privilege to execute the /bin/hostname 
> > program, otherwise we will run into below error messages during system boots up:
> > 
> 
> crond_t does not require it; logcheck.sh does.
> 
> I would probably dump the script in /etc/cron.daily or something.
> alternatively create cron_system_entry
> 
> Else you could confine your script and set up a domain transition from
> crond_t to your scripts domain.
> 
> > crond_t would require necessary privilege to manage and execute bin_t files,
> > otherwise we will run into below error messages during system boots up:
> 
> Probably same as above it; not cron but your script.
> 
> However i did notice the following:
> 
> [root at localhost Desktop]# sesearch -SC --allow -s crond_t -t bin_t
> Found 7 semantic av rules:
>    allow domain bin_t : dir { getattr search open } ;
>    allow crond_t file_type : filesystem getattr ;
>    allow crond_t bin_t : dir { ioctl read getattr lock search open } ;
>    allow crond_t bin_t : lnk_file { read getattr } ;
> ET allow crond_t bin_t : file { ioctl read getattr lock execute
> execute_no_trans open } ; [ allow_polyinstantiation ]
> ET allow crond_t bin_t : dir { ioctl read getattr lock search open } ; [
> allow_polyinstantiation ]
> ET allow crond_t bin_t : lnk_file { read getattr } ; [
> allow_polyinstantiation ]
> 
> Meaning that if boolean allow_polyinstantiation is toggled to true, then
> crond_t is allowed to execute bin_t files in its own domain. (i do not
> know why)
> 
> > quotaon will try to mmap a low area of the address space, which is explicitly
> > prohibited by the neverallow rule defined in kernel/domain.te:
> 
> I guess you do not have much choice here. ( i never noticed that quotaon
> needs this. )
> 
> > Where "console=ttyS0, 115200n8" or the like is specified in kernel bootparams.
> > This  would require getty_t having necessary privilege in order to use the console.
> > Otherwise /sbin/mingetty will fail to domain transition to local_login_t
> > and /sbin/init will end up respawning /sbin/mingetty forever:
> 
> I guess you do no have much choice here.
> 
> 
> > initrc_t would require necessary privilege to create /dev/loop*, otherwise
> > we will run into below error message during system boots up:
> 
> grep -r MAKEDEV /etc/rc.d/init.d/
> 
> See whether MAKEDEV is called from an init script or whether a program
> that is not targeted is runs MAKEDEV.
> 
> If MAKEDEV is called from some init script, than personally i would file
> a bug for the program that installed the init script. There are (in my
> opinion), or should be,  limits to the functionality of init scripts.
> 
> If some init daemon that is currently not targeted runs MAKEDEV , than i
> would start by targeting that init daemon.
> 
> > insmod_t would require necessary privilege to operate /dev/console, otherwise
> > during boot up modprobe would throw out many error messages such as:
> 
> I think these are usually dontaudited but i guess for some reason it
> should be allowed:
> 
> Found 1 semantic av rules:
>    allow insmod_t console_device_t : chr_file { ioctl read write getattr
> lock append open } ;
> 
> So that looks ok.
> 
> > The mount_t domain should have enough privilege to create the lock file in
> > /var/lock, otherwise we will run into below error messages during boot up:
> > 
> 
> Instead of using files_manage_generic_locks(mount_t), i would file type
> transition to mount_var_lock_t (after that type is created and made
> usable a files_lock_file(). But this is a personal preference.
> 
> > We should grant newrole_t enough privilege to use and relabel the /dev/console
> > if we want to use newrole after logging in from serial console.
> > 
> > However, if you never logs in from console but on tty or through ssh then this patch
> > is not needed.
> > 
> 
> I would make this tunable.
> 
> > Explicitly specify the security context for /root directory to avoid 
> > it being labeled as default_t.
> > 
> 
> Sure. This is how it is done in Fedora though:
> 
> ../Policy/3.7.8-6.fc13/serefpolicy-3.7.8/policy/modules/system/userdomain.fc:/root(/.*)?
>                gen_context(system_u:object_r:admin_home_t,s0)
> 
> Fedora uses type admin_home_t instead of user_home_(dir_)t
> 
> > semanage_t would require necessary privilege to read the pp created in user
> > homedir or /tmp, otherwise following error messages would pop up when
> > updating a pp in permissive mode:
> 
> userdom_read_user_home_content_files(semanage_t) should already include
> the required permissions to search user home dirs. If it does not, than
> in my view that is a bug in userdom_read_user_home_content_files()
> 
> > Add the types of /dev/console and /dev/pts/0 to securetty_types file,
> > so that you can do newrole on these devices.
> 
> This i do not know. I guess if you consider them secure...
> 
> > setfiles_t would require necessary privilege to read from /dev/console,
> > otherwise we will run into below error message during boot up:
> > 
> 
> This can be allowed. Fedora has this AV allowed as well:
> 
> allow setfiles_t console_device_t : chr_file { ioctl read write getattr
> lock append open } ;
> 
> Disclaimer: this is my personal view on this. I might be wrong about
> some of this.
> 
> 
> 
> 
> 
> _____________________________________________________________
> > Windows Live????????????
> > http://events.livetome.cn/2010/2birthday
> > 
> > 
> > 
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> 
> 
 		 	   		  
_________________________________________________________________
SkyDrive????????????????????????!
http://www.windowslive.cn/campaigns/e-magazine/ngmchina/?a=c
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20100204/a7204d94/attachment.html 

[refpolicy] Ask for comments about some patches for refpolicy-2.20091117

[TaurusHarry]

> Date: Wed, 3 Feb 2010 15:28:42 +0100
> From: domg472 at gmail.com
> To: refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] Ask for comments about some patches for	refpolicy-2.20091117
> 
> On 02/03/2010 10:10 AM, TaurusHarry wrote:
> > 
> > Hi SELinux experts,
> > 
> > I have come up with some patches for the latest refpolicy-2.20091117 and would like to ask for opinions about whether they make sense or not. 
> > 
> > Please help review when convenient, any comment is greatly welcomed!
> > 
> > Best regards,
> > Harry
> >  		 	   		  
> 
> > crond_t would require necessary privilege to execute the /bin/hostname 
> > program, otherwise we will run into below error messages during system boots up:
> > 
> 
> crond_t does not require it; logcheck.sh does.
> 
> I would probably dump the script in /etc/cron.daily or something.
> alternatively create cron_system_entry
> 
> Else you could confine your script and set up a domain transition from
> crond_t to your scripts domain.
> 
> > crond_t would require necessary privilege to manage and execute bin_t files,
> > otherwise we will run into below error messages during system boots up:
> 
> Probably same as above it; not cron but your script.
> 
> However i did notice the following:
> 
> [root at localhost Desktop]# sesearch -SC --allow -s crond_t -t bin_t
> Found 7 semantic av rules:
>    allow domain bin_t : dir { getattr search open } ;
>    allow crond_t file_type : filesystem getattr ;
>    allow crond_t bin_t : dir { ioctl read getattr lock search open } ;
>    allow crond_t bin_t : lnk_file { read getattr } ;
> ET allow crond_t bin_t : file { ioctl read getattr lock execute
> execute_no_trans open } ; [ allow_polyinstantiation ]
> ET allow crond_t bin_t : dir { ioctl read getattr lock search open } ; [
> allow_polyinstantiation ]
> ET allow crond_t bin_t : lnk_file { read getattr } ; [
> allow_polyinstantiation ]
> 
> Meaning that if boolean allow_polyinstantiation is toggled to true, then
> crond_t is allowed to execute bin_t files in its own domain. (i do not
> know why)
> 

Hi Dom,

My /etc/crontab looks at this:
# run-parts

01 * * * * root run-parts /etc/cron.hourly

02 4 * * * root run-parts /etc/cron.daily

22 4 * * 0 root run-parts /etc/cron.weekly

42 4 1 * * root run-parts /etc/cron.monthly

and the /usr/bin/run-parts has been labeled as bin_t:
root at cp3020:/root> ls -Z /usr/bin/run-parts 
-rwxr-xr-x  root root system_u:object_r:bin_t:s0       /usr/bin/run-parts

So I guess it's crond_t that lacks read/execute/ etc privileges for the bin_t. After I applied this patch I can tell from sesearch result that crond_t now have the required privileges now:
root at cp3020:/root> sesearch -SCA -s crond_t -t bin_t -c file
Found 1 semantic av rules:
   allow crond_t bin_t : file { ioctl read write create getattr setattr lock append unlink link rename execute execute_no_trans open } ; 

BTW, this rule is not controlled by the allow_polyinstantiate boolean in my policy.

> > quotaon will try to mmap a low area of the address space, which is explicitly
> > prohibited by the neverallow rule defined in kernel/domain.te:
> 
> I guess you do not have much choice here. ( i never noticed that quotaon
> needs this. )
> 
> > Where "console=ttyS0, 115200n8" or the like is specified in kernel bootparams.
> > This  would require getty_t having necessary privilege in order to use the console.
> > Otherwise /sbin/mingetty will fail to domain transition to local_login_t
> > and /sbin/init will end up respawning /sbin/mingetty forever:
> 
> I guess you do no have much choice here.
> 
> 
> > initrc_t would require necessary privilege to create /dev/loop*, otherwise
> > we will run into below error message during system boots up:
> 
> grep -r MAKEDEV /etc/rc.d/init.d/
> 
> See whether MAKEDEV is called from an init script or whether a program
> that is not targeted is runs MAKEDEV.
> 
> If MAKEDEV is called from some init script, than personally i would file
> a bug for the program that installed the init script. There are (in my
> opinion), or should be,  limits to the functionality of init scripts.
> 
> If some init daemon that is currently not targeted runs MAKEDEV , than i
> would start by targeting that init daemon.

Well, on my target it is /etc/rc.d/init.d/udev-post that calls MAKEDEV. However, I think the MAKEDEV is called from /sbin/start_udev, which in turn gets called by rc.sysinit.

If MLS is not enabled, then adding the storage_tmpfs_filetrans_fixed_disk(initrc_t) for distro_redhat would be enough for /dev/loop* being created by MAKEDEV. However,  I found these s15.c0.c255 devcies created successfully only after one more interface of mls_file_upgrade() called for initrc_t.

> 
> > insmod_t would require necessary privilege to operate /dev/console, otherwise
> > during boot up modprobe would throw out many error messages such as:
> 
> I think these are usually dontaudited but i guess for some reason it
> should be allowed:
> 
> Found 1 semantic av rules:
>    allow insmod_t console_device_t : chr_file { ioctl read write getattr
> lock append open } ;
> 
> So that looks ok.
> 
> > The mount_t domain should have enough privilege to create the lock file in
> > /var/lock, otherwise we will run into below error messages during boot up:
> > 
> 
> Instead of using files_manage_generic_locks(mount_t), i would file type
> transition to mount_var_lock_t (after that type is created and made
> usable a files_lock_file(). But this is a personal preference.
> 
> > We should grant newrole_t enough privilege to use and relabel the /dev/console
> > if we want to use newrole after logging in from serial console.
> > 
> > However, if you never logs in from console but on tty or through ssh then this patch
> > is not needed.
> > 
> 
> I would make this tunable.
> 
> > Explicitly specify the security context for /root directory to avoid 
> > it being labeled as default_t.
> > 
> 
> Sure. This is how it is done in Fedora though:
> 
> ../Policy/3.7.8-6.fc13/serefpolicy-3.7.8/policy/modules/system/userdomain.fc:/root(/.*)?
>                gen_context(system_u:object_r:admin_home_t,s0)
> 
> Fedora uses type admin_home_t instead of user_home_(dir_)t
> 
> > semanage_t would require necessary privilege to read the pp created in user
> > homedir or /tmp, otherwise following error messages would pop up when
> > updating a pp in permissive mode:
> 
> userdom_read_user_home_content_files(semanage_t) should already include
> the required permissions to search user home dirs. If it does not, than
> in my view that is a bug in userdom_read_user_home_content_files()
> 

Yeah, you are right, the userdom_read_user_home_content_files() is a superset for userdom_search_user_home_dirs().

Thanks again!

Best regards,
Harry


> > Add the types of /dev/console and /dev/pts/0 to securetty_types file,
> > so that you can do newrole on these devices.
> 
> This i do not know. I guess if you consider them secure...
> 
> > setfiles_t would require necessary privilege to read from /dev/console,
> > otherwise we will run into below error message during boot up:
> > 
> 
> This can be allowed. Fedora has this AV allowed as well:
> 
> allow setfiles_t console_device_t : chr_file { ioctl read write getattr
> lock append open } ;
> 
> Disclaimer: this is my personal view on this. I might be wrong about
> some of this.
> 
> 
> 
> 
> 
> _____________________________________________________________
> > Windows Live????????????
> > http://events.livetome.cn/2010/2birthday
> > 
> > 
> > 
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> 
> 
 		 	   		  
_________________________________________________________________
MSN????????????????25???????????2010?????????
http://kaba.msn.com.cn/?k=1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20100205/c31a0d33/attachment.html