On Wed, Jan 16, 2013 at 12:34 PM, Kevin Chadwick <ma1l1i...@yahoo.co.uk> wrote:
>> >
>> > I never meant it is rubbish as such but I saw it as rediculously
>> > inferior to sudo before I even read this.
>> >
>> > http://drfav.wordpress.com/2012/05/11/the-quest-towards-trusted-client-applications-a-rambling/
>>
>> Perhaps I'm misunderstanding, but that is talking about a specific set
>> of problems that I don't think polkit was actually designed to
>> address. Polkit is basically for authenticating applications via
>> users, not the applications themselves. If I am running app foo, and
>> app foo wants to inhibit hibernation; polkit is there to ask 'hey is
>> antarus allowed to inhibit hibernation? Does antarus need to auth to
>> do so? Is antarus already authenticated? Now one may say 'hey but I
>> only want certain applications to hibernate' and while that may be an
>> interesting problem...I don't think the existing polkit intends to
>> solve it.
>>
>
> The point is that it is inferior in every way and so pointlessly causing
> more work and other problems not to mention guaranteed increased
> security risk having extra code constantly running as root. Why was it
> started, rather than contributing to sudo.
I'm glad you think it is inferior, but i don't really buy your argument.
>
>> >
>> >
>> >> It is however, designed for graphical UI single-seat systems.
>> >> Its command line support sucks (they only added a CLI auth agent in
>> >> May) and it is not well adopted. Multi-user systems do not work well
>> >> with polkit. Certainly with polkit and dbus you can allow users to
>> >> take more specific action without complex wrappers, setuid scripts, or
>> >> sudo.
>> >
>> > Except you can't, it only encourages more coarse grained approaches,
>> > less useful commands available and devs to learn an api rather than C
>> > and simply moves code into a far less secure mechanism and increases the
>> > chance that the code will not be well designed to the task at hand and
>> > running as root. It can be a real pain to work out exactly what polkit
>> > allows and you cannot just edit it to suit your application and it
>> > completely ignores the existing unix security technologies with
>> > brilliant track records.
>>
>> One could say that 'a discrete set of APIs will be no match for
>> the..fined grain control that is the command line!' I would agree. I
>> don't agree that this is a one-size fits all deal though. There can be
>> a command line AND an API. I'd rather grant my users 'access to the
>> install authenticated packages action' than have to own a complex sudo
>> rule.
>>
>
> How about uncommenting a line that does so. All you are buying into is
> a default setup.
App authors don't ship configs like that though. Does apt ship a sudo
config? Does anything?
The nice thing about (really dbus, not so much polkit per se) is that
I can offer a nice API for applications that is not command line
based. No parsing strings, no 'oh this tool writes to stderr, that one
writes to stdout, I need to ignore these lines...)
>
>> I don't understand 'the APIs that coders will learn instead of C.' Can
>> you elaborate? Polkit has a C api...
>>
>
> It has an api that is simply not needed? Small tools are better.
You prefer the commandline api? (one byte for return values, half of
which are signals)
>
>> I don't understand how the code will 'not be well designed to the
>> application at hand.' I mean ideally the API and the CLI are
>> essentially just wrappers around the same library of functions.
>>
>
> If you search for sites that evaluate polkit you will see that it is
> considered to encourage granting more permissions than necessary rather
> than coding a specific tool.
Hah, because no one uses sudo to grant extraordinarily broad permissions.
>
>> Its unclear how polkit is 'hard'. Now it *is* new, and I will concede
>> you will have to read some manpages. However i don't think the
>> concepts are difficult.
>
> Man pages won't help with polkit and it actually generally ships with no
> configs by default.
In Ubuntu Precise..
/etc/polkit-1/*
This contains machine and site specific configuration. Ubuntu ships a
configuration such that anyone in the 'sudo' group is a 'polkit admin'
and can take most actions by entering their (not roots) password.
/usr/share/polkit-1/actions/*
This directory contains all available actions that polkit might auth.
for example, on ubuntu:
org.debian.apt.policy contains the policies for apt.
<action id="org.debian.apt.install-or-remove-packages">
<description gettext-domain="aptdaemon">Install or remove
packages</description>
<message gettext-domain="aptdaemon">To install or remove software,
you need to authenticate</message>
<defaults>
<allow_any>auth_admin</allow_any>
<allow_inactive>auth_admin</allow_inactive>
<allow_active>auth_admin_keep</allow_active>
</defaults>
</action>
All of this is explained in man polkit.
>
>> There are plenty of helpers (pkcheck springs
>> to mind) that assist the user in figuring out what is 'allowed'.
>
> I know about pkaction, the problem is that the actions tells you next to
> nothing about what is actually allowed. I haven't time to dig out one
> of the rediculous comments from the source now unfortunately. With
> small tools it's much better all round.
Really? Please enumerate what giving someone access to 'emerge' can do.
>
>>The
>> configuration for polkit is all in /usr/share and /etc. The configs
>> are configurable..again in /etc. This is not something I would term
>> 'challenging.'
>>
>
> Generally there aren't any rules files, the defaults are built in and
> your expected to use a webbrowser, even on a server?!?! You shouldn't
> run lynx never mind X on a server.
The configs are all ASCII on disk...The manpages are availablie..
>
> If some configs are in /usr/share rather than /etc perhaps that explains
> why one tutorial said so and it has no effect on some systems.
The actions are in /usr/share, the machine / site configs are in /etc/polkit-1/
>
>> >
>> > You could try to argue that many eyes will look at a central piece of
>> > code but in fact less implementations will likely mean less eyes and
>> > just assumption that a guy who got JS through as a config language has
>> > everything covered. Granted, unmaintained code running as root may be
>> > higher with sudo but if it needs maintaining, should it be running as
>> > root at all or is it actually simply doing too much.
>>
>> Its not a matter of many-eyes. It is a matter of 'some other guy is in
>> charge of maintaining that component.' It means I can focus on stuff
>> that matters, and not focus on 'wrappers to make random things work.'
>
> That can apply to sudo, would be more secure and cause less problems
> and you see why I brought it up and asked why not, because that should
> be the case.
No one maintains the sudo wrappers though. Someone maintains the
polkit actions. That someone also happens to be the upstream author.
>
>> Is the polkit maintain any less 'trustworthy' than the gnome
>> maintainers? the kde maintainers? the kernel maintainers? At the end
>> of the day my machines are running software from thousands of
>> contributors.
>>
>
> I think that has been demonstrated and we are talking about root code
> and sudo is never running as such.
I don't follow...
>
>> >
>> >> My package manager can have a polkit action like 'install a
>> >> signed package' and I can grant the user access to do that, but not
>> >> access to install unsigned packages (root exploit there...) or run
>> >> other dangerous apt commands. It comes built into apt, so I don't have
>> >> to write extra wrappers.
>> >
>> > That would be the default and wouldn't even need the command line
>> > argument control of sudo. Just allowing updates is apt-get update.
>>
>> Er, apt-get update downloads new Packages files, it doesn't install
>> any additional software. apt-get *upgrade* will. These are separate
>> *actions*.
>>
>
> /usr/bin/sudo /usr/bin/aptitude
> /usr/bin/sudo -t experimental install iceweasel
>
> You could even make synaptic use a _synaptic group just to install.
>
>> >
>> > In fact I have a debian system where experimental iceweasel is
>> > installable but nothing else. I have an Arch system where the only
>> > kernel updateable is a signed by me when offline kernel and polkit is
>> > disabled as I don't have the time to keep track of what it is
>> > permitting and code comments weren't helpful there.
>>
>> Look if you don't trust polkit, or you dislike it, or you just don't
>> have time to understand how it works; that is cool. 18 months ago I
>> was in the same camp. Polkit is not strictly required. But don't go
>> spouting about how much it sucks unless you have actually *used* it.
>>
>
> I do understand and I asked on the kde lists how to get kde 4.9 to
> switch back to using kdesudo by default. NOONE replied except a
> gentoo user called Duncan who was interested in the answer
> himself and was very helpful and told me how to remove rather than
> disable polkit if I don't mind compiling obviously. I worry more
> problems will be brought to bear and a lot of development done that
> could have been spent better.
>
>
>> In some cases (like most places where multiple users are present) it
>> is in fact terrible. We wanted to do some 'unique' things with
>> mounting of USB hardware with polkit (and udisks) and found it
>> basically impossible to make work over ssh. I ended up going with the
>> 'sudo make me a sandwich' route. Sometimes that is necessary.
>>
>
> Same here but not over ssh, though some of the functionality has since
> been put back.
>
> We have digressed from the point though, unless there is a real need
> for polkit that I have missed?
>
> I've read Polkit's predecessor was abandoned because it was a bad
> development and yet has been basically renamed to get away from the
> flak.
>
> Is it just misunderstanding of what sudo has to offer that drives
> polkit, that seems rife wherever polkit and sudo are mentioned in
> lists, often to the point of confusing sudo with su.
>
> It may become a real shame in history that many threads seem to believe
> sudo makes systems less secure when in fact it is polkit.
>
> So does anyone know for sure why sudoers with rules in aside from allow
> all were dropped and if that was a bad decision? I imagine users are
> better at avoiding sudo pitfalls these days and so maybe it should be
> brought back?
>
> --
> _______________________________________________________________________
>
> 'Write programs that do one thing and do it well. Write programs to work
> together. Write programs to handle text streams, because that is a
> universal interface'
>
> (Doug McIlroy)
> _______________________________________________________________________
>
