From: harrytaurus2002@hotmail.com (TaurusHarry) Date: Thu, 4 Feb 2010 06:45:10 +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 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