Default GNOME deployment security

We need to have a strong definition of what a default installation of GNOME allows a given user to do, what the authentication defaults are, and how system administrators can change the defaults.

To boil this problem down, it's really stupid to prompt for the root password to connect to a wireless network.

Prior art here includes Ubuntu's default use of sudo.

Proposal

When you install GNOME, you create a user account, and can optionally configure authentication there (password, mobile phone). There is no prompt for "root". The GNOME defaults allow any console user the ability to do "normal things" for a user-owns-machine deployment scenario (see below). Briefly, this includes:

Network controls
Changing the time and date
Installing and uninstalling applications (*not* "packages")
Access sound and graphics devices

It may also restrict things that "kernel defaults" would allow (for example, we may restrict the ability to use ptrace).

So what about making arbitrary changes to the OS image? See "Unlocking" below.

Unlocking

This is the process by which the OS is modified to allow arbitrary control. For example:

Adding and removing packages (as distinct from applications)
Modifying SELinux booleans
Removing other users

How would this work? Effectively, the OS knows whether it's ever been unlocked or not; this could be as simple as a file /etc/gnomeos/allow-unlock which is added to the default image. If this file exists, then the control panel has an "Unlock" button.

The unlock button simply grants the current user "pkexec" privileges, and then removes the allow-unlock file.

Deployment Scenarios

User Owns Machine

You download the GNOME image and install it on your computer. This is what the default OS image is configured for.

Network controls
Changing the time and date
Installing and uninstalling applications (*not* "packages")
Access sound and graphics devices

Slightly grey:

Allowing users to delete themselves?
Adding new users

Lab Workstation

GNOME running on a set of workstations in a computer lab. This case is probably easiest to turn off specific PolicyKit privileges like network control and application installation.

UNIX timesharing server

Traditional server role - in this case, we document how to just turn off all the PolicyKit privileges, since "kernel defaults" is closest to what people want.