On Mon, Nov 23, 2009 at 2:13 PM, Peter Jones <pjones@xxxxxxxxxx> wrote: > On 11/23/2009 01:24 PM, Gregory Maxwell wrote: >> I haven't tried the the fast user switching in fedora... Hopefully it is >> using some kernel mode secure path to prevent users from stealing each others >> credentials, if it isn't then one should be established for it. Why not use the >> same facility to switch to a system administration desktop, locked down a bit by >> default (use SE linux to make various unsafe user tasks like firefox, >> open office, etc unable to run in this admin context) to discourage >> casual use. > > Wait, you're arguing for this *instead* of finer-grained elevations of privilege > governed by policy files which can be locally overridden safely? I'm arguing for a secure way for users to obtain authoization to perform administrative operations instead of elevating them by default, and expecting the computer operator to go and hunt down the moving target of security holes in every new version of Fedora. This isn't mutually exclusive with finer-grained elevations but would allow finer grained elevations to stay out of the default install: When additional privileged is needed, the system prompts you to authenticate via a secure prompt. At that point if you have the required credentials you could authorize the activity and, optionally, permit that account to perform the same operation in the future. Obviously this kind of one-off permission granting isn't reasonable in a large environment, but large environments are the place where "customize the policy" is a workable answer especially when the systems is secure by default and customization can be applied selectively at the greatest pain points. This is a point I think people miss when advancing the position that it's only to be less secure for convince sake as you can customize your way out of a security hole: Customization has a non-trivial cost. If it didn't we'd all run build our systems from scratch rather than using distributions. To customize you must learn, understand, and track changes from version to version. If you're only customizing to make your systems easier the customization trade-off is easy to balance: When something annoys you, you learn about and then customize only that. But when you need to customize to get the expected security behaviour you must carefully evaluate all the security properties because insecurity is largely invisible until its too late. >> Surely this would be preferable to reducing the security against >> common casual threats. > > I think you've characterized things backwards here. Perhaps. I know that in my environment someone running software on my account to sniff the credentials is less likely than someone sitting at my computer and twiddling knobs while I walk away (but not long enough to get away with rebooting the system). If they could sit at my account they could start up such a sniffer, but the sort of people who would screw with my systems probably wouldn't. On Mon, Nov 23, 2009 at 4:40 PM, Krzysztof Halasa <khc@xxxxxxxxx> wrote: > I'm not talking about reducing security. su, sudo are already suid root > (on most systems at least, especially su). Yes, this is, or at least may > be, a security risk. Admin entering root's password in insecure session > to install software is another security risk. That obviously doesn't > mean I want non-root users to install system software at will. Though this isn't necessary. A facility to obtain elevated authority could be provided which eliminates this risk. > I just say that when it comes to entering the root password (and/or > installing system software), it should be done in a secure manner, > preferably not from within user X session (unless the risk = the fact > of user = root equivalency is explicitly and specifically understood > and accepted). Sorry— I thought you were taking the further position that because entering the password is also a risk, that it's okay to simply give subsets of privileged to users. You're correct. It's a risk which should and can be eliminated. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
