Plans for revamping Kiosk and KAuthorized

[Dario Freddi]

Hello people,

as I probably have anticipated in a previous thread, at Tokamak 3 me and Aaron 
took the chance to discuss a bit the future of Kiosk and KAuthorized, now that 
we have a working authorization framework in KDELibs.

First of all let me say that KAuth is not an in-place replacement to 
KAuthorized: however it can be used to make KAuthorized more secure, future 
proof, and simple. Here is my proposal on how to do it. This would be divided 
in 3 steps.

*1. Revamp KAuthorized by using KAuth as the backend*
At the moment Kiosk is based upon some KConfig files. This is not so great 
when it comes to security and flexibility, and especially when we can rely on 
something which was made exactly with this purpose. What would happen?

 - Ditch away the KConfig code, and move it to real KAuth actions, in the 
domain org.kde.kiosk. Checking if the action "crap" is authorized would turn 
into checking for authorization for the action org.kde.kiosk.action.crap.
 - This way, the action policy would be installed system-wide, configurable by 
administrator on a per-user base through the policykit module, and it could 
even turn out in a require authentication status. This is a huge improvemenPt 
IMHO.

Of course, this does not come without caveats.

 - Action names should be lowercase and (IIRC, must crosscheck) without _ in 
them. This can be solved by registering the action names in lowercase and 
replacing _ with - at check-time in KAuthorized. I don't think this would lead 
to any problem, but please come up with concerns if you think I'm 
underestimating the issue.
 - We will need a small API addition to KAuth that will let you check if an 
action exists, to improve performance and avoid strange behaviors when you try 
to check if an unexistent action is authorized. (already working on that)

More than that, all seems pretty cool. Next step is

*2. Generating the actions*
We would need to generate the actions. This means that we will simply store an 
.actions file in the system, that will be modified by adding/removing/changing 
actions (being it a standard ini file it's a breeze), and running against it 
the policy generator tool when we want to apply changes system-wide.

*3.Revamp Kiosk configuration UI*
As you might have understood by now, the Kiosk configuration, now, would take 
care of editing the actions file, generating the policy accordingly, setting a 
default for all users for the action, but NOT tuning privileges. For that, you 
would have the Policykit authorization module. So the administrator workflow 
would be:

 - Open the Kiosk configuration and create the various lockdowns with their 
default (yes/no/authorization needed/etc). Spit a warning in case he's locking 
completely the access to the Polkit or the Kiosk module: he could get locked 
out himself! (For this kind of actions the best way is to default them to yes, 
go to the policykit module, have it granting you an explicit authorization for 
the action forever, and then defaulting it to no). When he's done, comes the 
saving
 - Upon saving, generate and install the policy.
 - Then the administrator would be pointed to the polkit module, where he will 
be able to fine-tune authorizations.

Please note that with polkit-1 upcoming this design makes even more sense. 
Polkit-1 also introduces more level of policy definitions, per user-group 
authorizations, and more.

I hope I gave a good overview of what is my plan and hope to receive extensive 
feedback on that :) Be aware that:

 - I will not start to touch any line of code unless I have full approval from 
at least Aaron.
 - I need some guidance on the KioskTool (if possible), and most of all on the 
Kiosk URL actions, which I quite did not understand and are the only thing 
that could possibly need some effort to make fit into this kind of design.

Ok, bored you enough, looking into some even boring replies :)

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090923/234e9e99/attachment.sig>