Latest diffs - Resent with additional changes.

Latest diffs - Resent with additional changes.

[Daniel J Walsh]

After one hell of a merge.  :^(

Spent Christmas vacation week getting Strict policy into shape.

Here are a bunch of changes as well as fixes for targeted and mls policy

http://people.redhat.com/dwalsh/SELinux/policy.diff

----------------------------------------------------------------------------------

Had to add system_u:system_u to seusers to get cron to work correctly.
Cron calls getseusers with parameter of "system_u" if this seuser does
not exist it fails over to user_u and everything blows up.

Added booleans

allow_ftpd_full_access -  Allows users to use ftp and read any file on
the system.  Pretty close to disable_trans, but you still have some
network controls.


Changes allow_mount_anyfile to only allow files
added allow_mounton_anydir to allow admin to mount on any directory but
not read files

allow_daemons_dump_core - Allow daemons to create corefiles in /

use_lpd_server boolean removes lots of not needed privs from lpr on cups
platforms.

allow_unconfined_execmem_dyntrans is only used on ia64 platforms to run
32 bit applications.  kernel does some funny stuff and rexecs
unconfined_t programs but needs execmem and execstack.  Otherwise ia64
has to run all apps with execmem execstack.


The MLS constraints are really screwed up.  Need to come to some kind of
agreement between you, klaus and tcs.

usedom_executable_file is still in there.  I believe we need to separate
out the executables that are expected to be run by a user and those
expected to be run by the system.  This helps prevent accidently running
of applications under sysadm_t.

mkinitrd should not be confined and should not be labeled
bootloader_exec_t.  This just causes too many problems and little benifit.

I do not want consoletype and hostname transitioning to their domains
unless they need the privs,  Having them transition from an init script
is broken, because you end up with tons of denials when applications
redirect stdin/stdout

Hal restarts the network which has a transition to consoletype and thus
we get denials.

logwatch looks for files under /var

quota needed major rework to work correctly in MLS environment

Certain tools have rpm libraries built into them and these end up
calling the transition rules and getting denials.  I want to allow
unconfined_t to transition to rpm_script_t

rpm execs prelink and chats with hal, also needs to kill processes
running at different sensitivity levels


Added a tzdata domain to allow proper context of /etc/localtime

sudo reads netlink_route_socket,  wants to look at the kernel key ring,
stores a token in the pam_pid directory, and needs to getattr on all
"user" executables.

Some changes to su in order to handle key rings,  Needs
mls_file_write_down.  Need to be able to su from different domains, and
pam_rootok causes some selinux_compute_access checks.


usermanage was changed to allow useradd to automatically label the
homedirs correctly.  useradd now has a -s qualifier that allows it to
select the selinux user.  It also then labels the directory correctly.
Critical for MLS and Strict policy to work.

Lots of fixes to get evolution, mozilla, thunderbird, gnome, mplayer to
work with strict policy.

evolution still needs work.  (I mainly use thunderbird...)

Fixes to get gpg secret created correctly

Added java_domtrans_user_javaplugin to get transition from
staff_mozilla_t -> staff_javaplugin_t to work.

java wants to dbus chat with unconfined domains and init domains.

Not sure why you want if targeted_policy in loadkeys_run?

Fixes for slocate on MLS

userhelper role line is wrong
userhelper_exec so sysadm_t can run userhelper without transitioning.

webalizer wants to getattr fs_t

Label some executables stored in wierd places.

Still want break out of hi_reserved_port_t from reserved_port_t.

genfscon for ntfs-3g

handles for unlabled_t packets

fixes for kernel_unconfined

httpd_t wants to write to snmp_var_lib_t files.  Dontaudit.

Several domains want to run telinit.  Added init_exec.

Remove anacron_exec_t.   Just run in crond_t.

Remove automount_etc_t - Useless.

clamd wants to read kernel sysctl


Lots of fixes to get cron to work and to use polyinstantiation.

cups changes to run in MLS

dbus needs to ptrance itself.

Needs new interface to connect to user bus.

ftp needs to write to faillog

Hal transitions to some other domains, but needs to have it's fds and
fifo_files dontaudited

fixes to allow inetd to run on mls

irqbalance needs additional privs

kerberos libraries now try to read krb6kdc_conf_t,  Should be dontaudited.

Lots of fixes to get ypxfr/ypserv to work correctly

Dont want dontaudit var_yp_t:dir search line since this prevents
setroubleshoot from realizing you are on an NIS box.

nscd needs auth_use_nsswitch

Added policy for pcscd

Lots of fixes to get rhgb to work correctly in a strict enforcing mode.

rlogind needs nsswitch

sendmail wants to read clamav_libs

userspace connects to setroubleshoot unix_stream_socket

fsdaemon needs mls_write_down

spamassisin needs to read /var/lib/spamassisin directory

ssh_agent leaks fds by design.

sshd wants to look at kernel key ring


relabel ICE-UNIX to xdm_tmp_t, since we can not get transition to work
correcrtly.  Hopefully alot of these other communications paths are
being eliminated by gnome.

Lots of fixes to get xserver working with strict policy


fixes for authlogin handling of keyrings and mls, as well as pcscd

hwclock wants to read system state.

mkswap should not run as fsadm.  Should be labeled sbin_t.

Fixes for initrc to run in strict

fixes for iptbales to use nscd

local_login needs additional privs

lvm needs privs for multipath

/usr/share/X11/locale needs a label.

initrc replace localization files using cp -A to preserve context.  This
causes many avc messages.

modutils fixes for strict policy

Need correct labels for genhomedircon and system-config-selinux to
create context correctly.

Lots of fixes for polyinstatiation on MLS

Lots of updates to allow userdomain to work correctly in strict policy


Many changes to allow use of confined users in Targeted policy



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Latest diffs - Resent with additional changes.

[Christopher J. PeBenito]

(Karl, see the 3rd part: userdom_executable_file)

On Thu, 2007-01-25 at 08:12 -0500, Daniel J Walsh wrote: 
> allow_unconfined_execmem_dyntrans is only used on ia64 platforms to run
> 32 bit applications.  kernel does some funny stuff and rexecs
> unconfined_t programs but needs execmem and execstack.  Otherwise ia64
> has to run all apps with execmem execstack.

Almost makes me want to make an arch_ia64 tunable.  Aside from the usual
non-tranquil processes arguments, I'm not sure if this has to be
tunable, since its just going from unconfined to unconfined_execmem,
which are pretty much the same domain.

> The MLS constraints are really screwed up.  Need to come to some kind of
> agreement between you, klaus and tcs.

I'm not familiar with the LSPP requirements, so its mainly up to Klaus
and the TCS guys to iron out what makes sense.

> userdom_executable_file is still in there.  I believe we need to separate
> out the executables that are expected to be run by a user and those
> expected to be run by the system.  This helps prevent accidently running
> of applications under sysadm_t.

I have seen where you were going with this, but I think the ssh agent
unix socket and xserver's xsession-errors.log inheritance (i.e. leak fd
by design) are more evidence that the answer is a little more
comprehensive, like an application domain interface, so we can collect
up the domain and the entry point into attributes.  I don't think this
should go into userdomain since it doesn't have to do with the
definition of user roles.  I also don't think it belongs in the domain
module, since thats a more primitive concept, it should be in a system
layer module (just like init's init_daemon_domain()), so this probably
should get its own system layer module.  The domain_interactive_fd()
stuff should probably be included in this too.  Karl, do you have any
thoughts on this?

> mkinitrd should not be confined and should not be labeled
> bootloader_exec_t.  This just causes too many problems and little
> benifit.

We'll also have to start analyzing the policy to see what can be removed
because of this.  I suspect that most of the distro_* and optionals can
be removed.

> I do not want consoletype and hostname transitioning to their domains
> unless they need the privs,  Having them transition from an init script
> is broken, because you end up with tons of denials when applications
> redirect stdin/stdout

Not transitioning consoletype might work, assuming use in init scripts
don't need the privs, and then sys_admin would probably need to be
dontaudited in initrc_t.  However, I can't see how hostname not
transitioning from initrc can work, since setting the hostname certainly
requires sys_admin, and we don't want to give sys_admin to initrc_t.  I
also noticed that initrc_t has sys_admin for distro_redhat because of
kmodule.  I don't know if thats still needed, but you won't see if stuff
breaks if consoletype and hostname don't transition because of this.

> Certain tools have rpm libraries built into them and these end up
> calling the transition rules and getting denials.  I want to allow
> unconfined_t to transition to rpm_script_t

This sounds weird to me, what would be an example of a tool that has
this problem?  Also if these are redhat tools then this should be in a
distro_redhat.

> rpm execs prelink and chats with hal, also needs to kill processes
> running at different sensitivity levels

a rebasing problem, its there already.

> Added a tzdata domain to allow proper context of /etc/localtime

moved to admin layer

> usermanage was changed to allow useradd to automatically label the
> homedirs correctly.  useradd now has a -s qualifier that allows it to
> select the selinux user.  It also then labels the directory correctly.
> Critical for MLS and Strict policy to work.

I don't understand this part of the change:

+# Required because semanage execs these and hands them useradd_t:fd
+seutil_domtrans_setfiles(useradd_t)
+seutil_domtrans_loadpolicy(useradd_t)

also, why was apache_manage_all_content(useradd_t) added?

> evolution still needs work.  (I mainly use thunderbird...)

I'm merging these, but I think in the long run all the domains in
evolution probably need to be merged; there really isn't anything gained
by having all the separate domains.

There was also a weird ifdef soffice at the bottom of thunderbird.if.

> Not sure why you want if targeted_policy in loadkeys_run?

Well if we want it to act the same in strict and targeted, the ifdefs
need to be removed in both files, but that wasn't happening.

> Still want break out of hi_reserved_port_t from reserved_port_t.

I don't have a problem with breaking them up, but the current
implementation needs some work.  The current interfaces that give access
to reserved_port_t shouldn't also give access to hi_reserved_port_t.

> Several domains want to run telinit.  Added init_exec.

Probably should use init_telinit() and add exec for init_exec_t to the
interface.

> Remove anacron_exec_t.   Just run in crond_t.

What is the motivation for this?  Looks like there are other changes in
here that are MLS-only; should be in an ifdef enable_mls.

> cups changes to run in MLS

moved the first change down.  the second change is already in, at the
top of the file.

> fixes to allow inetd to run on mls

rearranged this, so be careful when you update

> sendmail wants to read clamav_libs

Weird.  moved up.

> fixes for authlogin handling of keyrings and mls, as well as pcscd

Can you elaborate some more on what you're trying to do with the keyring
parts.

> mkswap should not run as fsadm.  Should be labeled sbin_t.

Without it being fsadm_t, you can't run it on disk partitions.

> fixes for iptbales to use nscd

moved this block down

> local_login needs additional privs

Can you elaborate on these; they all seem odd.

> lvm needs privs for multipath

Can you elaborate as to why multipath (dm/lvm) needs net_admin?  A
cursory look through the docs doesn't mention the network at all.

> initrc replace localization files using cp -A to preserve context.  This
> causes many avc messages.

Moved this to distro_redhat.

> modutils fixes for strict policy

Why would depmod delete kernel modules?  Seems more like a mislabeled file.

> Need correct labels for genhomedircon and system-config-selinux to
> create context correctly.

Why would genhomedircon be ran directly instead of semodule or semanage?

> Lots of fixes for polyinstatiation on MLS

Why is corecmd_exec_bin() needed?

----

What is /dev/twe[^/]* and why is it labeled as a fixed disk (esp. since
its a character node)?

The term_unconfined() seems superfluous.

This seems excessive:

+# allow setkey to read a config files in any directory.
+userdom_read_sysadm_home_content_files(setkey_t)
+userdom_read_all_users_home_content_files(setkey_t)

There is an addition which allows ricci_moservice_t to create an init
script, and it can already transition to initrc_t with init scripts
entrypoints.  Does it really need this?

Why?
+allow nmbd_t samba_log_t:file unlink;

I noticed several ptrace additions.  Is there something new that is
causing these domains to trace themselves?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Latest diffs - Resent with additional changes.

[Klaus Weidner]

On Fri, Feb 16, 2007 at 04:58:21PM -0500, Christopher J. PeBenito wrote:
> On Thu, 2007-01-25 at 08:12 -0500, Daniel J Walsh wrote: 
> > The MLS constraints are really screwed up.  Need to come to some kind of
> > agreement between you, klaus and tcs.
> 
> I'm not familiar with the LSPP requirements, so its mainly up to Klaus
> and the TCS guys to iron out what makes sense.

I haven't heard back from TCS about their opinion on this. I would
suggest using the constraints as in Dan's policy (and as used in the
RHEL5 rc) since those are designed to meet LSPP requirements.

Dan, if you need to change the MLS constraints for RHEL5 to be different
from how they are now please let me know.

-Klaus

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Latest diffs - Resent with additional changes.

[Daniel J Walsh]

Christopher J. PeBenito wrote:
> (Karl, see the 3rd part: userdom_executable_file)
>
> On Thu, 2007-01-25 at 08:12 -0500, Daniel J Walsh wrote: 
>   
>> allow_unconfined_execmem_dyntrans is only used on ia64 platforms to run
>> 32 bit applications.  kernel does some funny stuff and rexecs
>> unconfined_t programs but needs execmem and execstack.  Otherwise ia64
>> has to run all apps with execmem execstack.
>>     
>
> Almost makes me want to make an arch_ia64 tunable.  Aside from the usual
> non-tranquil processes arguments, I'm not sure if this has to be
> tunable, since its just going from unconfined to unconfined_execmem,
> which are pretty much the same domain.
>
>   
>> The MLS constraints are really screwed up.  Need to come to some kind of
>> agreement between you, klaus and tcs.
>>     
>
> I'm not familiar with the LSPP requirements, so its mainly up to Klaus
> and the TCS guys to iron out what makes sense.
>
>   
>> userdom_executable_file is still in there.  I believe we need to separate
>> out the executables that are expected to be run by a user and those
>> expected to be run by the system.  This helps prevent accidently running
>> of applications under sysadm_t.
>>     
>
> I have seen where you were going with this, but I think the ssh agent
> unix socket and xserver's xsession-errors.log inheritance (i.e. leak fd
> by design) are more evidence that the answer is a little more
> comprehensive, like an application domain interface, so we can collect
> up the domain and the entry point into attributes.  I don't think this
> should go into userdomain since it doesn't have to do with the
> definition of user roles.  I also don't think it belongs in the domain
> module, since thats a more primitive concept, it should be in a system
> layer module (just like init's init_daemon_domain()), so this probably
> should get its own system layer module.  The domain_interactive_fd()
> stuff should probably be included in this too.  Karl, do you have any
> thoughts on this?
>   
This sounds good to me, but we need to specify these some how, 
especially if we start adding additional User Domains.
>   
>> mkinitrd should not be confined and should not be labeled
>> bootloader_exec_t.  This just causes too many problems and little
>> benifit.
>>     
>
> We'll also have to start analyzing the policy to see what can be removed
> because of this.  I suspect that most of the distro_* and optionals can
> be removed.
>
>   
>> I do not want consoletype and hostname transitioning to their domains
>> unless they need the privs,  Having them transition from an init script
>> is broken, because you end up with tons of denials when applications
>> redirect stdin/stdout
>>     
>
> Not transitioning consoletype might work, assuming use in init scripts
> don't need the privs, and then sys_admin would probably need to be
> dontaudited in initrc_t.  However, I can't see how hostname not
> transitioning from initrc can work, since setting the hostname certainly
> requires sys_admin, and we don't want to give sys_admin to initrc_t.  I
> also noticed that initrc_t has sys_admin for distro_redhat because of
> kmodule.  I don't know if thats still needed, but you won't see if stuff
> breaks if consoletype and hostname don't transition because of this.
>
>   
Ok I will remove this from Rawhide and see what breaks. 
>> Certain tools have rpm libraries built into them and these end up
>> calling the transition rules and getting denials.  I want to allow
>> unconfined_t to transition to rpm_script_t
>>     
>
>   
Multiple people are putting out apps like pup, up2date and other daemons 
that basically use the rpm database.  We need to keep labeling these 
rpm_exec_t to get them to work, or just allow the unconfined domain to 
transition to rpm_script_t to make rpm_exec work correctly.
> This sounds weird to me, what would be an example of a tool that has
> this problem?  Also if these are redhat tools then this should be in a
> distro_redhat.
>
>   
>> rpm execs prelink and chats with hal, also needs to kill processes
>> running at different sensitivity levels
>>     
>
> a rebasing problem, its there already.
>
>   
ok
>> Added a tzdata domain to allow proper context of /etc/localtime
>>     
>
> moved to admin layer
>
>   
ok
>> usermanage was changed to allow useradd to automatically label the
>> homedirs correctly.  useradd now has a -s qualifier that allows it to
>> select the selinux user.  It also then labels the directory correctly.
>> Critical for MLS and Strict policy to work.
>>     
>
>   
useradd, usermod now have semanage capability built into them,  So when 
I add a user I can specify a default SELinux user

useradd -Z staff_u dwalsh

This causes semanage to be executed to add the mapping.  It then calls 
genhomedircon and relabels the homedir correctly.

The problem is the useradd owns the terminal file descriptor which 
generates avc messages.
We really would want them to dontaudit the fd, so I guess an interface 
to useradd to ignore its fds would be better.
> I don't understand this part of the change:
>
> +# Required because semanage execs these and hands them useradd_t:fd
> +seutil_domtrans_setfiles(useradd_t)
> +seutil_domtrans_loadpolicy(useradd_t)
>
> also, why was apache_manage_all_content(useradd_t) added?
>
>   
useradd will create ~/public_html and any contents in it from the skel,  
It needs to be able to create and label these files.  As we expand 
userroles, we might need the capabilitity to identify contents in a home 
directory by attribute and allow useradd and friends to create/relabel them.
>> evolution still needs work.  (I mainly use thunderbird...)
>>     
>
> I'm merging these, but I think in the long run all the domains in
> evolution probably need to be merged; there really isn't anything gained
> by having all the separate domains.
>
> There was also a weird ifdef soffice at the bottom of thunderbird.if.
>
>   
Yes I will remove that.  I agree, thunderbird should be consolodated.  
As we move to userroles, I think we will need to reexamine all of these 
GUI/Application interfaces.
>> Not sure why you want if targeted_policy in loadkeys_run?
>>     
>
> Well if we want it to act the same in strict and targeted, the ifdefs
> need to be removed in both files, but that wasn't happening.
>
>   
Yes I will be sending up the next patch with lots of ifdef strict_policy 
removed.  Since we want to start introducing some confined user types to 
targeted policy.
>> Still want break out of hi_reserved_port_t from reserved_port_t.
>>     
>
> I don't have a problem with breaking them up, but the current
> implementation needs some work.  The current interfaces that give access
> to reserved_port_t shouldn't also give access to hi_reserved_port_t.
>
>   
Ok I think we should change
corenet_udp_bind_reserved_port and
corenet_tcp_bind_reserved_port to use hi_reserved_port_t

>> Several domains want to run telinit.  Added init_exec.
>>     
>
> Probably should use init_telinit() and add exec for init_exec_t to the
> interface.
>
>   
Ok I will change in next update.
>> Remove anacron_exec_t.   Just run in crond_t.
>>     
>
> What is the motivation for this?  Looks like there are other changes in
> here that are MLS-only; should be in an ifdef enable_mls.
>
>   
I am removing this change.  The end goal should be to make anacron 
selinux aware to work like cron.
>> cups changes to run in MLS
>>     
>
> moved the first change down.  the second change is already in, at the
> top of the file.
>   
Ok
mls_trusted_object(cupsd_var_run_t) is also in there twice.


>   
>> fixes to allow inetd to run on mls
>>     
>
> rearranged this, so be careful when you update
>
>   
>> sendmail wants to read clamav_libs
>>     
>
> Weird.  moved up.
>
>   
I think we might want to somehow add an attibute to file types that 
sendmail can read. 

sendmail < /var/run/log  commands are probably causing this type of access.
>> fixes for authlogin handling of keyrings and mls, as well as pcscd
>>     
>
> Can you elaborate some more on what you're trying to do with the keyring
> parts.
>   
I am just flailing around with this stuff,  I guess I am trying to 
identify domains that will own keyrings.  And then pass around open 
descriptors to them.   I really do not understand how this stuff is 
supposed to work.
>   
>> mkswap should not run as fsadm.  Should be labeled sbin_t.
>>     
>
> Without it being fsadm_t, you can't run it on disk partitions.
>
>   
mkswap has smarts built into it to label file swap_file_t at least at 
Red Hat.  Right now we only execute this from a unconfined domain, so 
this is not a problem.
>> fixes for iptbales to use nscd
>>     
>
> moved this block down
>
>   
>> local_login needs additional privs
>>     
>
> Can you elaborate on these; they all seem odd.
>
>   
I am not sure why they are generated,  I would guess this is generated 
by some pam module that requires appletalk communications.
>> lvm needs privs for multipath
>>     
>
> Can you elaborate as to why multipath (dm/lvm) needs net_admin?  A
> cursory look through the docs doesn't mention the network at all.
>
>   
Perhaps raid/iscsi?  Just guessing.  Don't have access to the Bugzilla 
that reported it.
>> initrc replace localization files using cp -A to preserve context.  This
>> causes many avc messages.
>>     
>
> Moved this to distro_redhat.
>
>   
ok
>> modutils fixes for strict policy
>>     
>
> Why would depmod delete kernel modules?  Seems more like a mislabeled file.
>
>   
Perhaps creating a tmp file in that directory?
>> Need correct labels for genhomedircon and system-config-selinux to
>> create context correctly.
>>     
>
> Why would genhomedircon be ran directly instead of semodule or semanage?
>
>   
It is a binary on disk that can be run, and people do.  You could add 
new users via NIS/LDAP others and then want to fix the labeling on the 
homedirs.
>> Lots of fixes for polyinstatiation on MLS
>>     
>
> Why is corecmd_exec_bin() needed?
>
>   
/etc/security/namespace.init
> ----
>
> What is /dev/twe[^/]* and why is it labeled as a fixed disk (esp. since
> its a character node)?
>
>   
Using google I found some references.  This might shed some light.
http://sourceforge.net/project/shownotes.php?release_id=267829&group_id=64297
> The term_unconfined() seems superfluous.
>
>   
Certain privs are not available for terminals, from unconfined domain.  
> This seems excessive:
>
> +# allow setkey to read a config files in any directory.
> +userdom_read_sysadm_home_content_files(setkey_t)
> +userdom_read_all_users_home_content_files(setkey_t)
>
>   
I guess we could label it differently, but this is a case similar to 
semodule where a user might create a file that they need to process with 
a confined domain. The problem is the confined domain is not allowed to 
read it and this confuses the user. 
> There is an addition which allows ricci_moservice_t to create an init
> script, and it can already transition to initrc_t with init scripts
> entrypoints.  Does it really need this?
>
>   
ricci_modservice executes chkconfig under the covers and starts and 
stops services.  So this is kind of what it is designed to do.  
Basically you use the tool to turn on service scripts at different 
runlevels and then start them.
> Why?
> +allow nmbd_t samba_log_t:file unlink;
>
>   
I am not sure.  Lots of bugzillas in FC6.
> I noticed several ptrace additions.  Is there something new that is
> causing these domains to trace themselves?
>
>   
killall and pidof now request ptrace when they run.  So any confined 
domain that execs these ends up requesting ptrace.  I think we can 
dontaudit them.  I believe Steve Smalley is looking into how we can 
remove this priv being required from just looking at the process table.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Latest diffs - Resent with additional changes.

[Darrel Goeddel]

Klaus Weidner wrote:
> On Fri, Feb 16, 2007 at 04:58:21PM -0500, Christopher J. PeBenito wrote:
>> On Thu, 2007-01-25 at 08:12 -0500, Daniel J Walsh wrote: 
>>> The MLS constraints are really screwed up.  Need to come to some kind of
>>> agreement between you, klaus and tcs.
>> I'm not familiar with the LSPP requirements, so its mainly up to Klaus
>> and the TCS guys to iron out what makes sense.
> 
> I haven't heard back from TCS about their opinion on this. I would
> suggest using the constraints as in Dan's policy (and as used in the
> RHEL5 rc) since those are designed to meet LSPP requirements.

We (TCS) are checking out the changes now.

-- 

Darrel

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Latest diffs - Resent with additional changes.

[Christopher J. PeBenito]

On Tue, 2007-02-20 at 10:58 -0500, Daniel J Walsh wrote:
> Christopher J. PeBenito wrote:
> >
> > On Thu, 2007-01-25 at 08:12 -0500, Daniel J Walsh wrote: 
> >> Certain tools have rpm libraries built into them and these end up
> >> calling the transition rules and getting denials.  I want to allow
> >> unconfined_t to transition to rpm_script_t
> >>     
> >
> >   
> Multiple people are putting out apps like pup, up2date and other daemons 
> that basically use the rpm database.  We need to keep labeling these 
> rpm_exec_t to get them to work, or just allow the unconfined domain to 
> transition to rpm_script_t to make rpm_exec work correctly.

They do setexeccon(::rpm_script_t)?

> > also, why was apache_manage_all_content(useradd_t) added?
> >
> >   
> useradd will create ~/public_html and any contents in it from the skel,  
> It needs to be able to create and label these files.  As we expand 
> userroles, we might need the capabilitity to identify contents in a home 
> directory by attribute and allow useradd and friends to create/relabel them.

The extras (stuff beyond things like .bashrc) in the skel is distro
dependent, so this should be in a distro_redhat.

> >> Still want break out of hi_reserved_port_t from reserved_port_t.
> >>     
> >
> > I don't have a problem with breaking them up, but the current
> > implementation needs some work.  The current interfaces that give access
> > to reserved_port_t shouldn't also give access to hi_reserved_port_t.
> >
> >   
> Ok I think we should change
> corenet_udp_bind_reserved_port and
> corenet_tcp_bind_reserved_port to use hi_reserved_port_t

I think we should have a low_reserved_port_t and high_reserved_port_t as
it seems clearer than reserved_port_t and high_reserved_port_t.  The
interfaces should reflect that.
  
> >> sendmail wants to read clamav_libs
> >>     
> >
> > Weird.  moved up.
> >
> >   
> I think we might want to somehow add an attibute to file types that 
> sendmail can read. 
> 
> sendmail < /var/run/log  commands are probably causing this type of access.

I'm not sure its dynamic enough to need an attribute.  We could consider
adding access to common stuff like config files, log files, and some
temp files.  

> >> local_login needs additional privs
> >>     
> >
> > Can you elaborate on these; they all seem odd.
> >
> >   
> I am not sure why they are generated,  I would guess this is generated 
> by some pam module that requires appletalk communications.

I'm going to need some more info on this.

> >> lvm needs privs for multipath
> >>     
> >
> > Can you elaborate as to why multipath (dm/lvm) needs net_admin?  A
> > cursory look through the docs doesn't mention the network at all.
> >
> >   
> Perhaps raid/iscsi?  Just guessing.  Don't have access to the Bugzilla 
> that reported it.

I'm going to need justification for this change.

> >> modutils fixes for strict policy
> >>     
> >
> > Why would depmod delete kernel modules?  Seems more like a mislabeled file.
> >
> >   
> Perhaps creating a tmp file in that directory?

My guess would be a file that is supposed to be modules_dep_t is instead
mislabeled as modules_object_t.

> > The term_unconfined() seems superfluous.
> >
> >   
> Certain privs are not available for terminals, from unconfined domain.  

It should be covered by the device_unconfined(), but looks like the
problem is that they're not marked as device nodes in term_tty() and
term_pty().  I've fixed this.

> > This seems excessive:
> >
> > +# allow setkey to read a config files in any directory.
> > +userdom_read_sysadm_home_content_files(setkey_t)
> > +userdom_read_all_users_home_content_files(setkey_t)
> >
> >   
> I guess we could label it differently, but this is a case similar to 
> semodule where a user might create a file that they need to process with 
> a confined domain. The problem is the confined domain is not allowed to 
> read it and this confuses the user. 

I can buy this for the sysadm's home content, but not unpriv users
content.

> > There is an addition which allows ricci_moservice_t to create an init
> > script, and it can already transition to initrc_t with init scripts
> > entrypoints.  Does it really need this?
> >
> >   
> ricci_modservice executes chkconfig under the covers and starts and 
> stops services.  So this is kind of what it is designed to do.  
> Basically you use the tool to turn on service scripts at different 
> runlevels and then start them.

Wouldn't the chkconfig part just be some symlink management?

> > Why?
> > +allow nmbd_t samba_log_t:file unlink;
> >
> >   
> I am not sure.  Lots of bugzillas in FC6.

It would be helpful if you could look through those to try to see why
this is happening.  We don't want daemons to delete their logs if it can
be helped.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Latest diffs - Resent with additional changes.

[Darrel Goeddel]

Darrel Goeddel wrote:
> Klaus Weidner wrote:
>> On Fri, Feb 16, 2007 at 04:58:21PM -0500, Christopher J. PeBenito wrote:
>>> On Thu, 2007-01-25 at 08:12 -0500, Daniel J Walsh wrote:
>>>> The MLS constraints are really screwed up.  Need to come to some 
>>>> kind of
>>>> agreement between you, klaus and tcs.
>>> I'm not familiar with the LSPP requirements, so its mainly up to Klaus
>>> and the TCS guys to iron out what makes sense.
>>
>> I haven't heard back from TCS about their opinion on this. I would
>> suggest using the constraints as in Dan's policy (and as used in the
>> RHEL5 rc) since those are designed to meet LSPP requirements.
> 
> We (TCS) are checking out the changes now.
> 

> diff --exclude-from=exclude -N -u -r nsaserefpolicy/policy/mls serefpolicy-2.5.1/policy/mls
> --- nsaserefpolicy/policy/mls	2006-11-16 17:15:26.000000000 -0500
> +++ serefpolicy-2.5.1/policy/mls	2007-01-17 13:32:47.000000000 -0500
> @@ -89,12 +89,14 @@
>  mlsconstrain { file lnk_file fifo_file dir chr_file blk_file sock_file } { write create setattr relabelfrom append unlink link rename mounton }
>  	(( l1 eq l2 ) or
>  	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> -	 (( t2 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
>  	 ( t1 == mlsfilewrite ) or
> +	 (( t2 == mlsrangedobject ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
>  	 ( t2 == mlstrustedobject ));
>  
> +# Directory "write" ops
>  mlsconstrain dir { add_name remove_name reparent rmdir }
> -	((( l1 dom l2 ) and ( l1 domby h2 )) or
> +	(( l1 eq l2 ) or
> +	 (( t1 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
>  	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
>  	 ( t1 == mlsfilewrite ) or
>  	 ( t2 == mlstrustedobject ));

First a question about something that is already upstream - the mlsrangedobject
portion of the constraint?  Should that line read: 
 "( t2 == mlsrangedobject ) and ( l1 dom l2 ) and ( l1 domby h2 )) or"?
Currently a process operating at SECRET, but with a clearance of SYSTEMHIGH could
not write to a "mlsrangedobject" ranged from UNCLASSIFIED to TOP SECRET because the
( h1 domby h2 ) check would fail.  Since the process is operating at SECRET,
shouldn't the access be granted?

The mlsrangedobject and mlswfilewriteinrange seem to be providing about the same
functionality (unless I'm missing something regarding the comment above).  Why have
a subject based override a few dir ops and an object based override for most other
file (in the general sense) ops?  I would think that these two constraint block should
be identical, as they used to be.  The only reason they were ever separated is due to
the fact that directories had operations other file classes did not have.  Maybe have
both overrides (subject and object) available and make these two block match up?

Like this (ignoring my first question about the h1 in the mlsrangedobject line):
	(( l1 eq l2 ) or
	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
	 (( t1 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
	 ( t1 == mlsfilewrite ) or
	 (( t2 == mlsrangedobject ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
	 ( t2 == mlstrustedobject ));

> @@ -165,8 +167,20 @@
>  mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } relabelto
>  	( h1 dom h2 );
>  
> +# the socket "read+write" ops
> +# (Socket FDs are generally bidirectional, equivalent to open(..., O_RDWR),
> +# require equal levels for unprivileged subjects, or read *and* write overrides)
> +mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { accept connect }
> +	(( l1 eq l2 ) or
> +	 (((( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
> +	   ( t1 == mlsnetread )) and
> +	  ((( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
> +	   (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> +	   ( t1 == mlsnetwrite ))));
> +
> +

The above can be accomplished by placing both accept and connect in the read
and write constraints below.  That way things wouldn't get out of sync if the
definition of the read or write constraint changes.

> @@ -274,7 +289,8 @@
>  
>  # the netif/node "write" ops (implicit single level socket doing the write)
>  mlsconstrain { netif node } { tcp_send udp_send rawip_send }
> -	(( l1 dom l2 ) and ( l1 domby h2 ));
> +	(( l1 eq l2 ) or
> +	(( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )));

We may like a mlsnetwrite override here as well.  I'll have to dig into it a 
bit more (or pick other brains :)) to figure out if we need it given the
state of the networking code.  Someone will follow up when after further
investigation.

-- 

Darrel

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Latest diffs - Resent with additional changes.

[Klaus Weidner]

On Tue, Feb 20, 2007 at 04:44:43PM -0600, Darrel Goeddel wrote:
> Darrel Goeddel wrote:
> >Klaus Weidner wrote:
> >+	 (( t2 == mlsrangedobject ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
> 
> First a question about something that is already upstream - the
> mlsrangedobject portion of the constraint?  Should that line read: 
>
> "( t2 == mlsrangedobject ) and ( l1 dom l2 ) and ( l1 domby h2 )) or"?
>
> Currently a process operating at SECRET, but with a clearance of
> SYSTEMHIGH could not write to a "mlsrangedobject" ranged from
> UNCLASSIFIED to TOP SECRET because the ( h1 domby h2 ) check would
> fail.  Since the process is operating at SECRET, shouldn't the access
> be granted?

Yes you are right, that was a mistake and is unnecessarily restrictive.
The check should be as you suggest (using "l1 domby h2"). Sorry about
that, and thank you for reviewing the changes. Do you want to merge that
change or do you want me to send a patch? 

> >+# Directory "write" ops
> > mlsconstrain dir { add_name remove_name reparent rmdir }
> >-	((( l1 dom l2 ) and ( l1 domby h2 )) or
> >+	(( l1 eq l2 ) or
> >+	 (( t1 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( l1 domby h2 
> >)) or
> > 	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) 
> > 	 or
> > 	 ( t1 == mlsfilewrite ) or
> > 	 ( t2 == mlstrustedobject ));
> 
> The mlsrangedobject and mlswfilewriteinrange seem to be providing about
> the same functionality (unless I'm missing something regarding the
> comment above).  Why have a subject based override a few dir ops and an
> object based override for most other file (in the general sense) ops?
> I would think that these two constraint block should be identical, as
> they used to be.  The only reason they were ever separated is due to
> the fact that directories had operations other file classes did not
> have.  Maybe have both overrides (subject and object) available and
> make these two block match up?

The first patch I had sent renamed the existing "mlsfilewriteinrange"
object based override to "mlsrangedobject" to match the naming
conventions used for other object overrides, they are supposed to be the
same thing. Apparently that patch was rejected upstream, which
contributed to the confusion. They are supposed to be the same thing.

> Like this (ignoring my first question about the h1 in the mlsrangedobject 
> line):
> 	(( l1 eq l2 ) or
> 	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) 
> 	 or
> 	 (( t1 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( l1 domby h2 
> 	 )) or
> 	 ( t1 == mlsfilewrite ) or
> 	 (( t2 == mlsrangedobject ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
> 	 ( t2 == mlstrustedobject ));

I'm not aware that mlsfilewriteinrange is used for both subject and
object properties - this is confusing. I don't have a strong opinion
about what the attribute is named and how it is used as long as the
permission check doesn't allow ranged writes without an override.

> >+mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket 
> >packet_socket key_socket unix_stream_socket unix_dgram_socket 
> >netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket 
> >netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket 
> >netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { accept 
> >connect }
> >+	(( l1 eq l2 ) or
> >+	 (((( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
> >+	   ( t1 == mlsnetread )) and
> >+	  ((( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 
> >)) or
> >+	   (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 
> >)) or
> >+	   ( t1 == mlsnetwrite ))));
> 
> The above can be accomplished by placing both accept and connect in the
> read and write constraints below.  That way things wouldn't get out of
> sync if the definition of the read or write constraint changes.

Sure, that is fine with me if the resulting policy is equivalent, and
sounds cleaner.

> >@@ -274,7 +289,8 @@
> > 
> > # the netif/node "write" ops (implicit single level socket doing the 
> > write)
> > mlsconstrain { netif node } { tcp_send udp_send rawip_send }
> >-	(( l1 dom l2 ) and ( l1 domby h2 ));
> >+	(( l1 eq l2 ) or
> >+	(( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )));
> 
> We may like a mlsnetwrite override here as well.  I'll have to dig into it 
> a bit more (or pick other brains :)) to figure out if we need it given the
> state of the networking code.  Someone will follow up when after further
> investigation.

In general adding additional overrides is fine, the point of the changes
was to make sure that users who don't have additional privileges get
the expected results.

-Klaus

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Latest diffs - Resent with additional changes.

[Daniel J Walsh]

Klaus Weidner wrote:
> On Tue, Feb 20, 2007 at 04:44:43PM -0600, Darrel Goeddel wrote:
>   
>> Darrel Goeddel wrote:
>>     
>>> Klaus Weidner wrote:
>>> +	 (( t2 == mlsrangedobject ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
>>>       
>> First a question about something that is already upstream - the
>> mlsrangedobject portion of the constraint?  Should that line read: 
>>
>> "( t2 == mlsrangedobject ) and ( l1 dom l2 ) and ( l1 domby h2 )) or"?
>>
>> Currently a process operating at SECRET, but with a clearance of
>> SYSTEMHIGH could not write to a "mlsrangedobject" ranged from
>> UNCLASSIFIED to TOP SECRET because the ( h1 domby h2 ) check would
>> fail.  Since the process is operating at SECRET, shouldn't the access
>> be granted?
>>     
>
> Yes you are right, that was a mistake and is unnecessarily restrictive.
> The check should be as you suggest (using "l1 domby h2"). Sorry about
> that, and thank you for reviewing the changes. Do you want to merge that
> change or do you want me to send a patch? 
>
>   
>>> +# Directory "write" ops
>>> mlsconstrain dir { add_name remove_name reparent rmdir }
>>> -	((( l1 dom l2 ) and ( l1 domby h2 )) or
>>> +	(( l1 eq l2 ) or
>>> +	 (( t1 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( l1 domby h2 
>>> )) or
>>> 	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) 
>>> 	 or
>>> 	 ( t1 == mlsfilewrite ) or
>>> 	 ( t2 == mlstrustedobject ));
>>>       
>> The mlsrangedobject and mlswfilewriteinrange seem to be providing about
>> the same functionality (unless I'm missing something regarding the
>> comment above).  Why have a subject based override a few dir ops and an
>> object based override for most other file (in the general sense) ops?
>> I would think that these two constraint block should be identical, as
>> they used to be.  The only reason they were ever separated is due to
>> the fact that directories had operations other file classes did not
>> have.  Maybe have both overrides (subject and object) available and
>> make these two block match up?
>>     
>
> The first patch I had sent renamed the existing "mlsfilewriteinrange"
> object based override to "mlsrangedobject" to match the naming
> conventions used for other object overrides, they are supposed to be the
> same thing. Apparently that patch was rejected upstream, which
> contributed to the confusion. They are supposed to be the same thing.
>
>   
>> Like this (ignoring my first question about the h1 in the mlsrangedobject 
>> line):
>> 	(( l1 eq l2 ) or
>> 	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) 
>> 	 or
>> 	 (( t1 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( l1 domby h2 
>> 	 )) or
>> 	 ( t1 == mlsfilewrite ) or
>> 	 (( t2 == mlsrangedobject ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
>> 	 ( t2 == mlstrustedobject ));
>>     
>
> I'm not aware that mlsfilewriteinrange is used for both subject and
> object properties - this is confusing. I don't have a strong opinion
> about what the attribute is named and how it is used as long as the
> permission check doesn't allow ranged writes without an override.
>
>   
>>> +mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket 
>>> packet_socket key_socket unix_stream_socket unix_dgram_socket 
>>> netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket 
>>> netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket 
>>> netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { accept 
>>> connect }
>>> +	(( l1 eq l2 ) or
>>> +	 (((( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
>>> +	   ( t1 == mlsnetread )) and
>>> +	  ((( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 
>>> )) or
>>> +	   (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 
>>> )) or
>>> +	   ( t1 == mlsnetwrite ))));
>>>       
>> The above can be accomplished by placing both accept and connect in the
>> read and write constraints below.  That way things wouldn't get out of
>> sync if the definition of the read or write constraint changes.
>>     
>
> Sure, that is fine with me if the resulting policy is equivalent, and
> sounds cleaner.
>
>   
>>> @@ -274,7 +289,8 @@
>>>
>>> # the netif/node "write" ops (implicit single level socket doing the 
>>> write)
>>> mlsconstrain { netif node } { tcp_send udp_send rawip_send }
>>> -	(( l1 dom l2 ) and ( l1 domby h2 ));
>>> +	(( l1 eq l2 ) or
>>> +	(( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )));
>>>       
>> We may like a mlsnetwrite override here as well.  I'll have to dig into it 
>> a bit more (or pick other brains :)) to figure out if we need it given the
>> state of the networking code.  Someone will follow up when after further
>> investigation.
>>     
>
> In general adding additional overrides is fine, the point of the changes
> was to make sure that users who don't have additional privileges get
> the expected results.
>
> -Klaus
>   

Send a patch to make sure we do it correctly.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Latest diffs - Resent with additional changes.

[Darrel Goeddel]

Klaus Weidner wrote:
> On Tue, Feb 20, 2007 at 04:44:43PM -0600, Darrel Goeddel wrote:
>> Darrel Goeddel wrote:
>>> Klaus Weidner wrote:
>>> +# Directory "write" ops
>>> mlsconstrain dir { add_name remove_name reparent rmdir }
>>> -	((( l1 dom l2 ) and ( l1 domby h2 )) or
>>> +	(( l1 eq l2 ) or
>>> +	 (( t1 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( l1 domby h2 
>>> )) or
>>> 	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) 
>>> 	 or
>>> 	 ( t1 == mlsfilewrite ) or
>>> 	 ( t2 == mlstrustedobject ));
>> The mlsrangedobject and mlswfilewriteinrange seem to be providing about
>> the same functionality (unless I'm missing something regarding the
>> comment above).  Why have a subject based override a few dir ops and an
>> object based override for most other file (in the general sense) ops?
>> I would think that these two constraint block should be identical, as
>> they used to be.  The only reason they were ever separated is due to
>> the fact that directories had operations other file classes did not
>> have.  Maybe have both overrides (subject and object) available and
>> make these two block match up?
> 
> The first patch I had sent renamed the existing "mlsfilewriteinrange"
> object based override to "mlsrangedobject" to match the naming
> conventions used for other object overrides, they are supposed to be the
> same thing. Apparently that patch was rejected upstream, which
> contributed to the confusion. They are supposed to be the same thing.
> 
>> Like this (ignoring my first question about the h1 in the mlsrangedobject 
>> line):
>> 	(( l1 eq l2 ) or
>> 	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) 
>> 	 or
>> 	 (( t1 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( l1 domby h2 
>> 	 )) or
>> 	 ( t1 == mlsfilewrite ) or
>> 	 (( t2 == mlsrangedobject ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
>> 	 ( t2 == mlstrustedobject ));
> 
> I'm not aware that mlsfilewriteinrange is used for both subject and
> object properties - this is confusing. I don't have a strong opinion
> about what the attribute is named and how it is used as long as the
> permission check doesn't allow ranged writes without an override.

The subject based override should be mlsfilewriteinrange and the object based
override should be mlsrangedobject, as they are.  I was just wondering if there
was a need for both.  I'm fine with having the extra flexibility of both the
subject based override and the object based override.

So... Do we agree that the block of constraints in question (the "big" file
write block and the extra directory operation block) should read should be:

(( l1 eq l2 ) or
 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
 (( t1 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
 ( t1 == mlsfilewrite ) or
 (( t2 == mlsrangedobject ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
 ( t2 == mlstrustedobject ));

>>> @@ -274,7 +289,8 @@
>>>
>>> # the netif/node "write" ops (implicit single level socket doing the 
>>> write)
>>> mlsconstrain { netif node } { tcp_send udp_send rawip_send }
>>> -	(( l1 dom l2 ) and ( l1 domby h2 ));
>>> +	(( l1 eq l2 ) or
>>> +	(( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )));
>> We may like a mlsnetwrite override here as well.  I'll have to dig into it 
>> a bit more (or pick other brains :)) to figure out if we need it given the
>> state of the networking code.  Someone will follow up when after further
>> investigation.
> 
> In general adding additional overrides is fine, the point of the changes
> was to make sure that users who don't have additional privileges get
> the expected results.

I'll let you know what we come up with on the possibility of the extra
override on the netif/node constraint.

I stuck what I think the mls file should look like here:

http://home.insightbb.com/~dgoeddel/policy/mls

I can give patches against svn or the rhel policy if you need.  Just let
me know.  It would probably be easiest if you could roll this into the big
patch for upstream (assuming everyone approves).  Otherwise I could make a
follow-on patch after the currently proposed changed are handled by Chris.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Latest diffs - Resent with additional changes.

[Klaus Weidner]

On Wed, Feb 21, 2007 at 11:58:11AM -0600, Darrel Goeddel wrote:
> The subject based override should be mlsfilewriteinrange and the object
> based override should be mlsrangedobject, as they are.  I was just
> wondering if there was a need for both.  I'm fine with having the extra
> flexibility of both the subject based override and the object based
> override.

Ok - I'm fine with supporting both overrides for extra flexibility.

> So... Do we agree that the block of constraints in question (the "big" file
> write block and the extra directory operation block) should read should be:
> 
> (( l1 eq l2 ) or
> (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> (( t1 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
> ( t1 == mlsfilewrite ) or
> (( t2 == mlsrangedobject ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
> ( t2 == mlstrustedobject ));

Yes, see below.

> I'll let you know what we come up with on the possibility of the extra
> override on the netif/node constraint.
> 
> I stuck what I think the mls file should look like here:
> 
> http://home.insightbb.com/~dgoeddel/policy/mls
> 
> I can give patches against svn or the rhel policy if you need.  Just let
> me know.  It would probably be easiest if you could roll this into the big
> patch for upstream (assuming everyone approves).  Otherwise I could make a
> follow-on patch after the currently proposed changed are handled by Chris.

I agree that the policy on your web page looks reasonable, and I think we
should go with that one. (We'll still need to run tests on it, and will
speak up if something unexpected happens.)

For completeness, here's a patch against selinux-policy-2.4.6-38.el5.src.rpm
(downloaded from http://people.redhat.com/dwalsh/SELinux/RHEL5/) to make
it match that policy.

Signed-off-by: Klaus Weidner <klaus@atsec.com>

--- /home/kw/bulk/src/rpm/BUILD/serefpolicy-2.4.6/policy/mls	2007-02-21 15:44:31.000000000 -0600
+++ dgoeddel/mls	2007-02-21 11:58:12.000000000 -0600
@@ -85,20 +85,21 @@
 	 ( t1 == mlsfileread ) or
 	 ( t2 == mlstrustedobject ));
 
-# the "single level" file "write" ops
+# the file "write" ops
 mlsconstrain { file lnk_file fifo_file dir chr_file blk_file sock_file } { write create setattr relabelfrom append unlink link rename mounton }
 	(( l1 eq l2 ) or
+	 (( t1 == mlsfilewriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
 	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
 	 ( t1 == mlsfilewrite ) or
-	 (( t2 == mlsrangedobject ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
+	 (( t2 == mlsrangedobject ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
 	 ( t2 == mlstrustedobject ));
 
-# Directory "write" ops
 mlsconstrain dir { add_name remove_name reparent rmdir }
 	(( l1 eq l2 ) or
 	 (( t1 == mlsfilewriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
 	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
 	 ( t1 == mlsfilewrite ) or
+	 (( t2 == mlsrangedobject ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
 	 ( t2 == mlstrustedobject ));
 
 # these access vectors have no MLS restrictions
@@ -167,20 +168,9 @@
 mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } relabelto
 	( h1 dom h2 );
 
-# the socket "read+write" ops
-# (Socket FDs are generally bidirectional, equivalent to open(..., O_RDWR),
-# require equal levels for unprivileged subjects, or read *and* write overrides)
-mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { accept connect }
-	(( l1 eq l2 ) or
-	 (((( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
-	   ( t1 == mlsnetread )) and
-	  ((( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
-	   (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
-	   ( t1 == mlsnetwrite ))));
-
-
 # the socket "read" ops (note the check is dominance of the low level)
-mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { read getattr listen getopt recv_msg }
+# note that accept and connect are also subject to the write constraint below
+mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { read getattr listen accept connect getopt recv_msg }
 	(( l1 dom l2 ) or
 	 (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
 	 ( t1 == mlsnetread ));
@@ -191,7 +181,8 @@
 	 ( t1 == mlsnetread ));
 
 # the socket "write" ops
-mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { write setattr relabelfrom setopt shutdown }
+# note that accept and connect are also subject to the read constraint above
+mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { write setattr relabelfrom accept connect setopt shutdown }
 	(( l1 eq l2 ) or 
 	 (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
 	 (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
@@ -290,7 +281,7 @@
 # the netif/node "write" ops (implicit single level socket doing the write)
 mlsconstrain { netif node } { tcp_send udp_send rawip_send }
 	(( l1 eq l2 ) or
-	(( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )));
+	 (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )));
 
 # these access vectors have no MLS restrictions
 # node enforce_dest

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Latest diffs - Resent with additional changes.

[Christopher J. PeBenito]

On Tue, 2007-02-20 at 18:27 -0600, Klaus Weidner wrote:
> On Tue, Feb 20, 2007 at 04:44:43PM -0600, Darrel Goeddel wrote:
> > Darrel Goeddel wrote:
> > The mlsrangedobject and mlswfilewriteinrange seem to be providing about
> > the same functionality (unless I'm missing something regarding the
> > comment above).  Why have a subject based override a few dir ops and an
> > object based override for most other file (in the general sense) ops?
> > I would think that these two constraint block should be identical, as
> > they used to be.  The only reason they were ever separated is due to
> > the fact that directories had operations other file classes did not
> > have.  Maybe have both overrides (subject and object) available and
> > make these two block match up?
> 
> The first patch I had sent renamed the existing "mlsfilewriteinrange"
> object based override to "mlsrangedobject" to match the naming
> conventions used for other object overrides, they are supposed to be the
> same thing. Apparently that patch was rejected upstream, which
> contributed to the confusion. They are supposed to be the same thing.

The only reason I had to reject renaming attributes is because it causes
a compatibility problem (the attribute you want to rename has been in a
refpolicy release).  In the (unlikely) case that a third party is
already using the interface that provides this attribute, their module
will break if you try to link it to a policy that has this change (if it
was compiled with the current interfaces).  This is all due to the fact
that interfaces modules are statically expanded, so mlsfilewriteinrange
will be required for their module.

Currently the only way that I can think of for renaming this but keeping
compatibility would be to:

1. add mlsrangedobject attribute
2. add the mlsconstraint expression for mlsrangedobject
3. add mls_ranged_object() interface
4. change mls_file_write_within_range() to call mls_ranged_object() and
throw a warning telling the user to use the mls_ranged_object()
interface using the refpolwarn() support macro

then after an appropriate transition time:

5. remove mlsfilewriteinrange attribute
6. remove mlsfilewriteinrange mlsconstraint expression
7. remove mls_file_write_within_range() interface

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.