On Sun, 2005-07-17 at 12:15 -0700, Jesse Keating wrote: > Once all the above is possible, then perhaps it could be looked at. > However SELinux really does get in the way of users doing work right > now. Yes I know lots of work is being done on SELinux but the sad truth > is that it isn't really usable in a corporate environment with lots of > users (and uses) without having a couple of full time SELinux managers > on staff. Not very realistic. Those are bugs; something we should be working to fix. > This is what I oppose. Especially if the end user doesn't really know > about it. I think the discussion in the other subthread about a warning/enable dialog is sufficient, no? > Sure we have to trust our users. However it's a conscious effort to > email code to a person. It's unconscious to forget that there is > sensitive material sitting in Public from when in the office I dunno; the idea is you wouldn't want users to use it for sensitive material. If you don't trust your users not to put sensitive material in it you could disable it. I guess that's your decision. > I'd rather make Fedora a Linux distribution that is secure by default > and can be expanded to be more insecure and 'easier' to share when > necessary. I just don't agree that having gnome-user-share available and having users being able to enable it by default in Fedora (including either poking a hole in the firewall or simply not having a firewall) is a security problem in general. For non-managed environments like a personal laptop it should just work. > Linux was attractive to me and lots of others because of the > idea of security first, and in a lot of cases, security over usability. > Please lets not go into the direction where we have Fedora, and then we > have 400 'tweaks' to get to a 'Secure Fedora'. I think this particular security is specific to a managed corporate environment, and in that case there are definitely other tweaks you're going to be making. > I guess this is a step that must be taken to make Fedora usable in > corporate environments. I just hate to see the distro take this > direction. I would also hope that this functionality could be provided > by a package, so that the package could just be excluded from > installation and then there is no possible way for a user to enable it. Sure, removing the package is one way you (the system administrator) could disable it. > But you should know it before being able to start sharing services on > the system. It seems totally arbitrary to me; why shouldn't you need the root password to send email then? Clearly we could do that either using SELinux or the firewall. The whole "we prompted the user for the root password, therefore we can wash our hands of responsibility if anything goes wrong" mentality is wrong, IMO. We should get things to the point where the right thing happens and the root password is never involved. In this case, I think the right thing is the first-time warning dialog. > Of course if there is a firewall set, then the user still > couldn't compile apache in /home/ and start it on a port because the > firewall will block them. If your user is actively malicious they could simply send an email with the data. > I think we disagree on goals to keep in mind w/ the furtherment of > Fedora. I think as a sysadmin, you obviously think as a desktop user. > Not that either of these views are wrong, it is just they are different > views and have different goals. Yes; I think this has been a useful discussion. I appreciate getting your perspective as a sysadmin using Fedora. I guess my bottom line here is: Since for the managed corporate environment you clearly do other tweaks such as making a samba share appear on the desktop, is it so bad for you (if you don't trust your users and want to disable g-u-s) to set a mandatory GConf key to disable it? Probably Sabayon could be enhanced to make this doable from a GUI too (perhaps in the Sabayon window when you click on the Public folder you get an option to disable sharing). -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
