From: harrytaurus2002@hotmail.com (TaurusHarry) Date: Fri, 5 Feb 2010 03:21:51 +0000 Subject: [refpolicy] Ask for comments about some patches for refpolicy-2.20091117 In-Reply-To: <4B69881A.9040102@gmail.com> References: , <4B69881A.9040102@gmail.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com > 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