Reindl Harald <h.reindl@xxxxxxxxxxxxx> writes: > Am 21.11.2012 15:38, schrieb lee: >> Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> writes: >>> Because the syslog interface isn't secure. >> >> How come? Only root can read the logfile. > > THE INTERFACE > > it is not trustable which process generates / fakes a record > also you do not want all from /var/log/secure mixed in messages Hm yes, that's true. >>> 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? > > useful enough because /var/log/secure is a more sensible > thing than "normal" messages from /var/log/messages What I mean is: How useful is it when we never do anything with these messages? >>>> 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? > > man crontab > man grep > man echo > > any output from a application / script started via crond > goes into a mail to root It goes to the user who created the crontab. What messages would I want to see? >> And how do you know or make sure that some software uses your password >> only for that? > > if you do not trust the author do not use the software > > but you refuse to understand the main difference having > things permanently running as root or only request root > pwd if it is really needed AND you can refuse to permit No, I'm seeing the difference and ask myself how relevant that is. With polkit, something requests the root password to do something and something happens in the background or maybe not and in any case I don't really know what's going on or not and what happens with the password. With su, I have bash running as root in one of the windows in tmux and everything I do from there runs as root. I'm not giving away the password other than to su and there aren't any hidden things that might or might not happen in the background. In both cases, "bad" software could do harm. So what's the relevant difference? >> Users are not supposed to change it at all, not even with extra >> authentication. > > so read manpages and restrict if things are allowed > the sudo way with users password and for the things > needing the root password: they CAN'T at all > >> 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. > >>> 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. > > NO how do you come to that conclusion? It gets users used to just enter their password whenever they are asked for it. > it is about you if you enter root password in a randomly popping up > window Yes, and once users are used to do that, they just do it. >> 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? > > what about drive-by-attacks? I don't know what you mean by that. > what about leave the room for a minute and forget lock the screen? If I had to lock the screen, I would. Other than that, with physical access to a computer the person having it can do whatever they want anyway. > what about malware trying things with your current permissions It can do that in any case. > ANY security relevant task has to be confirmed with > a password independent if you are logged in or not Starting/running a web browser is a security relevant task. "Web browser" is only a place holder. Fill in other software that might be security relevant. I'm running the web browser as a different user so it doesn't have access to my data. I have another application that I would like to run as a different user but I can't because that user doesn't have access to sound for unknown reasons. It must be some sort of messy setup that Fedora has, trying to make something more secure and achieving the opposite; it worked fine with Debian. Do you have any idea how to solve this problem? >> 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. > > users entering their password EVERWHERE have already lost > ANY security fight - sorry, but this argumentation is invalid > because ORDINARY user tasks do NOT request a password Your logic is flawed. It doesn't matter that some things don't require entering a password. (On a side note: Starting a web browser or starting emacs would require a password because a web browser is a security risk and because emacs could display and modify files that nobody but their owner is supposed to see or to modify. Depending on what's in ~/.emacs, starting emacs might be a security risk as well. Then when you have started the web browser or emacs and entered a password for it and it wants to do something it will just do that, if you want it or not. How do you cover that? Having applications doing something requesting permission for it is the wrong approach. Something independent would have to catch the applictions trying to do something and deny it unless they get permission for it. How do I know that there isn't a bug in the web browser or in emacs that can be used to make it transfer my data to someone?) What matters is that getting users used to enter their password everywhere decreases security. How much do ordinary users know about things like that, and how much do they care? When their computer tells them "I need your password to do this or that" and when they're used to it, they will just enter it to get on with whatever they are doing. I recently did it on a Mac when I put vlc on it, and I didn't have any way to find out if I actually should enter the password or better not, so I just entered it to get on with it. IIRC it didn't even tell me what it was needed for. What choice do you have? Reverse-engineer macos to try to figure out what's going on? You say users entering their passwords just like that have already lost all security. Then why get them used to do exactly that? You can't say it would increase security and you'd have to agree that it decreases security. There's even a fairy tale along these lines: It's about someone alerting his people about dangerous wolves coming, just for the fun of scaring the ppl up. He does that a couple times, and when the wolves are actually coming, nobody believes him anymore and the wolves kill all the sheep. You may argue that the fairy tale is invalid because ordinary shephearding doesn't request or involve wolves. Then the wolves will be LTAO while feasting on the sheep. Anyway, let's assume I wanted to use polkit. I need at least bash, ls, cp, less, yum, find and emacs to work with that --- and some others that don't come to mind atm. Are these going to be bloated up to support polkit? Do you seriously want me to enter my password every time though it would be useless anyway? Do you really think it would be a good idea to have files which are edited by root only mixed in with the other 56 buffers I have currently in my emacs session? I wouldn't want to do that; root has his own 34 buffers in his own emacs, kept nicely seperate. I might have to enter a password to switch buffers or even to see the buffer menu ... I'd rather get the problem with the sound for the second user fixed and disable polkit. That actually *would* inrease security. -- 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
