1 |
On Wed, Jan 16, 2013 at 12:34 PM, Kevin Chadwick <ma1l1ists@××××××××.uk> wrote: |
2 |
>> > |
3 |
>> > I never meant it is rubbish as such but I saw it as rediculously |
4 |
>> > inferior to sudo before I even read this. |
5 |
>> > |
6 |
>> > http://drfav.wordpress.com/2012/05/11/the-quest-towards-trusted-client-applications-a-rambling/ |
7 |
>> |
8 |
>> Perhaps I'm misunderstanding, but that is talking about a specific set |
9 |
>> of problems that I don't think polkit was actually designed to |
10 |
>> address. Polkit is basically for authenticating applications via |
11 |
>> users, not the applications themselves. If I am running app foo, and |
12 |
>> app foo wants to inhibit hibernation; polkit is there to ask 'hey is |
13 |
>> antarus allowed to inhibit hibernation? Does antarus need to auth to |
14 |
>> do so? Is antarus already authenticated? Now one may say 'hey but I |
15 |
>> only want certain applications to hibernate' and while that may be an |
16 |
>> interesting problem...I don't think the existing polkit intends to |
17 |
>> solve it. |
18 |
>> |
19 |
> |
20 |
> The point is that it is inferior in every way and so pointlessly causing |
21 |
> more work and other problems not to mention guaranteed increased |
22 |
> security risk having extra code constantly running as root. Why was it |
23 |
> started, rather than contributing to sudo. |
24 |
|
25 |
I'm glad you think it is inferior, but i don't really buy your argument. |
26 |
|
27 |
> |
28 |
>> > |
29 |
>> > |
30 |
>> >> It is however, designed for graphical UI single-seat systems. |
31 |
>> >> Its command line support sucks (they only added a CLI auth agent in |
32 |
>> >> May) and it is not well adopted. Multi-user systems do not work well |
33 |
>> >> with polkit. Certainly with polkit and dbus you can allow users to |
34 |
>> >> take more specific action without complex wrappers, setuid scripts, or |
35 |
>> >> sudo. |
36 |
>> > |
37 |
>> > Except you can't, it only encourages more coarse grained approaches, |
38 |
>> > less useful commands available and devs to learn an api rather than C |
39 |
>> > and simply moves code into a far less secure mechanism and increases the |
40 |
>> > chance that the code will not be well designed to the task at hand and |
41 |
>> > running as root. It can be a real pain to work out exactly what polkit |
42 |
>> > allows and you cannot just edit it to suit your application and it |
43 |
>> > completely ignores the existing unix security technologies with |
44 |
>> > brilliant track records. |
45 |
>> |
46 |
>> One could say that 'a discrete set of APIs will be no match for |
47 |
>> the..fined grain control that is the command line!' I would agree. I |
48 |
>> don't agree that this is a one-size fits all deal though. There can be |
49 |
>> a command line AND an API. I'd rather grant my users 'access to the |
50 |
>> install authenticated packages action' than have to own a complex sudo |
51 |
>> rule. |
52 |
>> |
53 |
> |
54 |
> How about uncommenting a line that does so. All you are buying into is |
55 |
> a default setup. |
56 |
|
57 |
App authors don't ship configs like that though. Does apt ship a sudo |
58 |
config? Does anything? |
59 |
The nice thing about (really dbus, not so much polkit per se) is that |
60 |
I can offer a nice API for applications that is not command line |
61 |
based. No parsing strings, no 'oh this tool writes to stderr, that one |
62 |
writes to stdout, I need to ignore these lines...) |
63 |
|
64 |
> |
65 |
>> I don't understand 'the APIs that coders will learn instead of C.' Can |
66 |
>> you elaborate? Polkit has a C api... |
67 |
>> |
68 |
> |
69 |
> It has an api that is simply not needed? Small tools are better. |
70 |
|
71 |
You prefer the commandline api? (one byte for return values, half of |
72 |
which are signals) |
73 |
|
74 |
> |
75 |
>> I don't understand how the code will 'not be well designed to the |
76 |
>> application at hand.' I mean ideally the API and the CLI are |
77 |
>> essentially just wrappers around the same library of functions. |
78 |
>> |
79 |
> |
80 |
> If you search for sites that evaluate polkit you will see that it is |
81 |
> considered to encourage granting more permissions than necessary rather |
82 |
> than coding a specific tool. |
83 |
|
84 |
Hah, because no one uses sudo to grant extraordinarily broad permissions. |
85 |
|
86 |
> |
87 |
>> Its unclear how polkit is 'hard'. Now it *is* new, and I will concede |
88 |
>> you will have to read some manpages. However i don't think the |
89 |
>> concepts are difficult. |
90 |
> |
91 |
> Man pages won't help with polkit and it actually generally ships with no |
92 |
> configs by default. |
93 |
|
94 |
In Ubuntu Precise.. |
95 |
|
96 |
/etc/polkit-1/* |
97 |
This contains machine and site specific configuration. Ubuntu ships a |
98 |
configuration such that anyone in the 'sudo' group is a 'polkit admin' |
99 |
and can take most actions by entering their (not roots) password. |
100 |
|
101 |
/usr/share/polkit-1/actions/* |
102 |
This directory contains all available actions that polkit might auth. |
103 |
|
104 |
for example, on ubuntu: |
105 |
org.debian.apt.policy contains the policies for apt. |
106 |
|
107 |
<action id="org.debian.apt.install-or-remove-packages"> |
108 |
<description gettext-domain="aptdaemon">Install or remove |
109 |
packages</description> |
110 |
<message gettext-domain="aptdaemon">To install or remove software, |
111 |
you need to authenticate</message> |
112 |
<defaults> |
113 |
<allow_any>auth_admin</allow_any> |
114 |
<allow_inactive>auth_admin</allow_inactive> |
115 |
<allow_active>auth_admin_keep</allow_active> |
116 |
</defaults> |
117 |
</action> |
118 |
|
119 |
All of this is explained in man polkit. |
120 |
|
121 |
> |
122 |
>> There are plenty of helpers (pkcheck springs |
123 |
>> to mind) that assist the user in figuring out what is 'allowed'. |
124 |
> |
125 |
> I know about pkaction, the problem is that the actions tells you next to |
126 |
> nothing about what is actually allowed. I haven't time to dig out one |
127 |
> of the rediculous comments from the source now unfortunately. With |
128 |
> small tools it's much better all round. |
129 |
|
130 |
Really? Please enumerate what giving someone access to 'emerge' can do. |
131 |
|
132 |
> |
133 |
>>The |
134 |
>> configuration for polkit is all in /usr/share and /etc. The configs |
135 |
>> are configurable..again in /etc. This is not something I would term |
136 |
>> 'challenging.' |
137 |
>> |
138 |
> |
139 |
> Generally there aren't any rules files, the defaults are built in and |
140 |
> your expected to use a webbrowser, even on a server?!?! You shouldn't |
141 |
> run lynx never mind X on a server. |
142 |
|
143 |
The configs are all ASCII on disk...The manpages are availablie.. |
144 |
|
145 |
> |
146 |
> If some configs are in /usr/share rather than /etc perhaps that explains |
147 |
> why one tutorial said so and it has no effect on some systems. |
148 |
|
149 |
The actions are in /usr/share, the machine / site configs are in /etc/polkit-1/ |
150 |
|
151 |
> |
152 |
>> > |
153 |
>> > You could try to argue that many eyes will look at a central piece of |
154 |
>> > code but in fact less implementations will likely mean less eyes and |
155 |
>> > just assumption that a guy who got JS through as a config language has |
156 |
>> > everything covered. Granted, unmaintained code running as root may be |
157 |
>> > higher with sudo but if it needs maintaining, should it be running as |
158 |
>> > root at all or is it actually simply doing too much. |
159 |
>> |
160 |
>> Its not a matter of many-eyes. It is a matter of 'some other guy is in |
161 |
>> charge of maintaining that component.' It means I can focus on stuff |
162 |
>> that matters, and not focus on 'wrappers to make random things work.' |
163 |
> |
164 |
> That can apply to sudo, would be more secure and cause less problems |
165 |
> and you see why I brought it up and asked why not, because that should |
166 |
> be the case. |
167 |
|
168 |
No one maintains the sudo wrappers though. Someone maintains the |
169 |
polkit actions. That someone also happens to be the upstream author. |
170 |
|
171 |
> |
172 |
>> Is the polkit maintain any less 'trustworthy' than the gnome |
173 |
>> maintainers? the kde maintainers? the kernel maintainers? At the end |
174 |
>> of the day my machines are running software from thousands of |
175 |
>> contributors. |
176 |
>> |
177 |
> |
178 |
> I think that has been demonstrated and we are talking about root code |
179 |
> and sudo is never running as such. |
180 |
|
181 |
I don't follow... |
182 |
|
183 |
> |
184 |
>> > |
185 |
>> >> My package manager can have a polkit action like 'install a |
186 |
>> >> signed package' and I can grant the user access to do that, but not |
187 |
>> >> access to install unsigned packages (root exploit there...) or run |
188 |
>> >> other dangerous apt commands. It comes built into apt, so I don't have |
189 |
>> >> to write extra wrappers. |
190 |
>> > |
191 |
>> > That would be the default and wouldn't even need the command line |
192 |
>> > argument control of sudo. Just allowing updates is apt-get update. |
193 |
>> |
194 |
>> Er, apt-get update downloads new Packages files, it doesn't install |
195 |
>> any additional software. apt-get *upgrade* will. These are separate |
196 |
>> *actions*. |
197 |
>> |
198 |
> |
199 |
> /usr/bin/sudo /usr/bin/aptitude |
200 |
> /usr/bin/sudo -t experimental install iceweasel |
201 |
> |
202 |
> You could even make synaptic use a _synaptic group just to install. |
203 |
> |
204 |
>> > |
205 |
>> > In fact I have a debian system where experimental iceweasel is |
206 |
>> > installable but nothing else. I have an Arch system where the only |
207 |
>> > kernel updateable is a signed by me when offline kernel and polkit is |
208 |
>> > disabled as I don't have the time to keep track of what it is |
209 |
>> > permitting and code comments weren't helpful there. |
210 |
>> |
211 |
>> Look if you don't trust polkit, or you dislike it, or you just don't |
212 |
>> have time to understand how it works; that is cool. 18 months ago I |
213 |
>> was in the same camp. Polkit is not strictly required. But don't go |
214 |
>> spouting about how much it sucks unless you have actually *used* it. |
215 |
>> |
216 |
> |
217 |
> I do understand and I asked on the kde lists how to get kde 4.9 to |
218 |
> switch back to using kdesudo by default. NOONE replied except a |
219 |
> gentoo user called Duncan who was interested in the answer |
220 |
> himself and was very helpful and told me how to remove rather than |
221 |
> disable polkit if I don't mind compiling obviously. I worry more |
222 |
> problems will be brought to bear and a lot of development done that |
223 |
> could have been spent better. |
224 |
> |
225 |
> |
226 |
>> In some cases (like most places where multiple users are present) it |
227 |
>> is in fact terrible. We wanted to do some 'unique' things with |
228 |
>> mounting of USB hardware with polkit (and udisks) and found it |
229 |
>> basically impossible to make work over ssh. I ended up going with the |
230 |
>> 'sudo make me a sandwich' route. Sometimes that is necessary. |
231 |
>> |
232 |
> |
233 |
> Same here but not over ssh, though some of the functionality has since |
234 |
> been put back. |
235 |
> |
236 |
> We have digressed from the point though, unless there is a real need |
237 |
> for polkit that I have missed? |
238 |
> |
239 |
> I've read Polkit's predecessor was abandoned because it was a bad |
240 |
> development and yet has been basically renamed to get away from the |
241 |
> flak. |
242 |
> |
243 |
> Is it just misunderstanding of what sudo has to offer that drives |
244 |
> polkit, that seems rife wherever polkit and sudo are mentioned in |
245 |
> lists, often to the point of confusing sudo with su. |
246 |
> |
247 |
> It may become a real shame in history that many threads seem to believe |
248 |
> sudo makes systems less secure when in fact it is polkit. |
249 |
> |
250 |
> So does anyone know for sure why sudoers with rules in aside from allow |
251 |
> all were dropped and if that was a bad decision? I imagine users are |
252 |
> better at avoiding sudo pitfalls these days and so maybe it should be |
253 |
> brought back? |
254 |
> |
255 |
> -- |
256 |
> _______________________________________________________________________ |
257 |
> |
258 |
> 'Write programs that do one thing and do it well. Write programs to work |
259 |
> together. Write programs to handle text streams, because that is a |
260 |
> universal interface' |
261 |
> |
262 |
> (Doug McIlroy) |
263 |
> _______________________________________________________________________ |
264 |
> |