-----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----- -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list