Stephen Smalley wrote: > On Fri, 2008-07-18 at 13:40 -0400, Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Stephen Smalley wrote: >>> On Fri, 2008-07-18 at 13:16 -0400, Daniel J Walsh wrote: >>> SELinux complains about things like restorecon or rpm when conflicts >>> exist in file_context file even when SELinux is disabled. >>> >>> It should just shut up.... >>> >>>> I think that's the wrong place to do it: >>>> - the fact that the application called libselinux at all except to test >>>> is_selinux_enabled() when SELinux is disabled is either a bug in the >>>> application or an indication that the application wants SELinux behavior >>>> regardless, >>>> - silencing all log messages coming from libselinux is too broad. >>>> And of course, file_contexts conflicts should be caught during policy >>>> build time aside from local customizations; if not, then we need to >>>> change the policy build process to do that even for modular policy >>>> builds. >> Well it could be argued that libraries should never write to the terminal... > > selinux_set_callback() lets the application control that behavior. > >> Try explaining this to the users we are telling selinux disabled does >> not effect their machines. They just come away with the opinion that >> SELinux Sucks and is broken. Besides we are even complaining when they >> are warnings and SELinux is disabled. > > Which reflects a bug in the application - why is it calling matchpathcon > if is_selinux_enabled() <= 0? > > As far as the warning goes, the log callback does get a type parameter > so it can distinguish warnings vs. errors. But we don't want to hide > these kinds of duplications or conflicts - we just want them to be > caught earlier. > >> The problem seems to be a broken genhomedircon, but we don't currently >> prevent users (rpm post install scripts) from adding conflicting file >> context in file context.local >> plain text document attachment (diff) >> >> The tools just complain about it after the fact. >> >> # semanage fcontext -a -t httpd_sys_content_t /tmp > > Ah, that's interesting. So the setfiles -c execution by libsemanage > only validates the base file contexts. I'm trying to remember why we > did that. Seems like that could be changed easily enough. > >> # matchpathcon /etc >> # matchpathcon /etc/ >> /etc/selinux/targeted/contexts/files/file_contexts: Multiple different >> specifications for /tmp (system_u:object_r:httpd_sys_content_t:s0 and >> system_u:object_r:tmp_t:s0). >> /etc/ system_u:object_r:etc_t:s0 >> >> Nice. > > That's a real bug in the file_contexts file that shouldn't be hidden > from the user. > > I do agree that a) the application shouldn't be calling matchpathcon if > is_selinux_enabled() <= 0, and b) we ought to catch these kinds of > errors at policy build time for the base policy, and c) we ought to > catch these kinds of errors at semodule/semanage invocation time for > local customizations. That is what we should be fixing. Not silencing > the messenger. > setfiles works while selinux is disabled. It could be the kerberos libraries, or udev. I still think warnings on a disabled system should be quietly ignored or thrown in syslog at most. Having the machine scream at boot, is a mistake. kerberos libraries can not call selinux_set_callback() since they do not know if the process has set it already. Yes I agree semanage should stop this from happening at compile time. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
