ramblings about privileges
David Zeuthen
david at fubar.dk
Sat Jan 21 17:17:24 PST 2006
Hey,
So as we're adding more and more functionality to hal in terms of method
invocations and other stuff, distributors and admins needs to take
greater precautions in locking down hal so there are no unwanted
privilege escalation.
Yes, even though I seem to say "console user is good enough for auth" a
lot, I do concur there's a real need to lock down systems; not all
systems are personal laptops or home machines, there's Sarbanes-Oxley to
consider, there's the university campus setting with bored malicious
grad students and much much more. I'm not sure what the exact term is so
I'll refer to this as "privilege policy" in the following.
Ideally I want all stakeholders (hal contributors, distributors and
vendors, desktops using hal etc.) to agree on a common scheme as far as
possible. Comments appreciated.
>From a 50,000 feet perspective I think the requirements are like this
a) Ability to lock down HAL completely
b) An easy way for relatively experienced sysadmins to grasp how
the system works and how to configure privilege policy [1]
c) The ability for the GNOME and KDE's of the world to easily provide
UI shells for configuring privilege policy
d) No controversial dependencies, e.g. no gconf or LDAP
e) A way for vendors to push privilege policies from remote databases
e.g. gconf or ldap
f) Based on lowest-common denominator technology, e.g. we can't rely
on SELinux, all we can assume is having the uid of the owner of the
process invoking a method. Optionally we want to rely on whether
that uid is at an console too though the Debian distros may want
to patch this to group membership
g) Fairly fine-grained privileges without overdoing it. E.g. make
a distinction between fixed media (disks inside the computer)
and non-fixed (e.g. optical discs, usb harddisks) rather than
providing a framework where you can match on every single property
know to HAL.
Btw, this is a very fine line to walk given we want to satisfy b)
and c) above.
h) Ship upstream HAL with a privilege policy that is secure out of
the box.
When thinking about hard problems like these I like to think in terms of
examples (credit for this example mostly goes to Alan Cox who proposed
this in the FC3 timeframe). Suppose we have a completely locked down
system and the user inserts a USB keychain drive. Since the system is
locked down, the method Mount() on HAL throws the PermissionDenied
expection and perhaps gnome-mount puts up a dialog like this [2]
+--------------------------------------------------------------------+
| "You are not privileged to access the volume 'Dave's USB key'" |
| |
| [Mount as super user] [Cancel] |
+--------------------------------------------------------------------+
Grrr.. Now, If the user presses "Mount as super user" he sees this
dialog (the round parenthesis are radio buttons)
+----------------------------------------------------+
| Super user password: [_______________] |
| |
| Would you also like to automatically allow |
| |
| (*) This user to mount 'Dave's USB key' |
| ( ) Any user to mount 'Dave's USB key' |
| ( ) This user to mount a removable storage device |
| ( ) Any user to mount a removable storage device |
| |
| [<- Drives and Media Preferences] [Mount] |
+----------------------------------------------------+
and the same dialog with s/removable storage device/internal disk/ for
fixed disks. After pressing the "Mount" button some magic happens
(consolehelper, whatever.. some vendors may ask for the user password
e.g. sudo) and if the password is correct we get elevated to uid 0 (or
something else) and HAL will let us mount..
Oh, btw, and the "Drives and Media Preferences" takes the user to the
gnome-volume-manager (or KDE equivalent or whatever) where there is a
button for a dialog for configuring the whole set of policies related to
storage. Oh.. clearly to use this dialog one needs to have some
administrative privileges so there is probably a dialog asking for a
password to get to it. Anyway, the dialog probably looks something like
this (U is a user icon, G is a group icon).
+------------------------------------------------+
| ( ) No user can mount fixed drives |
| ( ) Any user can mount fixed drives |
| (*) Restrict mounting of fixed drives to |
| the following users and groups: |
| +-------------------------------+ |
| | U davidz ^| |
| | U dilbert || |
| | G admins || |
| | G releng V| |
| +-------------------------------+ |
| [Delete] [Add Group] [Add User] |
| |
| ( ) No one can mount removable drives |
| ( ) Any user can mount removable drives |
| (*) Restrict mounting of removable drives to |
| the following users and groups: |
| +-------------------------------+ |
| | U jane ^| |
| | U john || |
| | G admins || |
| | G secretaries V| |
| +-------------------------------+ |
| [Delete] [Add Group] [Add User] |
| |
| This policy is overridden for the following |
| drives and volumes: |
| +-------------------------------+ |
| | 'Dave's USB key' ^| |
| | 'Financial Data Backup' || |
| | V| |
| +-------------------------------+ |
| [Delete] [Properties] |
| |
| [ ] Never ask user for password if not |
| privileged to mount a drive |
| |
| [Close] |
+------------------------------------------------+
The "Add Group" and "Add user" dialogs should be self explanatory, the
"Properties" dialog for overriding may look like this
+------------------------------------------------+
| The following users and groups are allowed to |
| mount the volume 'Dave's USB key': |
| +-------------------------------+ |
| | U dave ^| |
| | U dogbert || |
| | G coolkids V| |
| +-------------------------------+ |
| [Delete] [Add Group] [Add User] |
| |
| The following users and groups are not allowed |
| to mount the volume 'Dave's USB key': |
| +-------------------------------+ |
| | U bert ^| |
| | U osama || |
| | G lamers V| |
| +-------------------------------+ |
| [Delete] [Add Group] [Add User] |
| |
| [Close] |
+------------------------------------------------+
Now, this example is pretty complete I think, sorry for being verbose,
but I think in order to capture requirements one needs to consider all
details. it's complex, yes.. is it too complex for users and admins? Are
there features we don't need?
With the desired UI in mind, how would construct a model for allowing
such an user interface in a secure way? Clearly we have users, groups,
black lists and white lists in the picture.
My thinking is a flat configuration file that mirrors the data above
(where /org/fd/Hal/d/volume_uuid_43AC is the HAL UDI (unique device
identier, not uid!) for the volume 'Dave's USB key'.
I'd call the file /etc/hal/privilege-policy.d/storage.conf:
# List of numeric uid allowed to mount fixed media. If empty
anyone
# can mount fixed drives
PRIVPOL_STORAGE_FIXED="uid:davidz uid:dilbert gid:admins
gid:releng"
# List of numeric uid allowed to mount removable media. If
# empty anyone can mount removable media
PRIVPOL_STORAGE_REMOVABLE="uid:jane uid:john gid:admins
gid:secretaries"
# List of users and groups that are allowed mounting
# specific devices
PRIVPOL_STORAGE_WHITELIST=
"uid:dave:/org/fd/Hal/d/volume_uuid_43AC
uid:dogbert:/org/fd/Hal/d/volume_uuid_43AC
gid:coolkids:/org/fd/Hal/d/volume_uuid_43AC"
# List of users and groups that are prohibited mounting
specific
# devices
PRIVPOL_STORAGE_BLACKLIST=
"uid:bert:/org/fd/Hal/d/volume_uuid_43AC
uid:osama:/org/fd/Hal/d/volume_uuid_43AC
gid:lamers:/org/fd/Hal/d/volume_uuid_43AC"
This is a very simple text file that an administrator is expected to
understand. At least, that's the goal.
Ideally we'd write some tools to make this scheme easy for e.g.
hal-system-storage-mount and friends to use, e.g. said mounting script
could just invoke
hald-check-policy --file /etc/hal/privilege-policy.d/storage.conf \
--allowed-list PRIVPOL_STORAGE_FIXED \
--white-list PRIVPOL_STORAGE_WHITELIST \
--black-list PRIVPOL_STORAGE_BLACKLIST"
and get the result from there...
The thinking wrt. UI is that gnome-mount provides these dialogs that
simply reads and writes this configuration file. At some point in the
future we may want to mirror this in gconf to solve the LDAP case [3],
but eh, someone needs to show me a nice LDAP back-end for gconf before
that happens :-)
All this may well be over-engineered but I like the approach of having a
simple tool, hald-check-policy, that reads three variables from a file
denoting
1) What users and groups are allowed to do something
2) What users and groups are allowed to do something per-device
3) What users and groups are prohibited to do something per-device
This can be used to easily implement similar concepts for e.g. power
management, formatting, partitioning and what else we decide to put in
HAL. Would this fly? Comments welcome.
Cheers,
David
[1] : as an example, the volume.policy.* fiasco clearly showed it was
way too complicated - it was an useful learning experience (for me
personally at least) on how one can over-engineer and/or over-complicate
something. Nuff said.
[2] : if he is just a mere mortal, e.g. not in an admin group or
whatever, then maybe he won't. That's a user interaction question and
outside the scope of this mail
[3] : an admin can make a site-wide change to allow all members of group
'beancounters' to mount the volume "Secure Financial Data"
More information about the hal
mailing list