Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> writes: > On Wed, Nov 21, 2012 at 12:37:47PM +0100, lee wrote: >> > This records secure log messages from the kernel, including SELinux alerts. >> > You don't technically _need_ it, but these are important messages. >> Why does it need it's own daemon rather than using /var/log/messages >> where I might even see the messages? And aureport says there have been > > Because the syslog interface isn't secure. How come? Only root can read the logfile. >> 8765 events within 17 days. How am I supposed to keep track of that >> with over 500 events per day in messages I never see? How would I >> reasonably read these messages? > > That's a classic sysadmin's dilemma. It would be nice to have some good open > source processing, analysis, and correlation tools. Since we don't have them, how useful is it? >> Will it at least send me an email when something happens I should know >> about? > > You could configure it that way. Is there some documentation about this? >> So mcelog *might* be useful if I have problems with kernel panics, which >> I don't. > > If you are certain your hardware will never have any problems in the future, > or if you don't mind your system not responding to them properly, or if > you're running in a VM, you can certainly turn it off. Well I can't predict the future. What does mcelog actually do to prevent hardware problems or to make the system respond to them properly --- whatever "properly" means? >> > Polkit allows applications to use root permissions for fine-grained >> > actions rather than running as root all the time. >> So they become like 1/4, 3/8 or 1/2 root and do something only root should >> be allowed to do? >> > That increases security. >> How? It seems to do the opposite. > > By only asking for and using privileged access when required. That's a > fundamentally good idea. And how do you know or make sure that some software uses your password only for that? >> > For example, a timezone applet can show you the time as a regular user >> > and only require extra authentication to change it. >> Regular users must not change the system time. It's on UTC and kept on >> track with chrony. > > Well, exactly. That's why you would need extra authentication to change it. Users are not supposed to change it at all, not even with extra authentication. >> > However, if you don't want or need this functionality, applications >> > are supposed to gracefully fall back to requiring root. >> So for example instead of ls or emacs becoming only 1/4 root, I would >> have to run them as root? And if I don't run them as root, I'd have to > > Since neither ls nor emacs is written to use polkit, running them as root > when you need to access a particular file is in fact the only option you > have. Then polkit doesn't do me any good. Even if emacs and ls were using it, it would be very annoying having to enter a password all the time. >> Neither ls nor emacs ever asked me for extra authentication. And how >> would it increase security if I entered the password for root into >> arbitrary applications whenever they ask me for it? > > It wouldn't. In a GUI, polkit has a distinctive, separate dialog box it uses > to ask for authentication. It's absolutely true that spoofing this sort of > dialog is a concern. So yes, it decreases security instead of increasing it. >> It certainly does decrease security getting users used to enter the root >> password everywhere. Polkit should be deprecated. > > In the typical configuration on Fedora, users in the `wheel` group are asked > to provide their *own* password for this sort of access. What difference does it make which password is supplied when with the password things can be done that are relevant for security? Why should I give my password again when I'm already logged in and the system knows who I am? And what if the user in the wheel group wants to use emacs to edit some configuration file that can only be modified by root? Will they be asked for their password? And if they are, is it more secure to perform this operation when their emacs loads a large ~/.emacs that might contain options which could make it insecure to give privileges to emacs? And my emacs session is running since eleven days now and who knows what I've been doing with it that could turn out fatal once privileges are given to emacs. It may run month or two or longer and I might not remember having done anything ... > If you have an alternate implementation that solves the problems polkit was > meant to solve in a demonstrably better way, develop the code and propose it > as a Feature for a future Fedora. The alternate implemantation is su. It's much simpler and more secure already by being much simpler than polkit. It's also much more efficient. Polkit is insecure by design because it gets users used to enter their password everywhere. -- Fedora 17 -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
