What are these for?

[lee]

Ian Malone <ibmalone at gmail.com> writes:

> On 21 November 2012 14:38, lee <lee at yun.yagibdah.de> wrote:
> I don't pretend to have the answers to all your questions, but:
>
>> Matthew Miller <mattdm at fedoraproject.org> writes:
>>
>>> On Wed, Nov 21, 2012 at 12:37:47PM +0100, lee wrote:
>
>>> 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?
>>
>
> You don't really, but this is why policy kit is supposed to handle the
> authentication and tell you what access is being requested.

So it's a means of giving users a false impression of being secure.

>>>> > 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.
>>
>
> How does it ever get changed then?

I set it in the BIOS if needed and chrony keeps it on track.

> You might answer that you use ntpd (in which case you are trusting
> people on the internet),

Time, in this context and for practical purposes, is merely something
ppl have agreed on.  I don't really see where trust is involved with
that.

> but not all systems can (maybe no net access or embedded) or do all
> the time.

Then they might find other ways to deal with setting the time, or just
don't set it, whatever is needed.

> In theory if you really wanted to lock it down you could. Except root
> can change it and root *is* a user.

I don't need to lock it down, it already is by default.  Root is the
only user who can change the time, letting aside circumventing it by
setting it in the BIOS or booting something to change it.  It wasn't my
example, and I don't think it's a good one.

I only wanted to know if I need to run polkitd and what benefits it has
for me to do that and if I can disable it because I don't want to waste
resources with running things I don't need.

>>>> > 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.
>>
>
> But not all the time. You don't use you password to run emacs, emacs
> asks for permission to do something if it needs it, polkit looks at
> the request and whether the user is allowed to give it that permission
> and if so asks the user if it's okay.

Why not all the time?  I could have forgotten to lock my screen, so
emacs would have to ask if it is allowed to display a buffer ...

Is it ok for emacs (i. e. gnus) to mail out (parts of) my diary to
someone or does it need to ask for permission?  Is it ok for gnus to let
me answer your posting or does it need to ask for permission?  Perhaps
it's someone else doing it or perhaps what I'm sending contains security
relevant information --- and that information might even be added only
later by the MTA giving away my IP address.  Perhaps the MTA needs to
ask for permission to handle every single mail that goes through it?

Who decides?  How do I know that every application using polkit does
only what it's supposed to do?

>>>> 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.
>>
>
> ?
> "distinctive, separate dialog box" and "spoofing this sort of dialog
> is a concern."
> The answer to that is to prevent spoofing. If your GUI is compromised
> then what you type is compromised too.

And when you prevent spoofing and when every application only does what
it's supposed to, then why would you need polkit?

How closely do users look at just another dialog box and how much
attention do they pay to them?

>>>> 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?
>>
>
> Because polkit is confirming the user at the console before granting
> the extra permission. It can remember that for a while.

No it doesn't.  It cannot identify users, it only can verify passwords.

However, what difference does it make?  If something relevant for
security can be done with this or that password, it doesn't matter which
password is supplied.

And where's the limit?  Can I tag files so that emacs (or another
application) would request special permissions to display them?  Do I
want to do that kind of micro management and have to enter passwords all
the time?  Do I want to have many different passwords for accessing many
different (types) of files?  Do I want to enter a password to display
the buffer menu or to run ls?  For all I know, someone else could try to
get a listing of the files in my home directory, so the user would need
to be verified first ...  Is it relevant for security when the time is
being changed?

>> 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 ...
>>
>
> You're not thinking fine-grained. And yes, application security is an
> issue with any elevated privilege application, but it doesn't get
> permission to do everything as root. It gets time-limited permission
> to do a specific thing that it asked for and that the user has the
> authority to grant.

And in which way is this better than my emacs session (or another
application) never getting such a permission?

>>> 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.
>>
>
> No. su means running things unrestricted.

It also means being aware of that and not entering passwords everywhere.
It means that emacs and other applications I'm running as ordinary user
remain restricted and never get extended permissions and that those
applications I'm running as root are unaffected by whatever I might have
done as ordinary user (who then suddenly might give them extended
permissions if I was using polkit).

So what results to more restriction and what is less insecure?

> Also the equivalent is not su, it's actually suid, which does rely on
> the individual application to assume and drop privileges responsibly.

In which way is relying on an application that uses polkit to do only
what it is supposed to do better or different?  I can see it being
better forcing apps that are setuid root to request a password, yet they
don't need to do that when they already have the permissions they're
asking for.

If I understand the desgin correctly, using polkit is voluntary for an
application and it's up to the application to do whatever when it
receives extended permissions.  When the application already has
extended permissions, it doesn't need to ask and can do whatever anyway.

So what would be needed is something not voluntary which gets in the way
of every application regardless of the permissions the application has
and no matter what it wants to do, asks for permission to do one thing
in particular and monitors the application so it cannot do anything else
than what permissions for have been granted.  Maybe selinux does (try)
that, except that it doesn't let apps ask for permission?

Polkit doesn't do that --- or does it? --- and what it mostly does is
getting users used to enter their passwords.  It removes the separation
between apps that ordinary users run and do whatever with and (in some
cases the same) apps much more carefully run by root.  Both is bad.

So what's the point of polkit?  Allowing ordinary users to change the
time?  Every user could have their own time totally independent of the
system time and do whatever they want with it :)


-- 
Fedora 17