Post by Jon Masters Post by Jon Masters
I think what's needed is a nice little paragraph summarizing what
SELinux is aiming to do, and then the old option of setting permissive
or disabling - users can then set permissive if they prefer to.
Note that when I say this, I'm one of the users who might well turn it
off (well, set permissive) again on future installs. I've lived with
SELinux enforcing on F9 for under two weeks and have found it highly
inhibitive to performing many regular everyday tasks I'm used to.
I wasted about 6 hours on Sunday evening figuring out why an SELinux
policy update in F9 had randomly stopped VPNC from working in a policy
update - that came following days of denials trying to do even simple
stuff. I can't possibly see how thrusting this default upon masses of
otherwise unsuspecting users is a good idea. I'm not saying SELinux
isn't a fantastic idea in certain cases, just not on "the desktop".
Dan, et al, no offense, but we need the option to come back :)
 It had been almost ten years since I last read through all that
documentation. So although I learned a lot about our current policy, and
what has changed over the years in SELinux, so that I could understand
the current targeted policy source, this isn't something regular Fedora
users should have to do in order to be using their computers :)
But you were running a vpnc from the command line not the one launched
by network manager which was not broken. I don't know of many desktop
users who would do this.
So saying it should not be enabled for someone on the desktop because
they would be unable to chcon is contradicted by your statement.
The other problem you talked about is virtmanager also not that likely
to be run by your standard desktop user. We are working with the virt
team to make this simpler. libvirtd is not unconfined and running qemu
as a user is unconfined. Running qemu from libvirtd is still confined
and is fixed by correct labeling. Hopefully the virt-manager people
will assign an appropriate context at creation time, and/or default
virtual machines to /var/lib/libvirt/images where they will be labeled
The only confinement we have on real "Desktop users" by default. IE
Users that do not know the root password, is the executable memory
checks. These have been a pain in the past but they are getting better.
They usually are caused by badly written programs or bad labels on
programs that require java, wine, mono. But these checks can
successfully stop buffer overflow attacks. So they are important.
Other places where user confinement hits is through the use of
PolicyKit/Hal/dbus applications where code gets run as root on the users
behalf. PolicyKit/Hal/Dbus are great steps forward in usability for
users but should be treated as potential threats to the security of the
system. As a bug in anyone of these new apps could lead to a root
exploit. So SELinux needs to be used to confine the new desktop apps.
In Rawhide and Fedora 9 you can now actually confine the user using some
of the stuff I have been talking about in my blogs and presentations so
if you have a managed desktop user, someone who does not know the root
password, you can use these to really lock down the user on a system.
guest, xguest, user and staff are all available in Fedora 9 as well as
the unconfined user.