Request to re-add option to disable SELinux

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jon Masters wrote:
> On Wed, 2008-07-02 at 16:29 -0400, Jon Masters wrote:
> 
>> 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[0] 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 :)
> 
> Jon.
> 
> [0] 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
correctly automatically.


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.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhtFMwACgkQrlYvE4MpobN83wCgjsh+UHp5znNJ2j16chxg4yuj
ORUAniY8bZ8qru/SFWyn023fpQUfe2Zt
=RMsb
-----END PGP SIGNATURE-----