* Latest diffs - Resent with additional changes. @ 2007-01-25 13:12 Daniel J Walsh 2007-02-16 21:58 ` Christopher J. PeBenito 0 siblings, 1 reply; 12+ messages in thread From: Daniel J Walsh @ 2007-01-25 13:12 UTC (permalink / raw) To: Christopher J. PeBenito, SE Linux 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Latest diffs - Resent with additional changes. 2007-01-25 13:12 Latest diffs - Resent with additional changes Daniel J Walsh @ 2007-02-16 21:58 ` Christopher J. PeBenito 2007-02-19 3:19 ` Klaus Weidner 2007-02-20 15:58 ` Daniel J Walsh 0 siblings, 2 replies; 12+ messages in thread From: Christopher J. PeBenito @ 2007-02-16 21:58 UTC (permalink / raw) To: Daniel J Walsh, Karl MacMillan; +Cc: SE Linux (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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Latest diffs - Resent with additional changes. 2007-02-16 21:58 ` Christopher J. PeBenito @ 2007-02-19 3:19 ` Klaus Weidner 2007-02-20 19:41 ` Darrel Goeddel 2007-02-20 15:58 ` Daniel J Walsh 1 sibling, 1 reply; 12+ messages in thread From: Klaus Weidner @ 2007-02-19 3:19 UTC (permalink / raw) To: Christopher J. PeBenito; +Cc: Daniel J Walsh, Karl MacMillan, SE Linux 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Latest diffs - Resent with additional changes. 2007-02-19 3:19 ` Klaus Weidner @ 2007-02-20 19:41 ` Darrel Goeddel 2007-02-20 22:44 ` Darrel Goeddel 0 siblings, 1 reply; 12+ messages in thread From: Darrel Goeddel @ 2007-02-20 19:41 UTC (permalink / raw) To: Klaus Weidner Cc: Christopher J. PeBenito, Daniel J Walsh, Karl MacMillan, SE Linux 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Latest diffs - Resent with additional changes. 2007-02-20 19:41 ` Darrel Goeddel @ 2007-02-20 22:44 ` Darrel Goeddel 2007-02-21 0:27 ` Klaus Weidner 0 siblings, 1 reply; 12+ messages in thread From: Darrel Goeddel @ 2007-02-20 22:44 UTC (permalink / raw) To: Darrel Goeddel Cc: Klaus Weidner, Christopher J. PeBenito, Daniel J Walsh, Karl MacMillan, SE Linux 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Latest diffs - Resent with additional changes. 2007-02-20 22:44 ` Darrel Goeddel @ 2007-02-21 0:27 ` Klaus Weidner 2007-02-21 13:43 ` Daniel J Walsh ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Klaus Weidner @ 2007-02-21 0:27 UTC (permalink / raw) To: Darrel Goeddel Cc: Christopher J. PeBenito, Daniel J Walsh, Karl MacMillan, SE Linux 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Latest diffs - Resent with additional changes. 2007-02-21 0:27 ` Klaus Weidner @ 2007-02-21 13:43 ` Daniel J Walsh 2007-02-21 17:58 ` Darrel Goeddel 2007-02-23 16:12 ` Christopher J. PeBenito 2 siblings, 0 replies; 12+ messages in thread From: Daniel J Walsh @ 2007-02-21 13:43 UTC (permalink / raw) To: Klaus Weidner Cc: Darrel Goeddel, Christopher J. PeBenito, Karl MacMillan, SE Linux 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Latest diffs - Resent with additional changes. 2007-02-21 0:27 ` Klaus Weidner 2007-02-21 13:43 ` Daniel J Walsh @ 2007-02-21 17:58 ` Darrel Goeddel 2007-02-21 21:51 ` Klaus Weidner 2007-02-23 16:12 ` Christopher J. PeBenito 2 siblings, 1 reply; 12+ messages in thread From: Darrel Goeddel @ 2007-02-21 17:58 UTC (permalink / raw) To: Klaus Weidner Cc: Christopher J. PeBenito, Daniel J Walsh, Karl MacMillan, SE Linux 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Latest diffs - Resent with additional changes. 2007-02-21 17:58 ` Darrel Goeddel @ 2007-02-21 21:51 ` Klaus Weidner 0 siblings, 0 replies; 12+ messages in thread From: Klaus Weidner @ 2007-02-21 21:51 UTC (permalink / raw) To: Darrel Goeddel Cc: Christopher J. PeBenito, Daniel J Walsh, Karl MacMillan, SE Linux 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Latest diffs - Resent with additional changes. 2007-02-21 0:27 ` Klaus Weidner 2007-02-21 13:43 ` Daniel J Walsh 2007-02-21 17:58 ` Darrel Goeddel @ 2007-02-23 16:12 ` Christopher J. PeBenito 2 siblings, 0 replies; 12+ messages in thread From: Christopher J. PeBenito @ 2007-02-23 16:12 UTC (permalink / raw) To: Klaus Weidner; +Cc: Darrel Goeddel, Daniel J Walsh, Karl MacMillan, SE Linux 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Latest diffs - Resent with additional changes. 2007-02-16 21:58 ` Christopher J. PeBenito 2007-02-19 3:19 ` Klaus Weidner @ 2007-02-20 15:58 ` Daniel J Walsh 2007-02-20 20:04 ` Christopher J. PeBenito 1 sibling, 1 reply; 12+ messages in thread From: Daniel J Walsh @ 2007-02-20 15:58 UTC (permalink / raw) To: Christopher J. PeBenito; +Cc: Karl MacMillan, SE Linux 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Latest diffs - Resent with additional changes. 2007-02-20 15:58 ` Daniel J Walsh @ 2007-02-20 20:04 ` Christopher J. PeBenito 0 siblings, 0 replies; 12+ messages in thread From: Christopher J. PeBenito @ 2007-02-20 20:04 UTC (permalink / raw) To: Daniel J Walsh; +Cc: Karl MacMillan, SE Linux 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2007-02-23 16:10 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-01-25 13:12 Latest diffs - Resent with additional changes Daniel J Walsh 2007-02-16 21:58 ` Christopher J. PeBenito 2007-02-19 3:19 ` Klaus Weidner 2007-02-20 19:41 ` Darrel Goeddel 2007-02-20 22:44 ` Darrel Goeddel 2007-02-21 0:27 ` Klaus Weidner 2007-02-21 13:43 ` Daniel J Walsh 2007-02-21 17:58 ` Darrel Goeddel 2007-02-21 21:51 ` Klaus Weidner 2007-02-23 16:12 ` Christopher J. PeBenito 2007-02-20 15:58 ` Daniel J Walsh 2007-02-20 20:04 ` Christopher J. PeBenito
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.