Thomas Vander Stichele wrote:
Hi,
Why *all* so vehemently? There are devel issues other than selinux that occaisionallyOh, I'm sure there are developers dogfooding it. My point is that *all* of the Red Hat developers should be dogfooding it if you think SELINUX should be the default (which I assume is being thought since it's the default in anaconda).
crop up, and there is still a need to develop software that is (not yet anyways ;-) infected
with selinux.
Sure - but if Red Hat feels it is ready to be a default, surely it can't
be to much to ask that *all* developers respect that default and use
it ? I can't see what issues for them would be unfixable *if* your claim
that targeted is drop-in replacement is true.
Look *all* is not the issue, development is. A change of the magnitude of SELinux is not exactly easy, and even if *all* 1000 or so employees at Red Hat ran SE Linux daily, it simply would not make a difference at all.
Face it - lots of people have the attitude of "I'm just going to not try
SELINUX until it seems to be ready". That's not a good attitude, but
it's especially not a good attitude when those people are Red Hat
developers.
Sure, everyone has an attitude, some (like yours) I can even see some sense within ;-)
Your comments regarding SELinux were (and are, except for the naive *all* ;-)
dead on accurate IMHO, wrto my attitude. But that isn't really the issue here,
development of selinux and FCn is.
OTOH, I fully understand your out-of-box introduction to selinux trying to run mach.
My issues up to this point were completely unrelated to mach. Mach is
one of the reasons why I feel urged to run with targeted - I want to be
able to hit bugs that the common user will run into, so I can find a
solution in advance.
There are some very important issues in selinux with respect to aliasing of paths introduced by chroot that you and your mach build system experience could definitely help with.
The surface issue is that the added chroot prefix to paths more or less requires the
file context regexes be duplicated for each prefix when writing policy. This is rather clunky
atm (imho), and someone who uses chroot's all the time could only help
with a better specification mechanism for file contexts.
The other, and deeper, issue is writing policy for a build system which has not been
seriously attempted yet afiak/ Your mach hardening experience could only assist with
that policy goal (which is very different than writing "targeted" policy).
Perhaps *you* should have started dog-fooding selinux sooner. It's not exactly like
the SELinux clouds have not been gathering for quite some time.
Exactly. I have. Issues have ranged from "I couldn't even boot because
(I realize now) my /home was not labeled correctly and the installer
didn't think of doing that" to "All sorts of things didn't work,
including playing CD's". These are basic issues that should be caught
by *red hat devs* before they hit outside users IMO.
Good, glad to see you trying. Yup, selinux can/will stop booting, one needs to approach
booting just like one would with a bleeding edge development kernel, i.e. always have
a 2nd option.
I'm quite sure issues like booting failures have been "caught" by RH developers, it's
a new roll of the die for each and every new policy, and sh*t happens. Stabilizing
policy for everyone is a rather different issue than catching problems, and I suggest
that there has been demonstrable improvements throughout FC2 and FC3 devel
cycles.
It's pretty simple - if people at red hat were all happily running
SELINUX, there'd be less negative energy towards SELINUX from the
outside. As it stands, there are red hat developers who are negatively
promoting SELINUX, and you seem to suggest that *I* could solve this by
dogfooding in their place.
Would there? I doubt it, the magnitude of the effort to get to "strict" policy was rather
badly underestimated during FC2 which is what has led to "negative". Meanwhile, "targeted"
is a much saner, and more achievable goal, that is clearly easier to deploy stably, and with
a better focus on what the primary concern, an exploit path (i.e. daemons), that the majority of
users are (or should be) worried about.
And I dinna mean to suggest that you -- any more than the 1000 or so RH employees --
can "solve" any problem soon wrto SELinux deployment. It will take a gradual and persistent effort
to design and write policy that is known good, whose benefits are understood/used/deployed widely.
I'm trying to explain where this negative energy is coming from so that
the SELINUX transition goes better eventually.
Yeah, but you are explaining the existence of negative energy negatively.
Try the positive instead ;-)
73 de Jeff
