PolicyKit Library Reference Manual |
---|
polkit-authpolkit-auth — Manage authorizations |
Synopsis
polkit-auth
[--obtain
] [action
--show-obtainable
] [[
] [--user
] --explicituser
[
] [--user
] --explicit-detailuser
[
[--user
] --grant user
action
--constraint
]*] [constraint
[
[--user
] --block user
action
--constraint
]*] [constraint
[
] [--user
] --revoke user
action
--version
] [--help
]
DESCRIPTION
polkit-auth is used to inspect, obtain, grant and revoke PolicyKit authorizations. If invoked without any options, the authorizations of the calling process will be printed.
OPTIONS
|
Attempt to obtain an authorization through authentication
for the given action. This is only useful for implicit
authorizations requiring authentication; e.g. when an
appropriate stanza in the defaults section of the .policy
file for the action specifies
The gained authorization will be constrained as much as possible using the constraints specified in the section called “CONSTRAINTS”. For example, on a system running SELinux, if the caller runs uses this tool to obtain an authorization from a shell in a desktop in an active session, then constraints for local, active, exe and selinux_context will all be added. If an Authentication Agent (such as the one from PolicyKit-gnome) is available in the session, it will used for authentication unless the environment variable POLKIT_AUTH_FORCE_TEXT is set. If the environment variable POLKIT_AUTH_GRANT_TO_PID is set, the authorization will be granted to that process id instead of the invoking process (e.g. the shell from which polkit-auth is launched). |
|
Prints all actions that can be obtained via authentication and for which an authorization does not exist. |
|
Show explicit authorizations. Duplicates are not
printed. If used with the |
|
Show detailed information about explicit
authorizations. In contrast to
the |
|
Grant an authorization for an action. This is different
than |
|
Grant an negative authorization for an action. Negative
authorizations are normally used to block users that would
normally be authorized due to implicit
authorizations. Optionally, one or more constraints on the
granted authorization can be specified, see
the section called “CONSTRAINTS” for details. The
authorization needed to grant negative authorizations is
|
|
Revoke all authorizations for an action. If the user is
not specified the calling user is used. The
authorization |
|
Show version and exit. |
|
Show this information. |
CONSTRAINTS
One can put one or more constraints on an authorization. They are used to limit where the authrorization applies. Presently the following constraints are supported
|
The caller must be in a session on a local console attached to the system. For example processes that belong to remote XDMCP or ssh connections will fail to meet this constraint and as such the authorization with such a constraint won't apply. |
|
The caller must be in an active session. This is typically used with a local constraint to ensure that the caller is only authorized if his session is in the foreground. This is typically used for fast user switching (multiple sessions on the same console) to prevent inactive sessions from doing privileged operations like spying (using a webcam or a sound card) on the current active session. |
|
The authorization is constrained to processes for where
executable path ( |
|
The authorization is constrained to processes for where their SELinux security context matches the given context. |
NOTES
Note that the executable path for a process is not necessary
reliable information and as such shouldn't be relied on 100% to
make a security decision. In fact, this information is only
trustworthy in situations where the given binary is securely
locked down meaning that 1) it can't
be ptrace(2)
'd; 2) libc secure mode kicks in
(e.g LD_PRELOAD
won't work); 3) there are no
other attack vectors (e.g. GTK_MODULES, X11, CORBA, D-Bus) to
patch running code into the process.
In other words: the risk of relying on constraining an
authorization to a path of an executable is high. Suppose that
the program /usr/bin/gullible
obtains an
authorization via authentication for the action
org.example.foo
. We add a constraint to say
that the gained authorization only applies to processes for whom
/proc/pid/exe
points to
/usr/bin/gullible
.
Now enter /usr/bin/evil
. It knows that the
program /usr/bin/gullible
is not "securely
locked down" (per the definition in the above paragraph). So
/usr/bin/evil
simply sets
LD_PRELOAD
and execs
/usr/bin/gullible
and it can now run code in a
process where /proc/pid/exe
points to
/usr/bin/gullible
. Thus, the recently gained
authorization for org.example.foo
applies. Also,
/usr/bin/evil
could use a host of other attack
vectors to run it's own code under the disguise of pretending to be
/usr/bin/gullible
.
Specifically for interpreted languages like Python and Mono it
is the case that /proc/pid/exe
always points
to
/usr/bin/python
resp. /usr/bin/mono
. Thus, it's not very useful
to rely on that the result for this function if you want to
constrain an authorization to
e.g. /usr/bin/tomboy
or
/usr/bin/banshee
.
It is however possible to write programs that are "securely
locked down" (per the definition in the above paragraph); for
example all properly written setuid
and setgid
programs are written in this way.
COMPLETION
PolicyKit ships with a collection of shell functions such that
completion on users, actions and constraints work when using the
bash(1)
shell. For completion to properly work for polkit-auth,
arguments should be entered in the order specified in this
manual page; for example. --user
should be
specified before --revoke
to complete only on
the authorizations the given user has. Note that if the calling
user lacks the org.freedesktop.policykit.read
authorization, the completion function will fall back to
completing on all registered actions.
BUGS
Please send bug reports to either the distribution or the hal mailing list, see http://lists.freedesktop.org/mailman/listinfo/hal. to subscribe.