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
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
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
> 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