What are these for?

[lee]

Reindl Harald <h.reindl at thelounge.net> writes:

> Am 21.11.2012 15:38, schrieb lee:
>> Matthew Miller <mattdm at fedoraproject.org> 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