Allow unprivileged users to create commands other users can call on behalf of this unprivileged user

[hilbix]

suid is suid root. It is clumsy to have the need to create another variant which is suid user.

Being able to easily delegate with a sound and safe security barrier is important. Hence there should be a very easy way to implement this such that it is usable and stops possible errors due to complexity.

Note that this probably contradicts #3

• We cannot have both easily:
  • softlinks for commands and softlinks for delegation
  • Using hardlinks is not an option, as suid ususally is in /usr/local/bin/ (currently) where only root can create hardlinks
• However commands can be easily implemented with just a single line of shell script, where delegation is extremely complex.

Hence delegation should be favored.

Delegation would involve following steps:

• Permission of the user to softlink to suid.
• Delegation of the given user to provide configuration files which then are executed by the available user/group of the user

This should automatically include /etc/subid and /etc/subgid as follows:

• positive uids/gids (and names) are mapped to the system IDs
• negative uids/gids are taken from /etc/subid and /etc/subgid accordingly where -1 is the first sub-id.
• Why? Because a user might want to use the same configuration on different systems with different sub-id mappings

New directory /etc/suid/:

• Must be owned by root and must not be writable by others.
  • It can be writeable by group.
  • If the invoking user has no access rights to /etc/suid/, this option is not available for the user
  • This behavior must be added to /etc/suid.conf and /etc/suid.conf.d/ as well (before you could restrict access on suid directly, but if you want to open this for everybody but continue to restrict access to suid, then you need a new option).
• Entries in this directory are subdirectories with the user directories, named after the user's NAME
  • In case of a softlink, the softlink must be owned by root, group root or the group of /etc/suid/..
• Each subdirectory must be owned by the user and must not be writable by others.
  • It is ok if the UID belongs to the user from /etc/subuid
  • Group writable is ok as long as it is either root or a group the user belongs to or is available in /etc/subgid for the user
• Each entry within the subdirectory must be from the user again.
  • Again each /etc/subuid and /etc/subgid is considered to be from the user!

Entries from these directories can be accessed with:

• suid NAME/command
• A softlink which is named after the NAME
  • In case of some ambiguity, the softlink is read and evaluated again
  • If no match is found in /etc/suid/, this is an error
• Note that NAME must exist as user to be usable

Notes:

• Delegation allows a secondary suid environment for root using the user root
  • Perhaps it even allows more, as you can map more than one user to root
  • However this is not recommended as it might open accidental insecurities
• There is no need for a secondary delegation for things like Linux Containers, as this already is available to unprivileged users.
• There is no "global" configuration fed into the delgations, so /etc/suid.conf is not available in the delegated context
• A user who delegates this way, exports these commands to all and everybody on the machine, always and without limitation.
  • You cannot use the usual filesystem tricks to lock out somebody again (like hiding the softlink in some directory) because each user can create appropriate softlinks.
  • Example (note that the second softlink /usr/local/bin/max.mustermann is not recommended for general implementation):
    ln -s /home/max.mustermann/etc/suid.conf.d /etc/suid/max.mustermann
ln -s suid /usr/local/bin/max.mustermann
  • User does ln -s /usr/local/bin/max.mustermann $HOME/bin/max
  • If /usr/local/bin/max.mustermann is missing, following works, too:
    ln -s /usr/local/bin/suid $HOME/etc/max.mustermann
ln -s $HOME/etc/max.mustermann $HOME/bin/max
  • The latter is what exactly is intended:
    /etc/suid/ provides the ability to export by the user and is the single source which is needed
    and there is no need to pollute the global $PATH or even provide it

General delegation:

• I have no intent to implement general delegation, such that each user can provide suid commands
• This should be implemented using pam_exec which adds the ability to users of a certain group
  • do not forget to remove the rights when the group is missing.