[Kde-kiosk] Preventing unset of default KDE configurations

[Taru Jain]

Hello Martijn,

Thanks for your reply :-) I have a few questions:

1) When you say "from KDE 3.2 onwards there are user profiles that are
controlled through /etc/kderc and no longer rely on environment
variables." do you mean that the $KDEDIRS will no longer be read by the
underlying KDE system to determine what is the default configuration??
or is there any plan to do such a thing in the future version?

2) On my box I have KDE 3.2.1, and I see in the kde start up script
that the value of $KDEDIRS is being unset. Is it because of the reason
stated in the (i) point?

3) I wanted to use $KDEDIRS variable rather than user profile because
the directories listed in the $KDEDIRS have a lower precendence than the
user profiles. If a setting is *locked* in the default kde configuration
(specified through $KDEDIRS like /etc/opt/kde3) then the value which I
would have specified in my profile will not take effect. I want to
ensure that no matter what my settings should take precendence. So I can
set my configuration directory before the system defaults in the
$KDEDIRS variable. But then the problem is that after a user login
event, this $KDEDIR value can be unset. Is there a way to resolve this?

Thanks for all the help.

Regards
Taru


Taru Jain said:
> We can use the KDEDIRS variable to specify a directory which can
> contain the customized system wide default configuration. However,
after
> a user logs in, the KDEDIRS value can be reset/unset in a shell.
> Subsequently, the the customized configuration will not longer take
> effect in this shell and in any programs launched from this shell.
>
> Is there a way of preventing this from happening? (We do not want to
> stop the user from using the shell)

Yes and no.

Yes, because from KDE 3.2 onwards there are user profiles that are
controlled through /etc/kderc and no longer rely on environment
variables.

The 'old' style of applying Kiosk settings has the weakness you
describe.

The easiest way to setup profiles is to use KioskTool, but you can
also
manually setup the required components in /etc. (I don't have access
to
the docs at the moment, but IIRC the README.kiosk file in kdelibs
describes the details.)

No, because a user with shell access can potentially still bypass Kiosk
by
setting LD_PRELOAD to load a small library that intercepts the loading
of
/etc/kderc and pretends there are no profiles specified.

This can be mostly avoided by mounting all filesystems where a user
has
write access with 'noexec', but I am not convinced that is 100%
foolproof.
(I'm open to examples that prove me right or wrong, so far it's just a
feeling.) Combining noexec and profiles does help against most attack
vectors and makes bypassing Kiosk significantly harder, so much more
that
people are less inclined to try anymore. Only people who have
intentions
that are more malicious than just 'working around the system' will
likely
still bother.
-- 
Martijn