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

[domg472@gmail.com (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