Daniel J Walsh wrote:
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 may present a problem for policy developers. For instance, I am
writing new policy for spamass-milter, which currently shares spamd_t
with spamassassin. I need spamass-milter to transition into a different
domain, so I need to specify a new context for /usr/bin/spamass-milter
in my policy module. This conflicts with the existing context for the
same file (spamd_exec_t) in the main selinux-policy-targeted package and
I get warnings like this on most rpm/selinux operations:
/etc/selinux/targeted/contexts/files/file_contexts: Multiple different
specifications for /usr/sbin/spamass-milter
(system_u:object_r:milter_spamass_exec_t:s0 and
system_u:object_r:spamd_exec_t:s0).
For whatever reason, the context from my local module "wins" and I get
the desired result. However, if semanage didn't allow this, I believe
I'd need to fork the selinux-policy package for the duration of my
development to prevent the unwanted context specification from being
used. Or is there some other way around this?
Paul.
--
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.
