[refpolicy] Ask for comments about some patches for refpolicy-2.20091117
TaurusHarry
harrytaurus2002 at hotmail.com
Thu Feb 4 00:45:10 CST 2010
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
More information about the refpolicy
mailing list