Lines Matching full:user
8 allowing a user to set up user namespace UID mappings.
14 to switch to a different user must be spawned with CAP_SETUID privileges.
16 user that have been explicitly given the CAP_SETUID runtime capability. It is
19 privileges opens up possible security holes since any user with access to the
24 tree of processes under non-root user(s) in the first place. Specifically,
25 since CAP_SETUID allows changing to any user on the system, including the root
26 user, it is an overpowered capability for what is needed in this scenario,
28 lesser-privileged user -- not elevate privileges. Unfortunately, there is no
29 generally feasible way in Linux to restrict the potential UIDs that a user can
30 switch to through setuid() beyond allowing a switch to any user on the system.
39 do any unapproved actions (e.g. setuid to uid 0 or create/enter new user
66 Use user namespaces
68 Another possible approach would be to run a given process tree in its own user
71 own user namespace, and only approved UIDs/GIDs could be mapped back to the
72 initial system user namespace, affectively preventing privilege escalation.
73 Unfortunately, it is not generally feasible to use user namespaces in isolation,
75 Linux checks for capabilities based off of the user namespace that ???owns??? some
77 the user namespace in which they were created. A consequence of this is that
79 whether a task has the given capability in the context of the user namespace
80 that owns the network namespace -- not necessarily the user namespace under
81 which the given task runs. Therefore spawning a process in a new user namespace
85 configurations. Using user namespaces in isolation causes problems regarding
106 obtaining auxiliary setid privileges, such as allowing a user to set up user