[Kde-kiosk] how to make KDE kiosk work

[Martijn Klingens]

On Monday 10 January 2005 03:29, Claudio Henrique Fortes Felix wrote:
> Is the KDE kiosk framework just the result of the ability we have to
> edit the configuration files, for example, on /opt/kde/share, using
> immutable attributes, or is it something more than that? By looking at
> how kiosktool works, it appears to use profiles that, according to the
> its docs, are nothing else than KDE configuration directory structures.
> However, I see no KDEDIRS variable exporting them, so it appears there´s
> something more to it than the KDE documentation explains.

Yup, there's one more thing that was added rather recently (KDE 3.2.2 if I'm 
not mistaken) and that's not in most documentation: user profiles.

In all older KDE 3.x versions you needed to export KDEDIRS to apply a profile. 
The problem with this approach (besides being more work for the 
administrator) is that it's usually possible for users to override the 
profile by executing 'KDEDIRS=/opt/kde3 konqueror'. All a user needs is the 
ability to either dump a shell script or have direct shell access and the 
result is that he or she can run Konqueror in its full mode rather than the 
locked down version.

Of course there will always be ways to circumvent Kiosk restrictions on 
loosely locked down systems[1] (if all else fails one could put self-compiled 
binaries there), but it doesn't hurt if it's at least somewhat challenging to 
do so.

This is where the user profiles come into play. Those are handled directly by 
the files in /etc (kde3rc, kde-user-profile, kde-profile) and special code in 
the KDE libraries. The only way to bypass them without messing with files 
that only root should have access to or using custom binaries is to get 
listed in the 'kioskAdmin' field of /etc/kde3rc. In case you're listed there 
you can set $KDE_KIOSK_NO_PROFILES to temporarily bypass the profiles.

Hope this helps,

Martijn

[1] The less your users should be able to do, the more you can do to secure
    the system. You can't take the ability to store executable programs from a
    developer, nor can you take his shell access. However, many other people
    can work perfectly fine with a home dir that's mounted noexec and without
    shell access.