A couple of years ago, when I introduced the idea of the xguest user in SELinux, I was
working on a kiosk user. I have since added lots of other types of confined users. One
of the biggest problems I have seen with this is the way our desktop is designed.
Our desktop is designed to be what I would call an administrative desktop. Tools like
packagekit, setroubleshoot, abrt etc run by default. Pull down menus include lots of tools
that prompt me for the root password. If I don't know the root password and am not an
administrator of the machine, I should not be given options to run administrative tools in
the menu.
I played with sabayon, but sabayon has it backwards, in my opinion. sabayon is a
blacklist tool. sabayon tries to take away applications from the meno or stop applications
from starting. I believe sabayon or another tool needs to be a white list tool.
(sabaon++) If we had this tool the administrator or package developer could list the
applications that will show up in the menus, and will autostart. Once I lock design the
desktop for this type of user, no installation of an application will change the way this
type of users desktop looks/runs. With current sabayon, everytime a new desktop feature
shows up, I am forced to re-release xguest to remove the feature from the desktop.
I would like to see two default user types out of the box, Minimal Desktop,
administrative desktop.
Administrative desktop, would be what we have now. You install an app that includes
desktop files, they show up on the desktop.
Minimal desktop, would only have a minimal set of applications, for the user to use.
Firefox, Mail Client, Office products, NetworkManager, PowerManagement?
Then sabayon++ can add or remove applications from the menu system and autostarting.
Then I and other package maintainers could ship desktop users like xguest user, or
corporate desktop user and only run the apps that are appropriate to that type of user.
The biggest benefit for the SELinux team is we can write policy that is appropriate to the
type of user. Currently xguest policy has to dontaudit xguest_t sending dbus messages to
packagekit, just because the packagekit client starts by default. If we have the ability
to customize my xguest desktop environment, and future proof it, then we can remove the
dontaudit. If a xguest user tries to start packagekit client, that would be an audited
event.
Forgetting about SELinux, I believe this would be compelling to administrators of large
networks of desktops.
Show replies by thread