Verily I say unto thee, that Roy Schestowitz spake thusly:
> SELinux and Fedora
[quote]
The Red Hat SELinux team is very responsive, but users will get
frustrated quickly if things they are trying to do fail in mysterious
(to them) ways.
[/quote]
> http://lwn.net/Articles/289224/
Apparently Jon Masters has never heard of sealert, which pops-up to
notify users of the exact reason for the AVC denial, and suggests a
simple remedy in each case. This is installed and enabled by default
on Fedora:
[quote]
The setroubleshootd daemon listens for AVC denials and passes them
through a series of plugins to analyze the audits and report what has
been prevented. Suggestions are made on how to fix denials. On the
client side sealert provides either a GUI or plain CLI interface which
can connect to either the local machine or to a remote setroubleshootd.
The daemon can be configured to send email alerts. Making changes to
system policy can be done in a variety of ways. The aforementioned
sealert often suggests a simple CLI sequence to run. The older CLI
audit2allow and audit2why tools respectively generate fixes based on the
audit logs and explain them. semanage allows changes to be made on the
fly to SELinux policies and system-config-selinux also allows boolean
selection among pre-written policy options and the easy changes of ports
or filecontexts.
[/quote]
http://fedoraproject.org/wiki/FWN/LatestIssue
To those unfamiliar with SELinux (especially Windows users), think of it
like a kind of Malware daemon that blocks attempted access (to various
things, not just files) if that access is not permitted by a list of
rules governed by that Malware daemon. Users are then notified about
access violations in the form of a pop-up dialogue (sealert), that then
helps the user fix the issue by modifying those rules (as root).
Unlike Vista's infamous UAC ("Cancel or Allow"), AVC deny alerts are
relatively infrequent with SELinux, because Linux software is designed
from the ground up to work in a true multi-user environment, and so
utilises privileged access only where absolutely necessary.
In all the time that I've been using SELinux in enforced mode, I've only
seen an AVC deny message /once/, and that was because Revisor (the
distro remastering package) broke policy with filesystem access for the
chroot it was using to remaster the distro. I haven't yet investigated
whether or not that was a policy violation or an oversight in the policy
itself, but it seems more likely to be the former.
Any violation of SELinux policies is considered to be a bug with the
software that attempts that violation, and upstream is notified so they
can fix that bug (or the downstream package maintainer provides a patch
which inevitably ends up being pushed back upstream). On the rare
occasion that it /is/ an oversight with the policy, that policy is
discussed and potentially modified, depending on the outcome of the
discussion (on the SELinux list). New policies are then pushed out to
users via the updates tree of the repo, which are automatically picked
up by yum-updatesd. In the interim users can work around those attempted
access violations using the tools provided in policycoreutils.
Compared to Windows, Linux is infinitely more secure, even /without/
SELinux, mainly because (as I've said) Linux software is designed with
minimal access privileges in mind, and therefore "running as root" is
something that ordinary users should have to do extremely infrequently -
in total contrast to Windows which assumes root access most of the time.
However, there are certain instances where Linux seems indirectly
vulnerable, e.g. where it is running a Web server that utilises software
that might be vulnerable to cross-site scripting vulnerabilities, such
as PHP has been on occasions. A Web server running SELinux in enforced
mode, with an appropriate MAC policy, would be far less vulnerable to
such attacks, to the point that would essentially negate that attack
vector completely.
This is why I promote the use of SELinux in enforced mode. The mild
inconvenience that some users may occasionally experience with AVC
denials is worth the price, for the sake of further securing Linux, in a
world completely overrun by Windows-zombie-powered botnets.
The tools are provided for one to administer SELinux, it's simply a
question of making the relatively small effort to learn how to use them,
and then /actually/ using them, rather than give up at the first hurdle
and turning off SELinux, thus negating the whole point of SELinux in the
first place.
This is something that has plagued UAC on Vista, but there is absolutely
no reason it should plague SELinux, since the severity and frequency of
AVC denials is a /far/ smaller problem than with UAC's incessant "Cancel
or Allow" messages that drive users to distraction. And with the passage
of time; with ever more refined access policies; and with fewer and
fewer AVC issues with upstream packages, what little AVC violations
there are today will be insignificant or even virtually non-existent in
the future.
However, this goal can only be reached if the /users/ provide feedback
on AVC denials, so that package maintainers and upstream developers are
actually /aware/ of those issues so they can fix them. By disabling
SELinux and refusing to make the small effort required to both learn
about and use policycoreutils, users are actually inhibiting the
progress of the next generation security framework that is designed to
benefit /them/ and the rest of the Linux community.
So in short, I fully support Fedora's decision to remove the option to
disable SELinux during the install process. It can still be disabled
later using system-config-selinux, for those disinterested in making any
contributions to the Free Software that Fedora provides them.
--
K.
http://slated.org
.----
| GPL: You can't scare me with this Gestapo crap.
| I know my rights.
| I want my phone call.
| DRM: Tell me, what good is a phone call ...
| if you're unable to speak?
`----
Fedora release 8 (Werewolf) on sky, running kernel 2.6.23.8-63.fc8
17:21:43 up 216 days, 13:57, 3 users, load average: 0.45, 0.32, 0.28
|
|
