DaveMalcolm/SELinuxIdeas

Four audiences for SELinux

• "old-school" sysadmin: used to editing files under /etc, restarting services, etc etc; in runlevel 3; reads manpages; may be more familiar with other Posix systems that don't have MAC, and is surprised when things don't work quite the way they're used to
• semi-technical/Windows sysadmin: uses system-config-* and looks in gnome-system-monitor, in runlevel 5
• non-technical user; ideally doesn't know what "the kernel" is, and if they've even heard of SELinux, it's at the level of a feature bulletpoint and is "magic".
• the cracker who's gained a local account on the box via a zero-day exploit, and who is trying to escalate their privs up to the point where they have control of local user data, of services on the box, or root. Obviously we want to make life difficult for this persona.

Ideas for the "old-school" sysadmin

(brainstorming here)

man pages

• add an (optional) SELinux section to the standard manpage layout
• proposal: all confined services should have an SELinux section, with a description of defaults, and a list of booleans affecting the service (can this be autogenerated somehow?)
• do SELinux booleans have manpages? it seems to me that every SELinux boolean ought to have a manpage, so that if you type "man httpd_enable_homedirs", something should appear (to help make SELinux more "discoverable" to this user). Can these manpages be autogenerated from the existing documentation? (Seems like a new subsection within the "man" hierarchy, perhaps under "8"?).

/etc comments

• proposal: all confined programs with a /etc file should have a comment in the config file, describing booleans that affect the config, so that when the sysadmin turns on some feature in the config, there's a comment there telling them/reminding them to turn on the appropriate booleans

service startup

• proposal: all confined programs that read config and that can be affected by booleans should detect if the config is out-of-step with the booleans, and issue a warning on startup/rereading config describing which booleans to enable

Ideas for "GUI admins"

(again, a brainstorm)

Visual language for SELinux

Identify the various components

• processes should have icons (see e.g. gnome-system-monitor)
• domains could have visualizations e.g. as forcefields, annotated with icons
• visually distinguish rpm-managed files from 3rd party files
• visually distinguish files with an mismatching checksum
• visualize a denial: subject --action--> object, with "action" arrow blocked by the forcefields
• or perhaps show it like the rods in a nuclear reactor, filtering away the action from subject to object, stopping it happening?
• or a bank vault?
• railroad diagrams showing the interaction of booleans, composed into AND and OR combinations, with "marching ants" green lines to signify "allowed", and "dead ant" red lines signifying "denied"

/etc parsing

• proposal: sealert to use augeas to parse the config files, and warn about booleans that ought to be set