Difference between revisions of "KDE System Administration/Kiosk/Introduction"

Jump to: navigation, search
(KDE Control Module Restrictions)
(KDE Control Module Restrictions)
(7 intermediate revisions by 3 users not shown)
Line 10: Line 10:
 
== KDE's Configuration File Structure and Hierarchy ==
 
== KDE's Configuration File Structure and Hierarchy ==
  
All KDE applications use the same API to create, access and alter their configuration files. As such, all configuration files are stored in predetermined directories and they share the same syntax and structure. They are organised into groupings of key-value pairs. For example, let us examine some of the settings for the KDE desktop background stored in {{path|~/.kde/share/config/kdesktoprc}}:
+
All KDE applications use the same API to create, access and alter their configuration files. As such, all configuration files are stored in predetermined directories and they share the same syntax and structure. They are organised into groupings of key-value pairs. For example, let us examine some of the settings for the mouse behavior and desktop style stored in {{path|~/.config/kdeglobals}}:
  
 
<syntaxhighlight lang="ini">
 
<syntaxhighlight lang="ini">
[Desktop0]
+
[KDE]
Wallpaper=/usr/kde/share/wallpapers/KDE34.jpg
+
SingleClick=true
WallpaperMode=Scaled
+
DoubleClickInterval=400
 +
widgetStyle=breeze
 
</syntaxhighlight>
 
</syntaxhighlight>
  
The <tt>Desktop0</tt> group as shown contains two key-value pairs to indicate the image to be used as the wallpaper and how it should be displayed. The beginning of a group is indicated by placing its name in square brackets and that group ends when the next one begins or when the end of the configuration file is reached. Both the key and its value may contain spaces but all whitespace immediately before and after the equals sign and at the end of the line are ignored.
+
The <tt>KDE</tt> group as shown contains two key-value pairs to indicate some global settings across the desktop, such as the mouse behavior (single click activation vs double click) and the used applications widget style. The beginning of a group is indicated by placing its name in square brackets and that group ends when the next one begins or when the end of the configuration file is reached. Both the key and its value may contain spaces but all whitespace immediately before and after the equals sign and at the end of the line are ignored.
  
 
KDE configuration files can be stored in a number of possible directories and configuration files with the same name may exist in the different directories. There is a predetermined order in which these locations are checked for configuration files and KDE combines configuration files of the same name on a key-by-key basis; this is known as "cascading configuration". If the same key is defined in more than one of the configuration files then the key value read from the directory tree with the highest precedence will be used.
 
KDE configuration files can be stored in a number of possible directories and configuration files with the same name may exist in the different directories. There is a predetermined order in which these locations are checked for configuration files and KDE combines configuration files of the same name on a key-by-key basis; this is known as "cascading configuration". If the same key is defined in more than one of the configuration files then the key value read from the directory tree with the highest precedence will be used.
  
Two [https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html|environment variables] are used to indicate which directories should be searched for configuration files: <tt>$XDG_CONFIG_HOME</tt> is a cross-desktop environment variable used to locate configuration files in the user's home. <tt>$XDG_DATA_HOME</tt> defines the directory where user specific data should be stored.
+
Some [https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html|environment variables] are used to indicate which directories should be searched for configuration files: <tt>$XDG_CONFIG_DIRS</tt> is a cross-desktop environment variable used to locate configuration files globally in the system. <tt>$XDG_CONFIG_HOME</tt> defines the directory where user specific configs should be stored.
  
 
The cascading nature of KDE's configuration files allows system administrators to set system wide defaults while ensuring that the user's custom configuration settings will always override these system defaults. It is also the basis of the Kiosk framework as configuration entries may be marked as &quot;immutable&quot; - entries in a user's configuration file in <tt>$XDG_CONFIG_HOME</tt> that have been marked as immutable in a system level directory will not be read and will therefore have no effect.
 
The cascading nature of KDE's configuration files allows system administrators to set system wide defaults while ensuring that the user's custom configuration settings will always override these system defaults. It is also the basis of the Kiosk framework as configuration entries may be marked as &quot;immutable&quot; - entries in a user's configuration file in <tt>$XDG_CONFIG_HOME</tt> that have been marked as immutable in a system level directory will not be read and will therefore have no effect.
  
Let us continue with the desktop background example and, as the system administrators of an Internet caf&eacute;, we want to ensure that our logo or our sponsor's logo is always the desktop background and that it cannot be changed by our customers. In one of the system level directory trees (<tt>$KDEDIRS</tt>), we would edit the file {{path|/share/config/kdesktoprc}} so that it contained:
+
Let us continue with the applications widget style example and, as the system administrators of an Internet caf&eacute;, we want to ensure that the widget style is the default "Breeze" style and can't be changed by customers to ensure a visual branding integrity between the machines in the shop. In one of the system level directory trees (<tt>$XDG_CONFIG_DIRS</tt>), we would edit the file {{path|$XDG_CONFIG_DIRS/kdeglobals}} so that it contained:
  
 
<syntaxhighlight lang="ini">
 
<syntaxhighlight lang="ini">
[Background Common]
+
[KDE]
CommonDesktop[$i]=true
+
SingleClick=true
 
+
DoubleClickInterval=400
[Desktop0]
+
widgetStyle[$i]=breeze
Wallpaper[$i]=/usr/kde/share/wallpapers/our_logo.jpg
+
WallpaperMode[$i]=Scaled
+
 
</syntaxhighlight>
 
</syntaxhighlight>
  
Appending '<tt>[$i]</tt>' to the configuration key marks it as immutable. As configuration files from <tt>$KDEDIRS</tt> are read before <tt>$KDEHOME</tt>, the background is now &quot;locked down&quot; and and any custom settings made by a user in {{path|$KDEHOME/share/config/kdesktoprc}}, either directly or though a configuration dialog, will not be read by the configuration system.
+
Appending '<tt>[$i]</tt>' to the configuration key marks it as immutable. As configuration files from <tt>$XDG_CONFIG_DIRS</tt> are read before <tt>$XDG_CONFIG_HOME</tt>, the background is now &quot;locked down&quot; and and any custom settings made by a user in {{path|$XDG_CONFIG_HOME/kdeglobals}}, either directly or though a configuration dialog, will not be read by the configuration system.
  
 
Configuration options can also be marked immutable by group and by file. To mark a group as immutable, we append '<tt>[$i]</tt>' to the group name:
 
Configuration options can also be marked immutable by group and by file. To mark a group as immutable, we append '<tt>[$i]</tt>' to the group name:
  
 
<syntaxhighlight lang="ini">
 
<syntaxhighlight lang="ini">
[Desktop0][$i]
+
[KDE][$i]
Wallpaper=/usr/kde/share/wallpapers/KDE34.jpg
+
SingleClick=true
WallpaperMode=Scaled
+
DoubleClickInterval=400
 +
widgetStyle=breeze
 
</syntaxhighlight>
 
</syntaxhighlight>
  
Similarly, we can mark an entire configuration file as immutable by placing '<tt>[$i]</tt>' on a line of its own at the beginning of the file; KDE will now ignore a configuration file of the same name in the user's KDE configuration directory.
+
Similarly, we can mark an entire configuration file as immutable by placing '<tt>[$i]</tt>' on a line of its own at the beginning of the file; the system will now ignore a configuration file of the same name in the user's KDE configuration directory.
 
+
  
Setting default configuration options for KDE applications is just as easy as fixing the desktop background. We could lock Konqueror's homepage setting to our Internet caf&eacute;'s homepage by setting the following in a file called <tt>konquerorrc</tt> in one of the system directory trees:
+
Setting default configuration options for KDE applications is just as easy as fixing the desktop background.  
 +
We could lock Dolphin settings to always show the available space insicator in its statusbar by setting the following in a file called <tt>dolphinrc</tt>in one of the system directory trees:
  
 
<syntaxhighlight lang="ini">
 
<syntaxhighlight lang="ini">
[FMSettings]
+
[General]
HomeURL[$i]=http://www.myinternetcafe.com/
+
ShowSpaceInfo[$i]=true
 
</syntaxhighlight>
 
</syntaxhighlight>
  
Any setting that can be changed or customized in an application is one that can be locked down using the Kiosk framework. Examine the contents of the various configuration files that can be found under {{path|$KDEHOME/share/config/}} to get a feeling for KDE application configuration settings.
+
Any setting that can be changed or customized in an application is one that can be locked down using the Kiosk framework. Examine the contents of the various configuration files that can be found under {{path|$XDG_CONFIG_HOME}} to get a feeling for KDE application configuration settings.
  
You should also bear in mind that most applications will need to be restarted for configuration settings to take effect. For changes to configuration files such as <tt>kdesktoprc</tt> and <tt>kdeglobals</tt> (introduced in the next section) you will need to log out and back into KDE for changes to be applied.
+
 
 +
You should also bear in mind that most applications will need to be restarted for configuration settings to take effect. For changes to configuration files such as <tt>kdeglobals</tt> you will need to log out and back into the Plasma session for changes to be applied.
  
  
Line 66: Line 67:
 
== KDE Action Restrictions ==
 
== KDE Action Restrictions ==
  
One of KDE's strongest features is the fact that it is &quot;an integrated desktop environment&quot;. This means that all of its applications share the same 'look-and-feel' so that once you have learned how to use one KDE application, learning the next is even easier. This common functionality - standardised menus and toolbars, integrated help system, etc – is built around the concept of &quot;actions&quot;.
+
Many actions in KDE applications and Plasma can be restricted through the Kiosk system by placing appropriate entries in the  
 
+
All KDE actions can be restricted through the Kiosk system by placing appropriate entries in the {{path|kdeglobals}} file in a system level directory, such as {{path|/etc/xdg/kdeglobals}}. We could disable the file open action by adding the following entry:
For example, one can open a file by selecting the 'File-&gt;Open...' menu option, by clicking on the 'File Open' toolbar icon or by pressing 'CTRL+O'. Whichever way you choose, each option simply activates the <tt>file_open</tt> action.
+
 
+
All KDE actions can be restricted through the Kiosk system by placing appropriate entries in the {{path|/share/config/kdeglobals}} file in a system level directory. We could disable the file open action by adding the following entry:
+
  
 
<syntaxhighlight lang="ini">
 
<syntaxhighlight lang="ini">
Line 100: Line 98:
 
</table>
 
</table>
  
There are currently over 120 actions that can be restricted in KDE 3.4 and these include all standard file options, editing options, Internet and file browsing actions, the use of bookmarks and access to the help system. A full list can be found in the [http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/doc/README.kiosk?view=markup kdecore/doc/README.kiosk] file of the kdelibs package source code for your current KDE version (available from [http://developer.kde.org/source/ http://developer.kde.org/source/]).
+
The actions that can be restricted include all standard file options, editing options, Internet and file browsing actions, the use of bookmarks and access to the help system. A comprehensive list can be found in the [[KDE_System_Administration/Kiosk/Keys|Keys page]].
  
Some KDE applications, such as system configuration front ends like KUser, need to be run as the root user. These applications would be unnecessary in an Internet caf&eacute; and they can be disabled with:
+
A few other actions that are worthy of individual mention in the context of corporate and similar environments are:
 
+
<syntaxhighlight lang="ini">
+
[KDE Action Restrictions][$i]
+
user/root=false
+
</syntaxhighlight>
+
 
+
The ability to print documents can be blocked via the action <tt>file_print</tt> and access to the printing system/backend can be blocked by setting the <tt>print/system</tt> to <tt>false</tt>. One can also disable access to the printing properties dialogue, the ability to print more than one copy, etc. These are all referenced in the [http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/doc/README.kiosk?view=markup kdecore/doc/README.kiosk] file.
+
 
+
A few other actions that are worthy of individual mention in the context of Internet caf&eacute;s and similar environments are:
+
  
 
;<tt>shell_access</tt>
 
;<tt>shell_access</tt>
:Defines whether the user can start a shell for entering commands, whether the &quot;Run Command&quot; option (Alt-F2) can be used to run shell-commands and arbitrary executables and whether executables placed in the user's Autostart folder will be executed.
+
:Defines whether the user can start a shell for entering commands, whether the “Run Command” option (Alt-F2) can be used to run shell commands and arbitrary executables and whether executables placed in the user's Autostart folder will be executed.
  
 
;<tt>logout</tt>
 
;<tt>logout</tt>
:Defines whether a user will be able to end the KDE session.
+
:Defines whether a user will be able to end the KDE Plasma session.
  
 
;<tt>lock_screen</tt>
 
;<tt>lock_screen</tt>
Line 123: Line 112:
  
 
;<tt>run_command</tt>
 
;<tt>run_command</tt>
:Controls access to the &quot;Run Command&quot; option.
+
:Controls access to the “Run Command” option.
  
 
;<tt>movable_toolbars</tt>
 
;<tt>movable_toolbars</tt>
:Whether or not toolbars may be moved around by the user.
+
:Whether or not toolbars can be detached and/or moved around.
  
Users of public access terminals and Internet caf&eacute;s will undoubtedly want to keep their browsing history to themselves. You should carefully consider settings such as the history sidebar, how cookies are handled and whether or not to use a cache. Once you have made your choices, set these options in <tt>konquerorrc</tt> and mark them as immutable. Also, if you are a regular user of Konqueror then you know that it has a very useful feature in that it remembers the URLs you enter in the &quot;Location&quot; bar. In a public environment, set the action <tt>lineedit_text_completion</tt> to false so that text boxes do not remember previously entered information.
+
;<tt>action/options_show_toolbar</tt>
 +
:Whether or not toolbars can be hidden.
  
One may also wish to set the action <tt>editable_desktop_icons</tt> to false as it defines whether icons on the desktop can be moved, renamed, deleted or added by users. Be sure to either move the desktop directory and/or to make it read-only (usually {{path|$HOME/Desktop}}).
+
;<tt>plasma/plasmashell/unlockedDesktop</tt>
 +
:Whether or not widgets can be unlocked by the user. Unlocking widgets would allow the user to move around, add, and remove widgets, panels, launchers, etc.
 +
 
 +
In a public environment, set the action <tt>lineedit_text_completion</tt> to false so that text boxes and the “Run Command” dialog do not remember previously entered information. Do note that this will not affect 3rd party web browsers like Firefox.
  
 
== KDE URL Restrictions ==
 
== KDE URL Restrictions ==
Line 174: Line 167:
 
== KDE Control Module Restrictions ==
 
== KDE Control Module Restrictions ==
  
Almost all aspects of the K Desktop Environment can be configured and customized through the &quot;System Settings&quot;. Each &quot;group&quot; of settings, such as &quot;Screens&quot;, &quot;Colours&quot;, &quot;Fonts&quot;, etc as shown in Fig. 4, correspond to a system settings module and each of these modules can be locked down through the Kiosk framework.
+
Almost all aspects of the K Desktop Environment can be configured and customized through the &quot;System Settings&quot;. Each &quot;group&quot; of settings, such as &quot;Screens&quot;, &quot;Colours&quot;, &quot;Fonts&quot;, etc correspond to a system settings module and each of these modules can be locked down through the Kiosk framework.
  
 
As an example, a way of preventing users from changing their mouse settings would be to lock down that system settings module:
 
As an example, a way of preventing users from changing their mouse settings would be to lock down that system settings module:
Line 184: Line 177:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
In fact, the users will not even see an option to configure the mouse in System settings. Run the command '<tt>kcmshell5 --list</tt>' for a list of available modules and use the format &lt;module-name&gt;.desktop in the configuration file. In most public access/caf&eacute; environments, one will probably want to lock down almost all control centre modules.
+
The users will not even see an option to configure the mouse in System settings.  
 +
 
 +
Run the command '<tt>kcmshell5 --list</tt>' for a list of available modules and use the format &lt;module-name&gt;.desktop in the configuration file. In most public access/caf&eacute; environments, one will probably want to lock down almost all control centre modules.
  
 
Figure 4. The System Settings application interface.
 
Figure 4. The System Settings application interface.
  
== The KDE Kiosk Tool ==
+
== Closing Remarks ==
  
The KDE Kiosk Admin tool, see Fig. 5, is a graphical front end to the KDE Kiosk framework and was originally written by Waldo Bastian, a core KDE developer, for Novell's Linux Desktop. As well as provided an interface to the Kiosk framework, it  also allows KDE administrators to create default profiles for different groups of users (that is &quot;groups&quot; in the Unix file system sense) far easier than could be accomplished through the configuration files.
+
KDE's Kiosk framework is an essential tool for any system administrator who is maintaining or deploying the Plasma in a multi-desktop/multi-user scenario and/or in an environment where users cannot be trusted. By preventing users from changing default settings and locking down settings that may pose a security risk, a system administrator can significantly reduce the amount of time that will be spent &quot;maintaining and repairing&quot; each desktop as well as ensuring that each user has a common and familiar desktop environment every time they sit down to the computer.
  
  [kiosk-lp/kiosktool.jpg" title="Click for a larger image
+
{{CC-BY-SA}} © 2005 Barry O'Donovan
      <img src="kiosk-lp/kiosktool-small.jpg" border="0" width="388" height="256" alt="The Kiosk Tool" />
+
  ]
+
  
Figure 5. The KDE Kiosk Admin Tool.
+
{{CC-BY-SA}} © 2016 David Edmundson
  
The Kiosk Admin tool is not part of the official KDE distribution as it is under active development and keeping it free from KDE's release schedules allow its developers to incorporate feedback faster. It is, however, included with many Linux distributions. More information and downloads can be found on [http://extragear.kde.org/apps/kiosktool/ http://extragear.kde.org/apps/kiosktool/].
+
{{CC-BY-SA}} © 2016 Marco Martin
  
As I mentioned, one of Kiosk Tool's strongest assets is the ease at which one can create multiple Kiosk profiles and assign them per Unix group. For example, in an Internet caf&eacute; one might create two groups: customers and admins. It would then be logical to have an increased set of restrictions (such as file system access, shell access, etc) assigned to the customers' account(s) while leaving the administrators' accounts with little or no restrictions.
+
{{CC-BY-SA}} © 2016 Kai Uwe Broulik
 
+
The Kiosk Admin tool also allows system administrators to maintain all profiles on their local machine and then upload them to another server when profiles are added, deleted or modified.
+
 
+
== Closing Remarks ==
+
 
+
KDE's Kiosk framework is an essential tool for any system administrator who is maintaining or deploying the K Desktop Environment in a multi-desktop/multi-user scenario and/or in an environment where users cannot be trusted. By preventing users from changing default settings and locking down settings that may pose a security risk, a system administrator can significantly reduce the amount of time that will be spent &quot;maintaining and repairing&quot; each desktop as well as ensuring that each user has a common and familiar desktop environment every time they sit down to the computer.
+
 
+
{{CC-BY-SA}} © 2005 Barry O'Donovan
+

Revision as of 10:30, 6 September 2016

Introduction

The KDE Kiosk is a framework that has been built into KDE since version 3. It allows administrators to create a controlled environment for their users by customizing and locking almost any aspect of the desktop which includes the benign such as setting and fixing the background wallpaper, the functional such as disabling user log outs and access to the print system and the more security conscientious such as disabling access to a command shell.

This kind of framework is vital to maintain and increase KDE's propagation into areas such as business and enterprise environments and school and university laboratories. Other obvious areas of interest where a restricted desktop environment is required or desired would be the likes of Internet cafés, public access terminals and kiosks.

KDE's Kiosk framework is controlled by entries in various configuration files or through a GUI application, the Kiosk Admin Tool. In this article I will discuss the layout of KDE's configuration files and how to edit them to enable Kiosk's features. I will also discuss the various aspects of the desktop environment that can be customized and/or locked using the Kiosk framework. Once the reader understands how the Kiosk framework actually works through KDE's configuration files, we will discuss the Kiosk Admin Tool for those that prefer a GUI interface. This tool also allows administrators to more easily set-up Kiosk profiles and assign them system wide, per-user or per-group.

KDE's Configuration File Structure and Hierarchy

All KDE applications use the same API to create, access and alter their configuration files. As such, all configuration files are stored in predetermined directories and they share the same syntax and structure. They are organised into groupings of key-value pairs. For example, let us examine some of the settings for the mouse behavior and desktop style stored in ~/.config/kdeglobals:

[KDE]
SingleClick=true
DoubleClickInterval=400
widgetStyle=breeze

The KDE group as shown contains two key-value pairs to indicate some global settings across the desktop, such as the mouse behavior (single click activation vs double click) and the used applications widget style. The beginning of a group is indicated by placing its name in square brackets and that group ends when the next one begins or when the end of the configuration file is reached. Both the key and its value may contain spaces but all whitespace immediately before and after the equals sign and at the end of the line are ignored.

KDE configuration files can be stored in a number of possible directories and configuration files with the same name may exist in the different directories. There is a predetermined order in which these locations are checked for configuration files and KDE combines configuration files of the same name on a key-by-key basis; this is known as "cascading configuration". If the same key is defined in more than one of the configuration files then the key value read from the directory tree with the highest precedence will be used.

Some variables are used to indicate which directories should be searched for configuration files: $XDG_CONFIG_DIRS is a cross-desktop environment variable used to locate configuration files globally in the system. $XDG_CONFIG_HOME defines the directory where user specific configs should be stored.

The cascading nature of KDE's configuration files allows system administrators to set system wide defaults while ensuring that the user's custom configuration settings will always override these system defaults. It is also the basis of the Kiosk framework as configuration entries may be marked as "immutable" - entries in a user's configuration file in $XDG_CONFIG_HOME that have been marked as immutable in a system level directory will not be read and will therefore have no effect.

Let us continue with the applications widget style example and, as the system administrators of an Internet café, we want to ensure that the widget style is the default "Breeze" style and can't be changed by customers to ensure a visual branding integrity between the machines in the shop. In one of the system level directory trees ($XDG_CONFIG_DIRS), we would edit the file $XDG_CONFIG_DIRS/kdeglobals so that it contained:

[KDE]
SingleClick=true
DoubleClickInterval=400
widgetStyle[$i]=breeze

Appending '[$i]' to the configuration key marks it as immutable. As configuration files from $XDG_CONFIG_DIRS are read before $XDG_CONFIG_HOME, the background is now "locked down" and and any custom settings made by a user in $XDG_CONFIG_HOME/kdeglobals, either directly or though a configuration dialog, will not be read by the configuration system.

Configuration options can also be marked immutable by group and by file. To mark a group as immutable, we append '[$i]' to the group name:

[KDE][$i]
SingleClick=true
DoubleClickInterval=400
widgetStyle=breeze

Similarly, we can mark an entire configuration file as immutable by placing '[$i]' on a line of its own at the beginning of the file; the system will now ignore a configuration file of the same name in the user's KDE configuration directory.

Setting default configuration options for KDE applications is just as easy as fixing the desktop background. We could lock Dolphin settings to always show the available space insicator in its statusbar by setting the following in a file called dolphinrcin one of the system directory trees:

[General]
ShowSpaceInfo[$i]=true

Any setting that can be changed or customized in an application is one that can be locked down using the Kiosk framework. Examine the contents of the various configuration files that can be found under $XDG_CONFIG_HOME to get a feeling for KDE application configuration settings.


You should also bear in mind that most applications will need to be restarted for configuration settings to take effect. For changes to configuration files such as kdeglobals you will need to log out and back into the Plasma session for changes to be applied.


The information presented in this section will allow you to set system defaults and lock them if necessary for any KDE application. However, this is only the proverbial tip of the iceberg of the KDE Kiosk system and in the following sections we will cover many more of its capabilities.

KDE Action Restrictions

Many actions in KDE applications and Plasma can be restricted through the Kiosk system by placing appropriate entries in the All KDE actions can be restricted through the Kiosk system by placing appropriate entries in the kdeglobals file in a system level directory, such as /etc/xdg/kdeglobals. We could disable the file open action by adding the following entry:

[KDE Action Restrictions][$i]
action/file_open=false

This change can be visibly seen in Kate's 'File' menu and toolbar which are shown in Figs. 2 and 3.

     <img src="kiosk-lp/unrestricted.jpg" width="250" border="0" height="286" alt="Image of an unrestricted menu and toolbar" />
               
     <img src="kiosk-lp/restricted.jpg" width="250" border="0" height="287" alt="Image of a restricted menu and toolbar" />
Figure 2.
file_open
unrestricted.
Figure 3.
file_open
restricted.

The actions that can be restricted include all standard file options, editing options, Internet and file browsing actions, the use of bookmarks and access to the help system. A comprehensive list can be found in the Keys page.

A few other actions that are worthy of individual mention in the context of corporate and similar environments are:

shell_access
Defines whether the user can start a shell for entering commands, whether the “Run Command” option (Alt-F2) can be used to run shell commands and arbitrary executables and whether executables placed in the user's Autostart folder will be executed.
logout
Defines whether a user will be able to end the KDE Plasma session.
lock_screen
Defines whether a user will be able to lock the screen.
run_command
Controls access to the “Run Command” option.
movable_toolbars
Whether or not toolbars can be detached and/or moved around.
action/options_show_toolbar
Whether or not toolbars can be hidden.
plasma/plasmashell/unlockedDesktop
Whether or not widgets can be unlocked by the user. Unlocking widgets would allow the user to move around, add, and remove widgets, panels, launchers, etc.

In a public environment, set the action lineedit_text_completion to false so that text boxes and the “Run Command” dialog do not remember previously entered information. Do note that this will not affect 3rd party web browsers like Firefox.

KDE URL Restrictions

The KDE Kiosk system allows system administrators to control access to specific URLs based on the referrer, the protocol, the host and the path through entries in the kdeglobals file. Although some of these tasks may be more appropriate for a proxy server or a firewall, this functionality becomes incredibly useful when you consider the fact that KDE treats all locations as URLs. For blocking access to websites, one might use the following example:

Note this, only affects KDE applications, such as Dolphin or Konqueror. Other browsers are not affected.

[KDE URL Restrictions][$i]
rule_count=2
rule_1=open,,,,http,*.hotmail.msn.com,,false
rule_2=open,,,,http!,webmail.college.com,,false

The first rule blocks all http and https access to any URL that contains .hotmail.msn.com in the host part. Specifying one protocol will also match similar protocols that start with the same name; so specifying http will also include https. Rule 2 above blocks only http and thus forces the user to use https (assuming it is supported). The above rules could be used as a basis, for example, to block all access to third part web-based e-mail clients and force users to use a company or college provided virus-scanned e-mail account over https. If, for example, an Internet café took sponsorship from a search engine then its system administrators could use similar rules to block access to that search engine's competitors.

The format for URL restrictions is:

rule_N=<action>,<referrer protocol>,<referrer host>,<referrer path>,
    <protocol>,<host>,<path>,<enabled>

Any option that is left blank will match all by default. As we saw in the example above, wild cards may be used for host names. Specifying a path will match all URLs that begin with that path unless an exclamation mark is placed at the end of the path.

As I mentioned, KDE treats all locations as URLs: for example Internet addresses are URLs with the http or https protocol whereas local files on the hard drive are URLs using the file protocol. Access to the local filesystem can be restricted using rules such as the following:

[KDE URL Restrictions][$i]
rule_count=6
rule_1=open,,,,file,,,false
rule_2=list,,,,file,,,false
rule_3=open,,,,file,,$HOME,true
rule_4=list,,,,file,,$HOME,true
rule_5=open,,,,file,,$TMP,true
rule_6=list,,,,file,,$TMP,true

These rules will only allow the user to browse and access files stored in their home directory. We also allow access to the temporary directory used by KDE to ensure normal operation. If you are implementing a security policy then these rules should be used in conjunction with other rules such as restricted shell access.

KDE Control Module Restrictions

Almost all aspects of the K Desktop Environment can be configured and customized through the "System Settings". Each "group" of settings, such as "Screens", "Colours", "Fonts", etc correspond to a system settings module and each of these modules can be locked down through the Kiosk framework.

As an example, a way of preventing users from changing their mouse settings would be to lock down that system settings module:

Add the following to the global kde5rc file, in the heirachy listed above.

[KDE Control Module Restrictions][$i]
mouse.desktop=false

The users will not even see an option to configure the mouse in System settings.

Run the command 'kcmshell5 --list' for a list of available modules and use the format <module-name>.desktop in the configuration file. In most public access/café environments, one will probably want to lock down almost all control centre modules.

Figure 4. The System Settings application interface.

Closing Remarks

KDE's Kiosk framework is an essential tool for any system administrator who is maintaining or deploying the Plasma in a multi-desktop/multi-user scenario and/or in an environment where users cannot be trusted. By preventing users from changing default settings and locking down settings that may pose a security risk, a system administrator can significantly reduce the amount of time that will be spent "maintaining and repairing" each desktop as well as ensuring that each user has a common and familiar desktop environment every time they sit down to the computer.

Template:CC-BY-SA © 2005 Barry O'Donovan

Template:CC-BY-SA © 2016 David Edmundson

Template:CC-BY-SA © 2016 Marco Martin

Template:CC-BY-SA © 2016 Kai Uwe Broulik


Content is available under Creative Commons License SA 4.0 unless otherwise noted.