semanage-user

title: semanage-user(8)

text:
# semanage-user(8)

## NAME
semanage-user - SELinux Policy Management SELinux User mapping tool

## SYNOPSIS
semanage user [-h] [-n] [-N] [-S STORE] [ --add ( -L LEVEL -R ROLES -r RANGE SEUSER) | --delete SEUSER | --deleteall | --extract | --list [-C] | --modify ( -L LEVEL -R ROLES -r RANGE SEUSER ) ]

## DESCRIPTION
semanage is used to configure certain elements of SELinux policy without requiring modification to or recompilation from policy sources. semanage user controls the mapping between an SELinux User and the roles and MLS/MCS levels.

## OPTIONS
-h, --help

Show this help message and exit

-n, --noheading

Do not print heading when listing the specified object type

-N, --noreload

Do not reload policy after commit

-S STORE, --store STORE

Select an alternate SELinux Policy Store to manage

-C, --locallist

List local customizations

-a, --add

Add a record of the specified object type

-d, --delete

Delete a record of the specified object type

-m, --modify

Modify a record of the specified object type

-l, --list

List records of the specified object type

-E, --extract

Extract customizable commands, for use within a transaction

-D, --deleteall

Remove all local customizations

-L LEVEL, --level LEVEL

Default SELinux Level for SELinux user, s0 Default. (MLS/MCS Systems only)

-r RANGE, --range RANGE

MLS/MCS Security Range (MLS/MCS Systems only) SELinux Range for SELinux login mapping defaults to the SELinux user record range. SELinux Range for SELinux user defaults to s0.

-R [ROLES], --roles [ROLES]

SELinux Roles. You must enclose multiple roles within quotes, separate by spaces. Or specify -R multiple times.

## EXAMPLE

```
List SELinux users
# semanage user -l
Modify groups for staff_u user
# semanage user -m -R "system_r unconfined_r staff_r" staff_u
Assign user topsecret_u role staff_r and range s0-TopSecret
# semanage user -a -R "staff_r" -rs0-TopSecret topsecret_u
```

## SEE ALSO
selinux(8), semanage(8), semanage-login(8)

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>


semodule

package: policycoreutils

title: semodule(8)

summary: Manage SELinux policy modules.

text:
# semodule(8)

## NAME
semodule - Manage SELinux policy modules.

## SYNOPSIS
semodule [option]... MODE...

## DESCRIPTION
semodule is the tool used to manage SELinux policy modules, including installing, upgrading, listing and removing modules. semodule may also be used to force a rebuild of policy from the module store and/or to force a reload of policy without performing any other transaction. semodule acts on module packages created by semodule_package. Conventionally, these files have a .pp suffix (policy package), although this is not mandated in any way.

## MODES
-R, --reload

force a reload of policy

-B, --build

force a rebuild of policy (also reloads unless -n is used)

--refresh

Like --build, but reuses existing linked policy if no changes to module files are detected (by comparing with checksum from the last transaction). One can use this instead of -B to ensure that any changes to the module store done by an external tool (e.g. a package manager) are applied, while automatically skipping the module re-linking if there are no module changes.

-D, --disable_dontaudit

Temporarily remove dontaudits from policy. Reverts whenever policy is rebuilt

-i,--install=MODULE_PKG

install/replace a module package

-u,--upgrade=MODULE_PKG

deprecated, alias for --install

-b,--base=MODULE_PKG

deprecated, alias for --install

-r,--remove=MODULE_NAME

remove existing module at desired priority (defaults to -X 400)

-l[KIND],--list-modules[=KIND]

display list of installed modules (other than base)

KIND:

standard

list highest priority, enabled, non-base modules

full

list all modules

-X,--priority=PRIORITY

set priority for following operations (1-999)

-e,--enable=MODULE_NAME

enable module

-d,--disable=MODULE_NAME

disable module

-E,--extract=MODULE_PKG

Extract a module from the store as an HLL or CIL file to the current directory. A module is extracted as HLL by default. The name of the module written is <module-name>.<lang_ext>

## OPTIONS
-s,--store

name of the store to operate on

-n,--noreload,-N

do not reload policy after commit

-h,--help

prints help message and quit

-P,--preserve_tunables

Preserve tunables in policy

-C,--ignore-module-cache

Recompile CIL modules built from HLL files

-p,--path

Use an alternate path for the policy root

-S,--store-path

Use an alternate path for the policy store root

-v,--verbose

be verbose

-c,--cil

Extract module as a CIL file. This only affects the --extract option and only modules listed in --extract after this option.

-H,--hll

Extract module as an HLL file. This only affects the --extract option and only modules listed in --extract after this option.

-m,--checksum

Add SHA256 checksum of modules to the list output.

## EXAMPLE

```
# Install or replace a base policy package.
$ semodule -b base.pp
# Install or replace a non-base policy package.
$ semodule -i httpd.pp
# Install or replace all non-base modules in the current directory.
# This syntax can be used with -i/u/r/E, but no other option can be entered after the module names
$ semodule -i *.pp
# Install or replace all modules in the current directory.
$ ls *.pp | grep -Ev "base.pp|enableaudit.pp" | xargs /usr/sbin/semodule -b base.pp -i
# List non-base modules.
$ semodule -l
# List all modules including priorities
$ semodule -lfull
# Remove a module at priority 100
$ semodule -X 100 -r wireshark
# Turn on all AVC Messages for which SELinux currently is "dontaudit"ing.
$ semodule -DB
# Turn "dontaudit" rules back on.
$ semodule -B
# Disable a module (all instances of given module across priorities will be disabled).
$ semodule -d alsa
# Install a module at a specific priority.
$ semodule -X 100 -i alsa.pp
# Set an alternate path for the policy root
$ semodule -B -p "/tmp"
# Set an alternate path for the policy store root
$ semodule -B -S "/tmp/var/lib/selinux"
# Write the HLL version of puppet and the CIL version of wireshark
# modules at priority 400 to the current working directory
$ semodule -X 400 --hll -E puppet --cil -E wireshark
# Check whether a module in "localmodule.pp" file is same as installed module "localmodule"
$ /usr/libexec/selinux/hll/pp localmodule.pp | sha256sum
$ semodule -l -m | grep localmodule
# Translate binary module file into CIL (useful for debugging installation errors)
$ /usr/libexec/selinux/hll/pp alsa.pp > alsa.cil
```

## SEE ALSO
checkmodule(8), semodule_package(8)

## AUTHORS

```
This manual page was written by Dan Walsh <dwalsh@redhat.com>.
The program was written by Karl MacMillan <kmacmillan@tresys.com>, Joshua Brindle <jbrindle@tresys.com>, Jason Tang <jtang@tresys.com>
```


title: semodule_package(8)

summary: Create a SELinux policy module package.

text:
# semodule_package(8)

## NAME
semodule_package - Create a SELinux policy module package.

## SYNOPSIS
semodule_package -o <output file> -m <module> [-f <file contexts>]

## DESCRIPTION
semodule_package is the tool used to create a SELinux policy module package from a binary policy module and optionally other data such as file contexts. semodule_package packages binary policy modules created by checkmodule. The policy package created by semodule_package can then be installed via semodule.

## EXAMPLE

```
# Build a policy package for a base module.
$ semodule_package -o base.pp -m base.mod -f file_contexts
# Build a policy package for a httpd module.
$ semodule_package -o httpd.pp -m httpd.mod -f httpd.fc
# Build a policy package for local TE rules and no file contexts.
$ semodule_package -o local.pp -m local.mod
```

## OPTIONS
-o --outfile <output file>

Policy module package file generated by this tool.

-s --seuser <seuser file>

seuser file to be included in the package.

-u --user_extra <user extra file>

user_extra file to be included in the package.

-m --module <Module file>

Policy module file to be included in the package.

-f --fc <File context file>

File contexts file for the module (optional).

-n --nc <netfilter context file>

netfilter context file to be included in the package.

-h --help

Show help message.

## SEE ALSO
checkmodule(8), semodule(8), semodule_unpackage(8)

## AUTHORS

```
This manual page was written by Dan Walsh <dwalsh@redhat.com>.
The program was written by Karl MacMillan <kmacmillan@tresys.com>
```


sestatus

title: sestatus(8)

summary: SELinux status tool

text:
# sestatus(8)

## NAME
sestatus - SELinux status tool

## SYNOPSIS
sestatus [-v] [-b]

This tool is used to get the status of a system running SELinux.

## DESCRIPTION
This manual page describes the sestatus program.

This tool is used to get the status of a system running SELinux. It displays data about whether SELinux is enabled or disabled, location of key directories, and the loaded policy with its status as shown in the example:

> sestatus

SELinux status: enabled

SELinuxfs mount: /selinux

SELinux root directory: /etc/selinux

Loaded policy name: targeted

Current mode: permissive

Mode from config file: enforcing

Policy MLS status: enabled

Policy deny_unknown status: allow

Memory protection checking: actual (secure)

Max kernel policy version: 26

sestatus can also be used to display:

-

The security context of files and processes listed in the /etc/sestatus.conf file. The format of this file is described in sestatus.conf(5).

-

The status of booleans.

## OPTIONS
-v

Displays the contexts of files and processes listed in the /etc/sestatus.conf file. It also checks whether the file is a symbolic link, if so then the context of the target file is also shown. The following contexts will always be displayed:

The current process context

The init process context

The controlling terminal file context

-b

Display the current state of booleans.

## FILES
/etc/sestatus.conf

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>.

The program was written by Chris PeBenito <pebenito@gentoo.org>

## SEE ALSO
selinux(8), sestatus.conf(5)


setfiles

title: setfiles(8)

summary: set SELinux file security contexts.

text:
# setfiles(8)

## NAME
setfiles - set SELinux file security contexts.

## SYNOPSIS
setfiles [-c policy] [-C] [-d] [-l] [-m] [-n] [-e directory] [-E] [-p] [-s] [-v] [-W] [-F] [-I|-D] [-T nthreads] spec_file pathname ...

## DESCRIPTION
This manual page describes the setfiles program.

This program is primarily used to initialize the security context fields (extended attributes) on one or more filesystems (or parts of them). Usually it is initially run as part of the SELinux installation process (a step commonly known as labeling).

It can also be run at any other time to correct inconsistent labels, to add support for newly-installed policy or, by using the -n option, to passively check whether the file contexts are all set as specified by the active policy (default behavior) or by some other policy (see the -c option).

If a file object does not have a context, setfiles will write the default context to the file object's extended attributes. If a file object has a context, setfiles will only modify the type portion of the security context. The -F option will force a replacement of the entire context.

## OPTIONS
-c

check the validity of the contexts against the specified binary policy.

-C

If only relabeling errors are encountered during the file tree walks, exit with status 1 rather than 255.

-d

show what specification matched each file.

-e directory

directory to exclude (repeat option for more than one directory).

-E

treat conflicting specifications as errors, such as where two hardlinks for the same inode have different contexts.

-f infilename

infilename contains a list of files to be processed. Use “-” for stdin.

-F

Force reset of context to match file_context for customizable files, and the default file context, changing the user, role, range portion as well as the type.

-h, -?

display usage information and exit.

-i

ignore files that do not exist.

-I

ignore digest to force checking of labels even if the stored SHA1 digest matches the specfiles SHA1 digest. The digest will then be updated provided there are no errors. See the NOTES section for further details.

-D

Set or update any directory SHA1 digests. Use this option to enable usage of the security.sehash extended attribute.

-l

log changes in file labels to syslog.

-m

do not read /proc/mounts to obtain a list of non-seclabel mounts to be excluded from relabeling checks. Setting this option is useful where there is a non-seclabel fs mounted with a seclabel fs mounted on a directory below this.

-n

don't change any file labels (passive check).

-o outfilename

Deprecated - This option is no longer supported.

-p

show progress by printing the number of files in 1k blocks unless relabeling the entire OS, that will then show the approximate percentage complete. Note that the -p and -v options are mutually exclusive.

-q

Deprecated and replaced by -v. Has no effect on other options or on program behavior.

-r rootpath

use an alternate root path. Used in meta-selinux for OpenEmbedded/Yocto builds to label files under rootpath as if they were at /

-s

take a list of files from standard input instead of using a pathname from the command line (equivalent to “-f -” ).

-v

show changes in file labels and output any inode association parameters. Note that the -v and -p options are mutually exclusive.

-W

display warnings about entries that had no matching files by outputting the selabel_stats(3) results.

-0

the separator for the input items is assumed to be the null character (instead of the white space). The quotes and the backslash characters are also treated as normal characters that can form valid input. This option finally also disables the end of file string, which is treated like any other argument. Useful when input items might contain white space, quote marks or backslashes. The -print0 option of GNU find produces input suitable for this mode.

-T nthreads

use up to nthreads threads. Specify 0 to create as many threads as there are available CPU cores; 1 to use only a single thread (default); or any positive number to use the given number of threads (if possible).

## ARGUMENTS
spec_file

The specification file which contains lines of the following form:

regexp [type] context | <<none>> The regular expression is anchored at both ends. The optional type field specifies the file type as shown in the mode field by the ls(1) program, e.g. -- to match only regular files or -d to match only directories. The context can be an ordinary security context or the string <<none>> to specify that the file is not to have its context changed.

The last matching specification is used. If there are multiple hard links to a file that match different specifications and those specifications indicate different security contexts, then a warning is displayed but the file is still labeled based on the last matching specification other than <<none>>.

pathname ...

The pathname for the root directory of each file system to be relabeled or a specific directory within a filesystem that should be recursively descended and relabeled or the pathname of a file that should be relabeled. Not used if the -f or the -s option is used.

## EXIT STATUS
setfiles exits with status 0 if it encounters no errors. Fatal errors result in status 255. Labeling errors encountered during file tree walk(s) result in status 1 if the -C option is specified and no other kind of error is encountered, and in status 255 otherwise.

## NOTES
1.

setfiles operates recursively on directories. Paths leading up the final component of the file(s) are not canonicalized before labeling.

2.

If the pathname specifies the root directory and the -v option is set and the audit system is running, then an audit event is automatically logged stating that a "mass relabel" took place using the message label FS_RELABEL.

3.

To improve performance when relabeling file systems recursively the -D option to setfiles will cause it to store a SHA1 digest of the spec_file set in an extended attribute named security.sehash on each directory specified in pathname ... once the relabeling has been completed successfully. These digests will be checked should setfiles -D be rerun with the same spec_file and pathname parameters. See selinux_restorecon(3) for further details. The -I option will ignore the SHA1 digest from each directory specified in pathname ... and provided the -n option is NOT set, files will be relabeled as required with the digests then being updated provided there are no errors.

## EXAMPLE

```
Fix labeling of /var/www/ including all sub-directories, using targeted policy file context definitions and list all context changes
# setfiles -v /etc/selinux/targeted/contexts/files/file_contexts /var/www/
List mislabeled files in user home directory and what the label should be based on targeted policy file context definitions
# setfiles -nv /etc/selinux/targeted/contexts/files/file_contexts ~
Fix labeling of files listed in file_list file, ignoring any that do not exist
# setfiles -vif file_list /etc/selinux/targeted/contexts/files/file_contexts
```

## AUTHOR
This man page was written by Russell Coker <russell@coker.com.au>. The program was written by Stephen Smalley <stephen.smalley.work@gmail.com>

## SEE ALSO
restorecon(8), load_policy(8), checkpolicy(8)


setsebool

title: setsebool(8)

summary: set SELinux boolean value

text:
# setsebool(8)

## NAME
setsebool - set SELinux boolean value

## SYNOPSIS
setsebool [ -PNV ] boolean value | bool1=val1 bool2=val2 ...

## DESCRIPTION
setsebool sets the current state of a particular SELinux boolean or a list of booleans to a given value. The value may be 1 or true or on to enable the boolean, or 0 or false or off to disable it.

Without the -P option, only the current boolean value is affected; the boot-time default settings are not changed.

If the -P option is given, all pending values are written to the policy file on disk. So they will be persistent across reboots.

If the -N option is given, the policy on disk is not reloaded into the kernel.

If the -V option is given, verbose error messages will be printed from semanage libraries.

## EXAMPLE

```
Enable container_use_devices boolean (will return to persistent value after reboot)
# setsebool container_use_devices 1
Persistently enable samba_create_home_dirs and samba_enable_home_dirs booleans
# setsebool -P samba_create_home_dirs=on samba_enable_home_dirs=on
```

## AUTHOR
This manual page was written by Dan Walsh <dwalsh@redhat.com>. The program was written by Tresys Technology.

## SEE ALSO
getsebool(8), booleans(8), togglesebool(8), semanage(8)


package: policycoreutils-devel

title: semodule_expand(8)

summary: Expand a SELinux policy module package.

text:
# semodule_expand(8)

## NAME
semodule_expand - Expand a SELinux policy module package.

## SYNOPSIS
semodule_expand [-ahV] [ -c [version]] basemodpkg outputfile

## DESCRIPTION
semodule_expand is a developer tool for manually expanding a base policy module package into a kernel binary policy file. This tool is not necessary for normal operation of SELinux. In normal operation, such expanding is performed internally by libsemanage in response to semodule commands. Base policy module packages can be created directly by semodule_package or by semodule_link (when linking together a set of packages into a single package).

## OPTIONS
-h

show help

-V

show version

-c [version]

policy version to create

-a

Do not check assertions. This will cause the policy to not check any neverallow rules.

## SEE ALSO
checkmodule(8), semodule_package(8), semodule(8), semodule_link(8) (8),

## AUTHORS

```
This manual page was written by Dan Walsh <dwalsh@redhat.com>.
The program was written by Karl MacMillan <kmacmillan@tresys.com>, Joshua Brindle <jbrindle@tresys.com>
```


title: semodule_link(8)

text:
# semodule_link(8)

## NAME
semodule_link - Link SELinux policy module packages together

## SYNOPSIS
semodule_link [-hVv] [-o outfile] basemodpkg modpkg1 [modpkg2]...

## DESCRIPTION
semodule_link is a developer tool for manually linking together a set of SELinux policy module packages into a single policy module package. This tool is not necessary for normal operation of SELinux. In normal operation, such linking is performed internally by libsemanage in response to semodule commands. Module packages are created by semodule_package.

## OPTIONS
-h

show help

-V

show version

-v

verbose mode

-o <output file>

Linked policy module package generated by this tool.

## SEE ALSO
checkmodule(8), semodule_package(8), semodule(8), semodule_expand(8) (8),

## AUTHORS

```
This manual page was written by Dan Walsh <dwalsh@redhat.com>.
The program was written by Karl MacMillan <kmacmillan@tresys.com>
```


title: semodule_unpackage(8)

text:
# semodule_unpackage(8)

## NAME
semodule_unpackage - Extract policy module and file context file from an SELinux policy module package.

## SYNOPSIS
semodule_unpackage ppfile modfile [fcfile]

## DESCRIPTION
semodule_unpackage is a tool used to extract SELinux policy module file and file context file from an SELinux Policy Package.

## EXAMPLE

```
# Extract the httpd module file from httpd policy package.
$ semodule_unpackage httpd.pp httpd.mod httpd.fc
```

## SEE ALSO
semodule_package(8)

## AUTHORS

```
This manual page was written by Dan Walsh <dwalsh@redhat.com>.
The program was written by Stephen Smalley <stephen.smalley.work@gmail.com>
```


sepolicy

title: sepolicy(8)

summary: SELinux Policy Inspection tool

text:
# sepolicy(8)

## NAME
sepolicy - SELinux Policy Inspection tool

## SYNOPSIS
sepolicy [-h] [-P policy_path ] {booleans,communicate,generate,interface,manpage,network,transition} OPTIONS

Arguments:

booleans

Query SELinux policy to see description of booleans sepolicy-boolean(8)

communicate

Query SELinux policy to see if domains can communicate with each other sepolicy-communicate(8)

generate

Generate SELinux Policy module template sepolicy-generate(8)

gui

Launch Graphical User Interface for SELinux Policy, requires policycoreutils-gui package. sepolicy-gui(8)

interface

Print SELinux Policy interface information sepolicy-interface(8)

manpage

Generate SELinux man pages sepolicy-manpage(8)

network

Query SELinux policy network information sepolicy-network(8)

transition

Query SELinux Policy to see how a source process domain can transition to the target process domain sepolicy-transition(8)

## DESCRIPTION
sepolicy is a tools set that will query the installed SELinux policy and generate useful reports, man pages, or even new policy modules. See the argument specific man pages for options and descriptions.

## OPTIONS
-P, --policy

Alternate policy to analyze. (Defaults to currently installed policy /sys/fs/selinux/policy)

-h, --help

Display help message

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>

## SEE ALSO
selinux(8), sepolicy-booleans(8), sepolicy-communicate(8), sepolicy-generate(8),sepolicy-gui(8), sepolicy-interface(8), sepolicy-network(8), sepolicy-manpage(8), sepolicy-transition(8)


sepolicy-booleans

title: sepolicy-booleans(8)

text:
# sepolicy-booleans(8)

## NAME
sepolicy-booleans - Query SELinux Policy to see description of booleans

## SYNOPSIS
sepolicy booleans [-h] [ -a | -b booleanname ... ]

## DESCRIPTION
sepolicy booleans will show all booleans and their descriptions, or you can choose individual booleans to display. Please make sure that selinux-policy-devel is present in your system since it contains boolean descriptions extracted from the policy source code. Otherwise sepolicy booleans will only show descriptions generated based on boolean names.

## OPTIONS
-h, --help

Display help message

-a, --all

Display all boolean descriptions

-b, --boolean

boolean to get description

## EXAMPLE

```
List descriptions of samba_create_home_dirs and samba_enable_home_dirs booleans
# sepolicy booleans -b samba_create_home_dirs samba_enable_home_dirs
```

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>

## SEE ALSO
sepolicy(8), selinux(8), getsebool(8), setsebool(8)


sepolicy-communicate

title: sepolicy-communicate(8)

text:
# sepolicy-communicate(8)

## NAME
sepolicy-communicate - Generate a report showing if two SELinux Policy Domains can communicate

## SYNOPSIS
sepolicy communicate [-h] -s SOURCE -t TARGET [-c TCLASS] [-S SOURCEACCESS] [-T TARGETACCESS]

## DESCRIPTION
Use sepolicy communicate to examine SELinux Policy and determine if a source SELinux Domain can communicate with a target SELinux Domain. The default command looks to see if there are any file types that the source domain can write, which the target domain can read.

## OPTIONS
-c, --class

Specify the SELinux class which the source domain will attempt to communicate with the target domain. (Default file)

-h, --help

Display help message

-s, --source

Specify the source SELinux domain type.

-S, --sourceaccess

Specify the list of accesses used by the source SELinux domain type to communicate with the target domain. Default Open, Write.

-t, --target

Specify the target SELinux domain type.

-T, --targetaccess

Specify the list of accesses used by the target SELinux domain type to receive communications from the source domain. Default Open, Read.

## EXAMPLE

```
List types that can be used to communicate between samba daemon and apache server
# sepolicy communicate -s httpd_t -t smbd_t
Consider a type to be accessible by the source domain when it can be opened and appended to (as opposed to opened and written to)
# sepolicy communicate -s httpd_t -t smbd_t -S open,append
```

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>

## SEE ALSO
sepolicy(8), selinux(8)


sepolicy-generate

title: sepolicy-generate(8)

text:
# sepolicy-generate(8)

## NAME
sepolicy-generate - Generate an initial SELinux policy module template.

## SYNOPSIS
Common options

sepolicy generate [-h ] [-p PATH]

Confined Applications

sepolicy generate --application [-n NAME] [-u USER ]command [-w WRITE_PATH ]

sepolicy generate --cgi [-n NAME] command [-w WRITE_PATH ]

sepolicy generate --dbus [-n NAME] command [-w WRITE_PATH ]

sepolicy generate --inetd [-n NAME] command [-w WRITE_PATH ]

sepolicy generate --init [-n NAME] command [-w WRITE_PATH ]

Confined Users

sepolicy generate --admin_user [-r TRANSITION_ROLE] -n NAME

sepolicy generate --confined_admin -n NAME [-a ADMIN_DOMAIN] [-u USER] [-n NAME] [-w WRITE_PATH]

sepolicy generate --desktop_user -n NAME [-w WRITE_PATH]

sepolicy generate --term_user -n NAME [-w WRITE_PATH]

sepolicy generate --x_user -n NAME [-w WRITE_PATH]

Miscellaneous Policy

sepolicy generate --customize -d DOMAIN -n NAME [-a ADMIN_DOMAIN]

sepolicy generate --newtype -t type -n NAME

sepolicy generate --sandbox -n NAME

## DESCRIPTION
Use sepolicy generate to generate an SELinux policy Module.

sepolicy generate will create 5 files.

When specifying a confined application you must specify a path. sepolicy generate will use the rpm payload of the application along with nm -D APPLICATION to help it generate types and policy rules for your policy files.

NAME.te

This file can be used to define all the types enforcement rules for a particular domain.

Note: Policy generated by sepolicy generate will automatically add a permissive DOMAIN to your .te file. When you are satisfied that your policy works, you need to remove the permissive line from the .te file to run your domain in enforcing mode.

NAME.if

This file defines the interfaces for the types generated in the .te file, which can be used by other policy domains.

NAME.fc

This file defines the default file context for the system, it takes the file types created in the .te file and associates file paths to the types. Tools like restorecon and RPM will use these paths to put down labels.

NAME_selinux.spec

This file is an RPM SPEC file that can be used to install the SELinux policy on to machines and setup the labeling. The spec file also installs the interface file and a man page describing the policy. You can use sepolicy manpage -d NAME to generate the man page.

NAME.sh

This is a helper shell script to compile, install and fix the labeling on your test system. It will also generate a man page based on the installed policy, and compile and build an RPM suitable to be installed on other machines.

## OPTIONS
-h, --help

Display help message

-d, --domain

Enter domain type(s) which you will be extending

-n, --name

Specify alternate name of policy. The policy will default to the executable or name specified

-p, --path

Specify the directory to store the created policy files. (Default to current working directory )

optional arguments:

-r, --role

Enter role(s) to which this admin user will transition

-t, --type

Enter type(s) for which you will generate new definition and rule(s)

-u, --user

SELinux user(s) which will transition to this domain

-w, --writepath

Path(s) which the confined processes need to write to

-a, --admin

Domain(s) which the confined admin will administrate

--admin_user

Generate Policy for Administrator Login User Role

--application

Generate Policy for User Application

--cgi

Generate Policy for Web Application/Script (CGI)

--confined_admin

Generate Policy for Confined Root Administrator Role

--customize

Generate Policy for Existing Domain Type

--dbus

Generate Policy for DBUS System Daemon

--desktop_user

Generate Policy for Desktop Login User Role

--inetd

Generate Policy for Internet Services Daemon

--init

Generate Policy for Standard Init Daemon (Default)

--newtype

Generate new policy for new types to add to an existing policy

--sandbox

Generate Policy for Sandbox

--term_user

Generate Policy for Minimal Terminal Login User Role

--x_user

Generate Policy for Minimal X Windows Login User Role

## EXAMPLE
> sepolicy generate --init /usr/sbin/rwhod

Generating Policy for /usr/sbin/rwhod named rwhod

Created the following files:

rwhod.te # Type Enforcement file

rwhod.if # Interface file

rwhod.fc # File Contexts file

rwhod_selinux.spec # Spec file

rwhod.sh # Setup Script

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>

## SEE ALSO
sepolicy(8), selinux(8)


sepolicy-interface

title: sepolicy-interface(8)

text:
# sepolicy-interface(8)

## NAME
sepolicy-interface - Print interface information based on the installed SELinux Policy

## SYNOPSIS
sepolicy interface [-h] [-c] [-v] [-f FILE] [-a | -u | -l | -i INTERFACE [INTERFACE ... ]]

## DESCRIPTION
Use sepolicy interface to print information of interface macros between domains in SELinux policy modules, as used in Reference Policy. The information is based on installed on-disk representation of the SELinux Policy and it may be different from the policy which is currently loaded.

## OPTIONS
-a, --list_admin

List all domains with admin interface

-c, --compile

Test compile of interfaces

-h, --help

Display help message

-i, --interface

Interface(s) to be displayed

-l, --list

List all interfaces

-u, --list_user

List all domains with SELinux user role interface

-v, --verbose

Display extended information about the interface including parameters and description if available.

-f, --file

Interface file to be explored

## EXAMPLE

```
Show description of given interface
# sepolicy interface -vi samba_rw_config
List interfaces in given interface file and show their description
# sepolicy interface -f my_policy.if -lv
Run compile test for all interfaces in given file
# sepolicy interface -f my_policy.if -lc
```

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>

## SEE ALSO
sepolicy(8), selinux(8)


sepolicy-manpage

title: sepolicy-manpage(8)

text:
# sepolicy-manpage(8)

## NAME
sepolicy-manpage - Generate a man page based on the installed SELinux Policy

## SYNOPSIS
sepolicy manpage [-w] [-h] [-p PATH ] [-r ROOTDIR ] [-a | -d ]

## DESCRIPTION
Use sepolicy manpage to generate manpages based on SELinux Policy.

## OPTIONS
-a, --all

Generate Man Pages for All Domains

-d, --domain

Generate a Man Page for the specified domain. (Supports multiple commands)

-h, --help

Display help message

-o, --os

Specify the name of the OS to be used in the man page (only affects HTML man pages)

-p, --path

Specify the directory to store the created man pages. (Default to /tmp)

-r, --root

Specify alternative root directory to generate man pages from. (Default to /)

--source_files

Use file_contexts and policy.xml files from the specified root directory (the alternative root needs to include both files)

-w, --web

Generate an additional HTML man pages for the specified domain(s)

## EXAMPLE

```
Generate man pages for all available domains
# sepolicy manpage -a
Generate an HTML man page for domain alsa_t, setting the OS name to "My_distro"
# sepolicy manpage -o My_distro -d alsa_t -w
```

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>

## SEE ALSO
sepolicy(8), selinux(8)


sepolicy-network

title: sepolicy-network(8)

text:
# sepolicy-network(8)

## NAME
sepolicy-network - Examine the SELinux Policy and generate a network report

## SYNOPSIS
sepolicy network [-h] (-l | -a application [application ...] | -p PORT [PORT ...] | -t TYPE [TYPE ...] | -d DOMAIN [DOMAIN ...])

## DESCRIPTION
Use sepolicy network to examine SELinux Policy and generate network reports.

## OPTIONS
-a, --application

Generate a report listing the ports to which the specified init application is allowed to connect and or bind

-d, --domain

Generate a report listing the ports to which the specified domain is allowed to connect and or bind

-l, --list

List all Network Port Types defined in SELinux Policy

-h, --help

Display help message

-t, --type

Generate a report listing the port numbers associate with the specified SELinux port type

-p, --port

Generate a report listing the SELinux port types associate with the specified port number

## EXAMPLES
sepolicy network -p 22

22: tcp ssh_port_t 22

22: udp reserved_port_t 1-511

22: tcp reserved_port_t 1-511

sepolicy network -a /usr/sbin/sshd

sshd_t: tcp name_connect

111 (portmap_port_t)

53 (dns_port_t)

88, 750, 4444 (kerberos_port_t)

9080 (ocsp_port_t)

9180, 9701, 9443-9447 (pki_ca_port_t)

32768-61000 (ephemeral_port_t)

all ports < 1024 (reserved_port_type)

all ports with out defined types (port_t)

sshd_t: tcp name_bind

22 (ssh_port_t)

5900-5983, 5985-5999 (vnc_port_t)

6000-6020 (xserver_port_t)

32768-61000 (ephemeral_port_t)

all ports > 500 and < 1024 (rpc_port_type)

all ports with out defined types (port_t)

sshd_t: udp name_bind

32768-61000 (ephemeral_port_t)

all ports > 500 and < 1024 (rpc_port_type)

all ports with out defined types (port_t)

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>

## SEE ALSO
sepolicy(8), selinux(8), semanage(8)


sepolicy-transition

title: sepolicy-transition(8)

text:
# sepolicy-transition(8)

## NAME
sepolicy-transition - Examine the SELinux Policy and generate a process transition report

## SYNOPSIS
sepolicy transition [-h] -s SOURCE

sepolicy transition [-h] -s SOURCE -t TARGET

## DESCRIPTION
sepolicy transition will show all domains that a given SELinux source domain can transition to, including the entrypoint.

If a target domain is given, sepolicy transition will examine policy for all transition paths from the source domain to the target domain, and will list the paths.

## OPTIONS
-h, --help

Display help message

-s, --source

Specify the source SELinux domain type

-t, --target

Specify the target SELinux domain type

## EXAMPLE

```
List all domain transition paths from init_t to httpd_t
# sepolicy transition -s init_t -t httpd_t
List all transitions available from samba domain, including entry points and booleans controlling each transition
# sepolicy transition -s smbd_t
```

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>

## SEE ALSO
sepolicy(8), selinux(8)


selinux-polgengui

package: policycoreutils-gui

title: selinux-polgengui(8)

summary: SELinux Policy Generation Tool

text:
# selinux-polgengui(8)

## NAME
selinux-polgengui - SELinux Policy Generation Tool

## SYNOPSIS
selinux-polgengui

## DESCRIPTION
selinux-polgengui is a graphical tool, which can be used to create a framework for building SELinux Policy.

## OPTIONS
None

## FILES
/usr/bin/selinux-polgengui

## Examples
To run the program type:

selinux-polgengui

## SEE ALSO
selinux(1), sepolicy(8), sepolicy-generate(8)

## REPORTING BUGS
Report bugs to <http://bugzilla.redhat.com>.

## LICENSE AND AUTHORS
selinux-polgengui is licensed under the GNU General Public License and is copyrighted by Red Hat, Inc.

This man page was written by Daniel Walsh <dwalsh@redhat.com>


sepolicy-gui

title: sepolicy-gui(8)

text:
# sepolicy-gui(8)

## NAME
sepolicy-gui - Graphical User Interface for SELinux policy.

## SYNOPSIS
Common options

sepolicy gui [-h ] [ -d DOMAIN ]

## DESCRIPTION
Use sepolicy gui to run the graphical user interface, which allows you to explore how SELinux confines different process domains.

## OPTIONS
-h, --help

Display help message

-d, --domain

Initialize gui to the selected domain

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>

## SEE ALSO
sepolicy(8), selinux(8)


system-config-selinux

title: system-config-selinux(8)

summary: SELinux Management tool

text:
# system-config-selinux(8)

## NAME
system-config-selinux - SELinux Management tool

## SYNOPSIS
system-config-selinux

## DESCRIPTION
system-config-selinux provides a graphical interface for managing the SELinux configuration.

## OPTIONS
None

## FILES
/usr/bin/system-config-selinux

## Examples
To run the program type:

system-config-selinux

## SEE ALSO
selinux(1), semanage(8)

## REPORTING BUGS
Report bugs to <http://bugzilla.redhat.com>.

## LICENSE AND AUTHORS
system-config-selinux is licensed under the GNU General Public License and is copyrighted by Red Hat, Inc.

This man page was written by Daniel Walsh <dwalsh@redhat.com>


mcs

package: policycoreutils-mcstransd

title: mcs(8)

summary: Multi-Category System

text:
# mcs(8)

## NAME
mcs - Multi-Category System

## DESCRIPTION
MCS (Multiple Category System) allows users to label files on their system within administrator defined categories. It then uses SELinux Mandatory Access Control to protect those files. MCS is a discretionary model to allow users to mark their data with additional tags that further restrict access. The only mandatory aspect is authorizing users for categories by defining their clearance in policy. However, MCS is similar to MLS and exercises the same code paths and share the same support infrastructure. They just differ in their specific configuration.

The /etc/selinux/{SELINUXTYPE}/setrans.conf configuration file translates the labels on disk to human readable form. Administrators can define any labels they want in this file. Certain applications like printing and auditing will use these labels to identify the files. By setting a category on a file you will prevent other applications/services from having access to the files.

Examples of file labels would be PatientRecord, CompanyConfidential etc.

## SEE ALSO
selinux(8), chcon(1)

## FILES
/etc/selinux/{SELINUXTYPE}/setrans.conf


mcstransd

title: mcstransd(8)

text:
# mcstransd(8)

## NAME
mcstransd - MCS (Multiple Category System) daemon. Translates SELinux MCS/MLS labels to human readable form.

## SYNOPSIS
mcstransd [-f] [-h]

## DESCRIPTION
This manual page describes the mcstransd program.

This daemon reads /etc/selinux/{SELINUXTYPE}/setrans.conf configuration file, and communicates with libselinux via a socket in /var/run/setrans.

## OPTIONS
-f

Run mcstransd in the foreground. Do not run as a daemon.

-h

Output a short summary of available command line options.

## AUTHOR
This man page was written by Dan Walsh <dwalsh@redhat.com>. The program was originally written by Dan Walsh <dwalsh@redhat.com>. The program was enhanced/rewritten by Joe Nall <joe@nall.com>.

## FILES
/etc/selinux/{SELINUXTYPE}/setrans.conf

## SEE ALSO
setrans.conf(5),mcs(8)


restorecond

package: policycoreutils-restorecond

title: restorecond(8)

text:
# restorecond(8)

## NAME
restorecond - daemon that watches for file creation and then sets the default SELinux file context

## SYNOPSIS
restorecond [-d] [-h] [-f restorecond_file ] [-u] [-v]

## DESCRIPTION
This manual page describes the restorecond program.

This daemon uses inotify to watch files listed in the /etc/selinux/restorecond.conf, when they are created, this daemon will make sure they have the correct file context associated with the policy.

## OPTIONS
-d

Turns on debugging mode. Application will stay in the foreground and lots of debugs messages start printing.

-h

Print usage statement.

-f restorecond_file

Use alternative restorecond.conf file.

-u

Turns on user mode. Runs restorecond in the user session and reads /etc/selinux/restorecond_user.conf. Uses dbus to make sure only one restorecond is running per user session.

-v

Turns on verbose debugging. (Report missing files)

## AUTHOR
This man page and program was written by Dan Walsh <dwalsh@redhat.com>.

## FILES
/etc/selinux/restorecond.conf /etc/selinux/restorecond_user.conf

## SEE ALSO
restorecon(8),


sandbox

package: policycoreutils-sandbox

title: sandbox(8)

summary: Run cmd under an SELinux sandbox

text:
# sandbox(8)

## NAME
sandbox - Run cmd under an SELinux sandbox

## SYNOPSIS
sandbox [-C] [-s] [ -d DPI ] [-l level ] [[-M | -X] -H homedir -T tempdir ] [ -R runuserdir ] [-I includefile ] [ -W windowmanager ] [ -w windowsize ] [[-i file ]...] [ -t type ] cmd

sandbox [-C] [-s] [ -d DPI ] [-l level ] [[-M | -X] -H homedir -T tempdir ] [ -R runuserdir ] [-I includefile ] [ -W windowmanager ] [ -w windowsize ] [[-i file ]...] [ -t type ] -S

## DESCRIPTION
Run the cmd application within a tightly confined SELinux domain. The default sandbox domain only allows applications the ability to read and write stdin, stdout and any other file descriptors handed to it. It is not allowed to open any other files. The -M option will mount an alternate homedir and tmpdir to be used by the sandbox.

If you have the policycoreutils-sandbox package installed, you can use the -X option and the -M option. sandbox -X allows you to run X applications within a sandbox. These applications will start up their own X Server and create a temporary home directory and /tmp. The default SELinux policy does not allow any capabilities or network access. It also prevents all access to the users other processes and files. Files specified on the command that are in the home directory or /tmp will be copied into the sandbox directories.

If directories are specified with -H or -T the directory will have its context modified with chcon(1) unless a level is specified with -l. If the MLS/MCS security level is specified, the user is responsible to set the correct labels.

-h --help

display usage message

-H --homedir

Use alternate homedir to mount over your home directory. Defaults to temporary. Requires -X or -M.

-i --include

Copy this file into the appropriate temporary sandbox directory. Command can be repeated.

-I --includefile

Copy all files listed in inputfile into the appropriate temporary sandbox directories.

-l --level

Specify the MLS/MCS Security Level to run the sandbox with. Defaults to random.

-M --mount

Create a Sandbox with temporary files for $HOME and /tmp.

-s --shred

Shred temporary files created in $HOME and /tmp, before deleting.

-t --type

Use alternate sandbox type, defaults to sandbox_t or sandbox_x_t for -X. Examples:

sandbox_t - No X, No Network Access, No Open, read/write on passed in file descriptors.

sandbox_min_t - No Network Access

sandbox_x_t - Ports for X applications to run locally

sandbox_web_t - Ports required for web browsing

sandbox_net_t - Network ports (for server software)

sandbox_net_client_t - All network ports

-T --tmpdir

Use alternate temporary directory to mount on /tmp. Defaults to tmpfs. Requires -X or -M.

-R --runuserdir

Use alternate temporary directory to mount on XDG_RUNTIME_DIR (/run/user/$UID).

-S --session

Run a full desktop session, Requires level, and home and tmpdir.

-w --windowsize

Specifies the windowsize when creating an X based Sandbox. The default windowsize is 1000x700.

-W --windowmanager

Select alternative window manager to run within sandbox -X. Default to /usr/bin/openbox.

-X

Create an X based Sandbox for gui apps, temporary files for $HOME and /tmp, secondary Xserver, defaults to sandbox_x_t

-d --dpi

Set the DPI value for the sandbox X Server. Defaults to the current X Sever DPI.

-C --capabilities

Use capabilities within the sandbox. By default applications executed within the sandbox will not be allowed to use capabilities (setuid apps), with the -C flag, you can use programs requiring capabilities.

## SEE ALSO
runcon(1), seunshare(8), selinux(8)

## EXAMPLE

```
Run a graphical application inside the sandbox
# sandbox -X evince
Run a graphical application that requires the use of network
# sandbox ‑X ‑t sandbox_web_t firefox
Preserve data from one session to the next
# mkdir -p ~/sandbox/home ~/sandbox/tmp
# sandbox -H ~/sandbox/home -T ~/sandbox/tmp -X libreoffice --writer
```

## AUTHOR
This manual page was written by Dan Walsh <dwalsh@redhat.com> and Thomas Liu <tliu@fedoraproject.org>


seunshare

title: seunshare(8)

text:
# seunshare(8)

## NAME
seunshare - Run cmd with alternate homedir, tmpdir and/or SELinux context

## SYNOPSIS
seunshare [ -v ] [ -C ] [ -k ] [ -t tmpdir ] [ -h homedir ] [ -Z context ] -- executable [args]

## DESCRIPTION
Run the executable within the specified context, using custom home directory and /tmp directory. The seunshare command unshares from the default namespace, then mounts the specified homedir and tmpdir over the default homedir and /tmp. Finally it tells the kernel to execute the application under the specified SELinux context.

-h homedir

Alternate homedir to be used by the application. Homedir must be owned by the user

-t tmpdir

Use alternate temporary directory to mount on /tmp. tmpdir must be owned by the user

-r runuserdir

Use alternate temporary directory to mount on XDG_RUNTIME_DIR (/run/user/$UID). runuserdir must be owned by the user

-C --capabilities

Allow apps executed within the namespace to use capabilities. Default is no capabilities

-k --kill

Kill all processes with matching MCS level

-Z context

Use alternate SELinux context while running the executable

-v

Verbose output

## EXAMPLE

```
Run bash with temporary /home and /tmp directory
# USERHOMEDIR=`mktemp -d /tmp/home.XXXXXX`; USERTEMPDIR=`mktemp -d /tmp/temp.XXXXXX`
# seunshare -v -h ${USERHOMEDIR} -t ${USERTEMPDIR} -- /bin/bash
```

## SEE ALSO
runcon(1), sandbox(8), selinux(8)

## AUTHOR
This manual page was written by Dan Walsh <dwalsh@redhat.com> and Thomas Liu <tliu@fedoraproject.org>


policyd-weight

package: policyd-weight

title: policyd-weight(8)

summary: weighted SMTP policy daemon

text:
# policyd-weight(8)

## NAME
policyd-weight - weighted SMTP policy daemon

## STATUS
Beta, Documentation incomplete

## SYNOPSIS

```

```

policyd-weight [-option] [-option2 <arg>] command

## DESCRIPTION

policyd-weight(8) is a SMTP policy daemon written in perl(1) for postfix(1). It evaluates based on RBL/RHSBL results, HELO and MAIL FROM domain and subdomain arguments and the client IP address the possibility of forgery or SPAM. It is designed to be called before the SMTP DATA command at the RCPT TO stage. This way it is a) possible to reject a mail attempt before the body has been received and b) to keep multirecipient mail intact, i.e. provide the functionality of selective usage based on recipients.

To make policyd-weight(8) work with postfix(1), it is required to add a system account for $USER (default: polw)

Policyd-weight can operate in master.cf or daemon mode. In master.cf mode it uses postfix' spawn(8), which results in number of simultanous requests perl instances. In daemon mode it uses shared memory and forks on load, and only if all childs are busy.

At the time of writing the man-pages for policyd-weight assume a postfix installation. It has been reported that policyd-weight works with other MTAs like Exim, too.

## master.cf mode:
master.cf:

policy unix - n n - - spawn user=polw

argv=/usr/bin/perl /usr/local/bin/policyd-weight

main.cf:

smtpd_recipient_restrictions =

permit_mynetworks,

... authenticated permits ...

reject_unauth_destination,

... whitelists, role accounts, clients ...

check_policy_service unix:private/policy

## daemon mode:
start the daemon with policyd-weight start. Poliyd-weight then listens on $TCP_PORT (default: 12525) for policy requests. To make postfix talk to that port do following changes to main.cf:

main.cf:

smtpd_recipient_restrictions =

permit_mynetworks,

... authenticated permits ...

reject_unauth_destination,

... whitelists, role accounts, clients ...

check_policy_service inet:127.0.0.1:12525

It is possible to have more than one postfix server talk to the daemonized policyd-weight by configuring each postfix machine to query the policy server with check_policy_service inet:IP:12525 where IP is the host on which policyd-weight runs.

Please note that check_policy_service should come at last, or at least after reject_unauth_destination, or else you may become an open relay.

## COMMANDS

Following commands exist and are reserved for daemon mode only:

start start the policy server

stop stop the policy server

restart restart the policy server

reload tells the policy server to reload its configuration

defaults prints the default settings to STDOUT and exits

## OPTIONS

-d operate in debug mode

Not for use in master.cf. In debug mode everything is reported on STDOUT instead of syslog(3). Also an own debug cache daemon will be spawned. The socket-file is named after the value of $SPATH with ".debug" as suffix.

-f /path/to/file

Pass a configuration file to policyd-weight

-h show help

-k kill cache daemon

Not for use in master.cf. Together with -d this kills the debug cache daemon. Without -d it kills the global running cache daemon.

-s show cache entries

Not for use in master.cf.

-v show version

## LOGGING

Logging is done via syslog(3) with facility "mail" and priority "info". For a complete list of log entries and their correspondending configuration parameters refer to policyd-weight.conf(5).

## BUGS

```
Please report bugs to r.felber@ek-muc.de
```

## HISTORY

March 2005

Ralf Hildebrandt (Author of the Book of Postfix) is the spiritual father of policyd-weight. It was his idea to have a scored RBL evaluation, I've added the weighted MAIL FROM/HELO DNS-evaluation. For that purpose I used Meng Wong's spf.pl which was shipped with the postfix source as example.

## FILES

```
/etc/policyd-weight.conf, Policyd-weight configuration file
/etc/postfix/main.cf, Postfix configuration parameters
/etc/postfix/master.cf, Postfix daemon processes
```

## SEE ALSO

```
policyd-weight.conf(5), Policyd-weight configuration file
master(5), Postfix master.cf file syntax
postconf(5), Postfix main.cf file syntax
access(5), Postfix SMTP access control table
```

## LICENSE

```
GNU General Public License
```

## AUTHOR

```
Robert Felber <r.felber@ek-muc.de>
Autohaus Erich Kuttendreier
81827 Munich, Germany
```


polkit

package: polkit

title: polkit(8)

summary: Authorization Manager

text:
# polkit(8)

## NAME
polkit - Authorization Manager

## OVERVIEW
polkit provides an authorization API intended to be used by privileged programs (“MECHANISMS”) offering service to unprivileged programs (“SUBJECTS”) often through some form of inter-process communication mechanism. In this scenario, the mechanism typically treats the subject as untrusted. For every request from a subject, the mechanism needs to determine if the request is authorized or if it should refuse to service the subject. Using the polkit APIs, a mechanism can offload this decision to a trusted party: The polkit authority.

The polkit authority is implemented as an system daemon, polkitd(8), which itself has little privilege as it is running as the polkitd system user. Mechanisms, subjects and authentication agents communicate with the authority using the system message bus.

In addition to acting as an authority, polkit allows users to obtain temporary authorization through authenticating either an administrative user or the owner of the session the client belongs to. This is useful for scenarios where a mechanism needs to verify that the operator of the system really is the user or really is an administrative user.

## SYSTEM ARCHITECTURE
The system architecture of polkit is comprised of the Authority (implemented as a service on the system message bus) and an Authentication Agent per user session (provided and started by the user's graphical environment). Actions are defined by applications. Vendors, sites and system administrators can control authorization policy through Authorization Rules.

[IMAGE][1]

```
 +-------------------+

 |   Authentication  |

 |       Agent       |

 +-------------------+

 | libpolkit-agent-1 |

 +-------------------+

        ^                                  +---------+

        |                                  | Subject |

        +--------------+                   +---------+

                       |                        ^

                       |                        |
User Session           |                        |
=======================|========================|=============
System Context         |                        |

                       |                        |

                       |                    +---+

                       V                    |

                     /------------\         |

                     | System Bus |         |

                     \------------/         |

                       ^        ^           V

                       |        |      +---------------------+

        +--------------+        |      |      Mechanism      |

        |                       |      +---------------------+

        V                       +----> | libpolkit-gobject-1 |
+------------------+                   +---------------------+
|    polkitd(8)    |
+------------------+
| org.freedesktop. |
|    PolicyKit1    |<---------+
+------------------+          |

          ^                   |

          |            +--------------------------------------------+

          |            | /etc/polkit-1/actions/*.policy             |

          |            | /run/polkit-1/actions/*.policy             |

          |            | /usr/local/share/polkit-1/actions/*.policy |

          |            | /usr/share/polkit-1/actions/*.policy       |

          |            +--------------------------------------------+

          |

   +--------------------------------------------+

   | /etc/polkit-1/rules.d/*.rules              |

   | /run/polkit-1/rules.d/*.rules              |

   | /usr/local/share/polkit-1/rules.d/*.rules  |

   | /usr/share/polkit-1/rules.d/*.rules        |

   +--------------------------------------------+
```

For convenience, the libpolkit-gobject-1 library wraps the polkit D-Bus API and is usable from any C/C++ program as well as higher-level languages supporting GObjectIntrospection[2] such as JavaScript and Python. A mechanism can also use the D-Bus API or the pkcheck(1) command to check authorizations. The libpolkit-agent-1 library provides an abstraction of the native authentication system, e.g. pam(8) and also facilities for registration and communication with the polkit D-Bus service.

See the developer documentation[3] for more information about writing polkit applications.

## AUTHENTICATION AGENTS
An authentication agent is used to make the user of a session prove that the user of the session really is the user (by authenticating as the user) or an administrative user (by authenticating as an administrator). In order to integrate well with the rest of the user session (e.g. match the look and feel), authentication agents are meant to be provided by the user session that the user uses. For example, an authentication agent may look like this:

[IMAGE][4]

```
+----------------------------------------------------------+
|                                                          |
|  [Icon]  Authentication required                         |
|                                                          |
|          Authentication is required to format INTEL      |
|          SSDSA2MH080G1GC (/dev/sda)                      |
|                                                          |
|          Administrator                                   |
|                                                          |
|          Password: [__________________________________]  |
|                                                          |
| [Cancel]                                  [Authenticate] |
+----------------------------------------------------------+
```

If the system is configured without a root account, it may prompt for a specific user designated as the administrative user:

[IMAGE][5]

```
+----------------------------------------------------------+
|                                                          |
|  [Icon]  Authentication required                         |
|                                                          |
|          Authentication is required to format INTEL      |
|          SSDSA2MH080G1GC (/dev/sda)                      |
|                                                          |
|          [Icon] David Zeuthen                            |
|                                                          |
|          Password: [__________________________________]  |
|                                                          |
| [Cancel]                                  [Authenticate] |
+----------------------------------------------------------+
```

Applications that do not run under a desktop environment (for example, if launched from an ssh(1) login) may not have an authentication agent associated with them. Such applications may use the PolkitAgentTextListener type or the pkttyagent(1) helper so the user can authenticate using a textual interface.

## DECLARING ACTIONS
A mechanism needs to declare a set of actions in order to use polkit. Actions correspond to operations that clients can request the mechanism to carry out and are defined in XML files that the mechanism installs into the /usr/share/polkit-1/actions directory.

polkit actions are namespaced and can only contain the characters "[A-Z][a-z][0-9].-", e.g. ASCII, digits, period and hyphen. Each XML file can contain more than one action but all actions need to be in the same namespace and the file needs to be named after the namespace and have the extension .policy.

The XML file must have the following doctype declaration

```
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD polkit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/software/polkit/policyconfig-1.dtd">
```

The policyconfig element must be present exactly once. Elements that can be used inside policyconfig includes:

vendor

The name of the project or vendor that is supplying the actions in the XML document. Optional.

vendor_url

A URL to the project or vendor that is supplying the actions in the XML document. Optional.

icon_name

An icon representing the project or vendor that is supplying the actions in the XML document. The icon name must adhere to the Freedesktop.org Icon Naming Specification[6]. Optional.

action

Declares an action. The action name is specified using the id attribute and can only contain the characters "[A-Z][a-z][0-9].- ", e.g. ASCII, digits, period and hyphen.

Elements that can be used inside action include:

description

A human readable description of the action, e.g. “Install unsigned software”.

message

A human readable message displayed to the user when asking for credentials when authentication is needed, e.g. “Installing unsigned software requires authentication”.

defaults

This element is used to specify implicit authorizations for clients. Elements that can be used inside defaults include: allow_any

Implicit authorizations that apply to any client. Optional.

allow_inactive

Implicit authorizations that apply to clients in inactive sessions on local consoles. Optional.

allow_active

Implicit authorizations that apply to clients in active sessions on local consoles. Optional.

Each of the allow_any, allow_inactive and allow_active elements can contain the following values:

no

Not authorized.

yes

Authorized.

auth_self

Authentication by the owner of the session that the client originates from is required. Note that this is not restrictive enough for most uses on multi-user systems; auth_admin* is generally recommended.

auth_admin

Authentication by an administrative user is required.

auth_self_keep

Like auth_self but the authorization is kept for a brief period (e.g. five minutes). The warning about auth_self above applies likewise.

auth_admin_keep

Like auth_admin but the authorization is kept for a brief period (e.g. five minutes).

annotate

Used for annotating an action with a key/value pair. The key is specified using the key attribute and the value is specified using the value attribute. This element may appear zero or more times. See below for known annotations.

vendor

Used for overriding the vendor on a per-action basis. Optional.

vendor_url

Used for overriding the vendor URL on a per-action basis. Optional.

icon_name

Used for overriding the icon name on a per-action basis. Optional.

For localization, description and message elements may occur multiple times with different xml:lang attributes.

To list installed polkit actions, use the pkaction(1) command.

### Known annotations
The org.freedesktop.policykit.exec.path annotation is used by the pkexec program shipped with polkit - see the pkexec(1) man page for details.

The org.freedesktop.policykit.imply annotation (its value is a string containing a space-separated list of action identifiers) can be used to define meta actions. The way it works is that if a subject is authorized for an action with this annotation, then it is also authorized for any action specified by the annotation. A typical use of this annotation is when defining an UI shell with a single lock button that should unlock multiple actions from distinct mechanisms.

The org.freedesktop.policykit.owner annotation can be used to define a set of users who can query whether a client is authorized to perform this action. If this annotation is not specified, then only root can query whether a client running as a different user is authorized for an action. The value of this annotation is a string containing a space-separated list of PolkitIdentity entries, for example "unix-user:42 unix-user:colord". A typical use of this annotation is for a daemon process that runs as a system user rather than root.

## AUTHORIZATION RULES
polkitd reads .rules files from the following directories in this order:

•/etc/polkit-1/rules.d

•/run/polkit-1/rules.d

•/usr/local/share/polkit-1/rules.d

•/usr/share/polkit-1/rules.d

These directories are processed in lexical order based on the basename of each file. If there's a tie, files in directories earlier in the list are processed first. For example, for the following four files, the order is:

•/etc/polkit-1/rules.d/10-auth.rules

•/run/polkit-1/rules.d/10-auth.rules

•/usr/local/share/polkit-1/rules.d/10-auth.rules

•/usr/share/polkit-1/rules.d/10-auth.rules

All of these directories are monitored, so if a rules file is changed, added, or removed, existing rules are purged and all files are read and processed again. Rules files are written in the JavaScript[7] programming language and interface with polkitd through the global polkit object (of type Polkit).

While the JavaScript interpreter used in particular versions of polkit may support non-standard features (such as the let keyword), authorization rules must conform to ECMA-262 edition 5[8] (in other words, the JavaScript interpreter used may change in future versions of polkit).

Authorization rules are intended for two specific audiences

•System Administrators

•Special-purpose Operating Systems / Environments

and those audiences only. In particular, applications, mechanisms and general-purpose operating systems must never include any authorization rules.

### The Polkit type
The following methods are available on the polkit object:

void addRule(polkit.Result function(action, subject) {...});

void addAdminRule(string[] function(action, subject) {...});

void log(string message);

string spawn(string[] argv);

The addRule() method is used for adding a function that may be called whenever an authorization check for action and subject is performed. Functions are called in the order they have been added until one of the functions returns a value. Hence, to add an authorization rule that is processed before other rules, put it in a file in /etc/polkit-1/rules.d with a name that sorts before other rules files, for example 00-early-checks.rules. Each function should return a value from polkit.Result

```
polkit.Result = {

    NO              : "no",

    YES             : "yes",

    AUTH_SELF       : "auth_self",

    AUTH_SELF_KEEP  : "auth_self_keep",

    AUTH_ADMIN      : "auth_admin",

    AUTH_ADMIN_KEEP : "auth_admin_keep",

    NOT_HANDLED     : null
};
```

corresponding to the values that can be used as defaults. If the function returns polkit.Result.NOT_HANDLED, null, undefined or does not return a value at all, the next user function is tried.

Keep in mind that if polkit.Result.AUTH_SELF_KEEP or polkit.Result.AUTH_ADMIN_KEEP is returned, authorization checks for the same action identifier and subject will succeed (that is, return polkit.Result.YES) for the next brief period (e.g. five minutes) even if the variables passed along with the check are different. Therefore, if the result of an authorization rule depend on such variables, it should not use the "*_KEEP" constants (if similar functionality is required, the authorization rule can easily implement temporary authorizations using the Date[9] type for timestamps).

The addAdminRule() method is used for adding a function that may be called whenever administrator authentication is required. The function is used to specify what identities may be used for administrator authentication for the authorization check identified by action and subject. Functions added are called in the order they have been added until one of the functions returns a value. Each function should return an array of strings where each string is of the form "unix-group:<group>", "unix-netgroup:<netgroup>" or "unix-user:<user>". If the function returns null, undefined or does not return a value at all, the next function is tried.

There is no guarantee that a function registered with addRule() or addAdminRule() is ever called - for example an early rules file could register a function that always returns a value, hence ensuring that functions added later are never called.

If user-provided code takes a long time to execute, no exception will be thrown and the script will be killed right away (the current limit is 15 seconds). This is used to catch runaway scripts.

The spawn() method spawns an external helper identified by the argument vector argv and waits for it to terminate. If an error occurs or the helper doesn't exit normally with exit code 0, an exception is thrown. If the helper does not exit within 10 seconds, it is killed. Otherwise, the program's standard output is returned as a string. The spawn() method should be used sparingly as helpers may take a very long or indeterminate amount of time to complete and no other authorization check can be handled while the helper is running. Note that the spawned programs will run as the unprivileged polkitd system user.

The log() method writes the given message to the system logger prefixed with the JavaScript filename and line number. Log entries are emitted using the LOG_AUTHPRIV flag meaning that the log entries usually ends up in the file /var/log/secure. The log() method is usually only used when debugging rules. The Action and Subject types has suitable toString() methods defined for easy logging, for example,

```
polkit.addRule(function(action, subject) {

    if (action.id == "org.freedesktop.policykit.exec") {

        polkit.log("action=" + action);

        polkit.log("subject=" + subject);

    }
});
```

will produce the following when the user runs 'pkexec -u bateman bash -i' from a shell:

```
May 24 14:28:50 thinkpad polkitd[32217]: /etc/polkit-1/rules.d/10-test.rules:3: action=[Action id='org.freedesktop.policykit.exec' command_line='/usr/bin/bash -i' program='/usr/bin/bash' user='bateman' user.gecos='Patrick Bateman' user.display='Patrick Bateman (bateman)']
May 24 14:28:50 thinkpad polkitd[32217]: /etc/polkit-1/rules.d/10-test.rules:4: subject=[Subject pid=1352 user='davidz' groups=davidz,wheel, seat='seat0' session='1' local=true active=true]
```

### The Action type
The action parameter passed to user functions is an object with information about the action being checked. It is of type Action and has the following attribute:

string id

The action identifier, for example org.freedesktop.policykit.exec.

The following methods are available on the Action type:

string lookup(string key);

The lookup() method is used to lookup the polkit variables passed from the mechanism. For example, the pkexec(1) mechanism sets the variable program which can be obtained in JavaScript using the expression action.lookup("program"). If there is no value for the given key, then undefined is returned.

Consult the documentation for each mechanism for what variables are available for each action.

### The Subject type
The subject parameter passed to user functions is an object with information about the process being checked. It is of type Subject and has the following attributes

int pid

The process id.

string user

The user name.

string[] groups

Array of groups that user user belongs to.

string seat

The seat that the subject is associated with - blank if not on a local seat.

string session

The session that the subject is associated with.

string system_unit

The systemd unit that the subject's process is part of (if any). Note that this can only match on system units, as user units can be created with any name without privileges (unlike system units which require root to create). A process running in a user unit will return the user session unit in this attribute (e.g.: user-1000.service).

boolean local

Set to true only if seat is local.

boolean no_new_privileges

Set only if system_unit is not empty, and set to true only if the referenced systemd service unit has the NoNewPrivileges= setting enabled. This ensures that the process cannot gain any new privileges via executing setuid binaries.

boolean active

Set to true only if the session is active.

The following methods are available on the Subject type:

boolean isInGroup(string groupName);

boolean isInNetGroup(string netGroupName);

The isInGroup() method can be used to check if the subject is in a given group and isInNetGroup() can be used to check if the subject is in a given netgroup.

### Authorization Rules Examples
Allow all users in the admin group to perform user administration without changing policy for other users:

```
polkit.addRule(function(action, subject) {

    if (action.id == "org.freedesktop.accounts.user-administration" &&

        subject.isInGroup("admin")) {

        return polkit.Result.YES;

    }
});
```

Define administrative users to be the users in the wheel group:

```
polkit.addAdminRule(function(action, subject) {

    return ["unix-group:wheel"];
});
```

Forbid users in group children to change hostname configuration (that is, any action with an identifier starting with org.freedesktop.hostname1.) and allow anyone else to do it after authenticating as themselves:

```
polkit.addRule(function(action, subject) {

    if (action.id.indexOf("org.freedesktop.hostname1.") == 0) {

        if (subject.isInGroup("children")) {

            return polkit.Result.NO;

        } else {

            return polkit.Result.AUTH_SELF_KEEP;

        }

    }
});
```

Run an external helper to determine if the current user may reboot the system:

```
polkit.addRule(function(action, subject) {

    if (action.id.indexOf("org.freedesktop.login1.reboot") == 0) {

        try {

            // user-may-reboot exits with success (exit code 0)

            // only if the passed username is authorized

            polkit.spawn(["/opt/company/bin/user-may-reboot",

                          subject.user]);

            return polkit.Result.YES;

        } catch (error) {

            // Nope, but do allow admin authentication

            return polkit.Result.AUTH_ADMIN;

        }

    }
});
```

The following example shows how the authorization decision can depend on variables passed by the pkexec(1) mechanism:

```
polkit.addRule(function(action, subject) {

    if (action.id == "org.freedesktop.policykit.exec" &&

        action.lookup("program") == "/usr/bin/cat") {

        return polkit.Result.AUTH_ADMIN;

    }
});
```

The following example shows another use of variables passed from the mechanism. In this case, the mechanism is UDisks[10] which defines a set of actions and variables[11] that is used to match on:

```
// Allow users in group 'engineers' to perform any operation on
// some drives without having to authenticate
//
polkit.addRule(function(action, subject) {

    if (action.id.indexOf("org.freedesktop.udisks2.") == 0 &&

        action.lookup("drive.vendor") == "SEAGATE" &&

        action.lookup("drive.model") == "ST3300657SS" &&

        subject.isInGroup("engineers")) {

            return polkit.Result.YES;

        }

    }
});
```

Allow all processes running as part of the admin.service systemd system unit to perform user administration, as long as they cannot gain new privileges:

```
polkit.addRule(function(action, subject) {

    if (action.id == "org.freedesktop.accounts.user-administration" &&

        subject.system_unit == "admin.service" &&

        subject.no_new_privileges) {

        return polkit.Result.YES;

    }
});
```

## AUTHOR
Written by David Zeuthen <davidz@redhat.com> with a lot of help from many others.

## BUGS
Please send bug reports to either the distribution or the polkit-devel mailing list, see the link https://gitlab.freedesktop.org/polkit/polkit/-/issues/ on how to subscribe.

## SEE ALSO
polkitd(8), pkaction(1), pkcheck(1), pkexec(1), pkttyagent(1)

## NOTES
1.

/usr/share/gtk-doc/html/polkit-1/polkit-architecture.png

2.

GObjectIntrospection

https://live.gnome.org/GObjectIntrospection

3.

developer documentation

http://www.freedesktop.org/software/polkit/docs/latest/

4.

/usr/share/gtk-doc/html/polkit-1/polkit-authentication-agent-example.png

5.

/usr/share/gtk-doc/html/polkit-1/polkit-authentication-agent-example-wheel.png

6.

Freedesktop.org Icon Naming Specification

http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html

7.

JavaScript

http://en.wikipedia.org/wiki/JavaScript

8.

ECMA-262 edition 5

http://en.wikipedia.org/wiki/ECMAScript#ECMAScript.2C_5th_Edition

9.

Date

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date

10.

UDisks

http://udisks.freedesktop.org/docs/latest/udisks.8.html

11.

actions and variables

http://udisks.freedesktop.org/docs/latest/udisks-polkit-actions.html


polkitd

title: polkitd(8)

summary: The polkit system daemon

text:
# polkitd(8)

## NAME
polkitd - The polkit system daemon

## SYNOPSIS
polkitd

## DESCRIPTION
polkitd provides the org.freedesktop.PolicyKit1 D-Bus service on the system message bus. Users or administrators should never need to start this daemon as it will be automatically started by dbus-daemon(1) or systemd(1) whenever an application calls into the service.

polkitd must be started with superuser privileges but drops privileges early by switching to the unprivileged polkitd system user.

See the polkit(8) man page for more information.

## AUTHOR
Written by David Zeuthen <davidz@redhat.com> with a lot of help from many others.

## BUGS
Please send bug reports to either the distribution or the polkit-devel mailing list, see the link https://gitlab.freedesktop.org/polkit/polkit/-/issues/ on how to subscribe.

## SEE ALSO
polkit(8), pkaction(1), pkcheck(1), pkexec(1), pkttyagent(1), dbus-daemon(1), systemd(1)


pkla-admin-identities

package: polkit-pkla-compat

title: pkla-admin-identities(8)

summary: List pklocalauthority\-configured polkit administrators

text:
# pkla-admin-identities(8)

## NAME
pkla-admin-identities - List pklocalauthority-configured polkit administrators

## SYNOPSIS
pkla-admin-identities [--help]

pkla-admin-identities [--config-path config-path]

## DESCRIPTION
pkla-admin-identities interprets configuration files described below to determine which users polkit(8) considers administrators, using a non-JavaScript configuration file format described below.

Note: Determining which users are considered administrators is driven by JavaScript rules as described in polkit(8). pkla-admin-identities is called by a JavaScript rule file named 49-polkit-pkla-compat.rules; other JavaScript rules with a higher priority may exist, so the pkla-admin-identities configuration may not necessarily govern the final decision by polkit(8).

The ordering of the JavaScript rule files and the ordering of pkla-admin-identities configuration files is not integrated and uses different rules; the pkla-admin-identities configuration evaluation is happens at a single point within the JavaScript rule evaluation order.

pkla-admin-identities is an internal helper program of pkla-polkit-compat. You shouldn't need to run it directly, except for debugging purposes.

Configuration is read from files with a .conf extension in the /etc/polkit-1/localauthority.conf.d directory. All files are read in lexicographical order (using the C locale), meaning that later files can override earlier ones. The file 50-localauthority.conf contains the settings provided by the OS vendor. Users and 3rd party packages can drop configuration files with a priority higher than 60 to change the defaults. The configuration file format is simple. Each configuration file is a key file (also commonly known as a ini file) with a single group called [Configuration]. Only a single key, AdminIdentities is read. The value of this key is a semi-colon separated list of identities that can be used when administrator authentication is required. Users are specified by prefixing the user name with unix-user:, groups of users are specified by prefixing with unix-group:, and netgroups of users are specified with unix-netgroup:. See the section called “EXAMPLE” for an example of a configuration file.

pkla-admin-identities outputs the resulting configuration of administrator identities, one identity per line, using the same format (including e.g. the unix-user: prefix). If no administrator identities are configured in the above-described configuration files, the output will be empty.

## OPTIONS
-h, --help

Write a summary of the available options to standard output and exit successfully.

-c, --config-path=config-path

Search for configuration files in config-path instead of the default /etc/polkit-1/localauthority.conf.d.

## EXIT STATUS
pkla-admin-identities exits with 0 on success (even if there are no administrator identities), and a non-zero status on error.

## FILES
/etc/polkit-1/localauthority.conf.d

Default directory containing configuration files.

## EXAMPLE
The following .conf file

```
[Configuration]
AdminIdentities=unix-group:staff

```

specifies that any user in the staff UNIX group can be used for authentication when administrator authentication is needed. This file would typically be installed in the /etc/polkit-1/localauthority.conf.d directory and given the name 60-desktop-policy.conf to ensure that it is evaluated after the 50-localauthority.conf file shipped with pkla-polkit-compat. If the local administrator wants to override this (suppose 60-desktop-policy.conf was shipped as part of the OS) he can simply create a file 99-my-admin-configuration.conf with the following content

```
[Configuration]
AdminIdentities=unix-user:lisa;unix-user:marge

```

to specify that only the users lisa and marge can authenticate when administrator authentication is needed.

## AUTHOR
Written by David Zeuthen <davidz@redhat.com> with a lot of help from many others. Adapted by Miloslav Trmač <mitr@redhat.com>.

## SEE ALSO
polkit(8)


pkla-check-authorization

title: pkla-check-authorization(8)

text:
# pkla-check-authorization(8)

## NAME
pkla-check-authorization - Evaluate pklocalauthority authorization configuration

## SYNOPSIS
pkla-check-authorization [--help]

pkla-check-authorization [--paths paths] {user-name} {is-local} {is-active} {action}

## DESCRIPTION
pkla-check-authorization interprets non-JavaScript configuration files described below to determine the response of polkit(8) to authorization queries.

Note: Authorization decision evaluation is driven by JavaScript rules as described in polkit(8). pkla-check-authorization is called by a JavaScript rule file named 49-polkit-pkla-compat.rules; other JavaScript rules with a higher priority may exist, so the pkla-check-authorization configuration may not necessarily govern the final polkit(8) authorization decision.

The ordering of the JavaScript rule files and the ordering of pkla-check-authorization configuration files is not integrated and uses different rules; the pkla-check-authorization configuration evaluation is happens at a single point within the JavaScript rule evaluation order.

pkla-check-authorization is an internal helper program of pkla-polkit-compat. You shouldn't need to run it directly, except for debugging purposes.

The arguments to pkla-check-authorization are, in order:

user-name

Name of the user account asking for authorization

is-local

Whether the attempted action is performed from a local login session, true or false.

is-active

Whether the attempted action is performed from a currently active session (e.g. currently active virtual console), true or false.

action

A string identifying the polkit(8) action.

If the configuration specifies an authorization decision, pkla-check-authorization outputs the decision and a terminating newline. If no decision is configured, the output is empty.

## OPTIONS
-h, --help

Write a summary of the available options to standard output and exit successfully.

-p, --paths=paths

Search for configuration files in semicolon-separated paths instead of the default /var/lib/polkit-1/localauthority;/etc/polkit-1/localauthority.

## EXIT STATUS
pkla-check-authorization exits with 0 on success (even if there is no decision configured), and a non-zero status on error.

## DIRECTORY STRUCTURE
Files with .pkla extension are read from all directories located inside the /etc/polkit-1/localauthority and /var/lib/polkit-1/localauthority directories (or as specified using the --paths option). By default, the following sub-directories are installed.

```
/etc/polkit-1/
`-- localauthority

    |-- 10-vendor.d

    |-- 20-org.d

    |-- 30-site.d

    |-- 50-local.d

    `-- 90-mandatory.d

```

and

```
/var/lib/polkit-1/
`-- localauthority

    |-- 10-vendor.d

    |-- 20-org.d

    |-- 30-site.d

    |-- 50-local.d

    `-- 90-mandatory.d

```

The /etc/polkit-1/localauthority hierarchy is intended for local configuration and the /var/lib/polkit-1/localauthority is intended for 3rd party packages.

Each .pkla file contains one or more authorization entries. If the underlying filesystem supports file monitoring, the Local Authority will reload information whenever .pkla files are added, removed or changed.

Each directory is intended for a specific audience

10-vendor.d

Intended for use by the OS vendor.

20-org.d

Intended for the organization deploying the OS.

30-site.d

Intended for the site deploying the system.

50-local.d

Intended for local usage.

90-mandatory.d

Intended for the organization deploying the OS.

and new directories can be added/removed as needed.

As to regards to the content, each .pkla file is a standard key file and contains key/value pairs in one or more groups with each group representing an authorization entry. A .pkla file MUST be named by using a scheme to ensure that the name is unique, e.g. reverse DNS notation or similar. For example, if the organization is “Acme Corp” needs to modify policy for the product “Frobnicator”, a name like com.acme.frobnicator.pkla would be suitable.

## AUTHORIZATION ENTRY
Each group in a .pkla file must have a name that is unique within the file it belongs to. The following keys are recognized:

Identity

A semi-colon separated list of entries to match identities. Each entry should start with unix-user: or unix-group: to specify whether to match on a UNIX user name or a UNIX group name, and continue with a glob matching the group or user name. Netgroups are supported with the unix-netgroup: prefix, but cannot support glob syntax. Finally, an entry "default" (with no prefix) can be used to specify the default match.

Action

A semi-colon separated list of globs to match action identifiers.

ResultActive

The result to return for subjects in an active local session that matches one or more of the given identities. Allowed values are similar to what can be used in the defaults section of .policy files used to define actions, e.g. yes, no, auth_self, auth_self_keep, auth_admin and auth_admin_keep.

ResultInactive

Like ResultActive but instead applies to subjects in inactive local sessions.

ResultAny

Like ResultActive but instead applies to any subject.

All keys specified above are required except that only at least one of ResultAny, ResultInactive and ResultActive must be present.

## EVALUATION ORDER
The authorization entries discussed above are consulted using the following algorithm.

The authorization entries from all .pkla files are ordered using the following rules. First all the basename of all sub-directories (e.g. 30-site.d) from both the /etc/polkit-1/localauthority and /var/lib/polkit-1/localauthority directories are enumerated and sorted (using the C locale). If a name exists in both /etc and /var, the one in /etc takes precedence. Then all .pkla files are read in order from this list of sub-directories. For each .pkla file, authorizations from each file are appended in order resulting in an ordered list of authorization entries.

For example, given the following files

```
/var/lib/polkit-1
└── localauthority

    ├── 10-vendor.d

    │   └── 10-desktop-policy.pkla

    ├── 20-org.d

    ├── 30-site.d

    ├── 50-local.d

    ├── 55-org.my.company.d

    │   └── 10-org.my.company.product.pkla

    └── 90-mandatory.d
/etc/polkit-1
└── localauthority

    ├── 10-vendor.d

    │   └── 01-some-changes-from-a-subvendor.pkla

    ├── 20-org.d

    ├── 30-site.d

    ├── 50-local.d

    ├── 55-org.my.company.d

    │   └── 10-org.my.company.product.pkla

    └── 90-mandatory.d

```

the evaluation order of the .pkla files is:

1. 10-desktop-policy.pkla

2. 01-some-changes-from-a-subvendor.pkla

3. 10-org.my.company.product.pkla (the /var one)

4. 10-org.my.company.product.pkla (the /etc one)

When the list of authorization entries has been calculated, the authorization check can be made. First, the user of the Subject is determined and the groups that the user belongs are looked up.

Then, authorization entries that include the "default" field value in the Identity field are consulted in order. If the authorization entry matches the data from the authorization check, then the authorization result from RequireAny, RequireInactive or RequireActive is used.

Next, for each group identity, all authorization entries that contain a matching group entry are again consulted in the same manner.

Finally, the authorization entries are consulted using the user identity in the same manner.

Note that processing continues even after a match. This allows for so called “negative authorizations”, see the section called “EXAMPLE” for further discussion.

## EXAMPLE
The following .pkla file grants authorization to all users in the staff group for actions matching the glob com.example.awesomeproduct.* provided they are in an active session on the local console:

```
[Normal Staff Permissions]
Identity=unix-group:staff
Action=com.example.awesomeproduct.*
ResultAny=no
ResultInactive=no
ResultActive=yes

```

If the users homer and grimes are member of the staff group but policy requires that an administrator needs to authenticate every time authorization for any action matching com.example.awesomeproduct.* is required, one would add

```
[Exclude Some Problematic Users]
Identity=unix-user:homer;unix-user:grimes
Action=com.example.awesomeproduct.*
ResultAny=no
ResultInactive=no
ResultActive=auth_admin

```

and make sure this authorization entry is after the first one.

The following entry modifies the default authorization decision (it is overridden by any entry that matches using unix-user: or unix-group:, but overrides any defaults set by the application author in an .action file):

```
[Disable Access by Default]
Identity=default
Action=com.example.awesomeproduct.*
ResultAny=no
ResultInactive=no
ResultActive=no

```

## FILES
/etc/polkit-1/localauthority, /var/lib/polkit-1/localauthority

Default directories containing decision configuration files.

## AUTHOR
Written by David Zeuthen <davidz@redhat.com> with a lot of help from many others. Adapted by Miloslav Trmač <mitr@redhat.com>.

## SEE ALSO
polkit(8)


pklocalauthority

title: pklocalauthority(8)

summary: polkit Local Authority Compatibility

text:
# pklocalauthority(8)

## NAME
pklocalauthority - polkit Local Authority Compatibility

## DESCRIPTION
The polkit Local Authority no longer exists. Existing configuration files are honored; see pkla-admin-identities(8) and pkla-check-authorization(8) for description of the configuration format.

Unlike the original Local Authority implementation, ReturnValue keys are ignored because polkit(8) no longer supports the functionality.

## SEE ALSO
pkla-admin-identities(8), pkla-check-authorization(8), polkit(8)

## AUTHOR
Miloslav Trmač <mitr@redhat.com>

Author


title: popa3d(8)

summary: Post Office Protocol (POP3) server

text:
# popa3d(8)

## NAME
popa3d - Post Office Protocol (POP3) server

## SYNOPSIS
popa3d [-D] [-V]

## DESCRIPTION
popa3d is a Post Office Protocol version 3 (POP3) server.

A POP3 server operates on local mailboxes on behalf of its remote users. Users can connect at any time to check their mailbox and fetch the mail that has accumulated. The advantage of this "pull" approach is that any user with a simple POP3-capable mail reader program can receive mail, eschewing the need for a full-fledged Mail Transfer Agent (MTA) and a permanent network connection.

Note that POP3 can only be used to retrieve mail, not to send it. To send mail, the SMTP protocol is commonly used.

For access to a mailbox through POP3, the username must be in the password database. Additionally, popa3d does not permit null passwords and will refuse to serve mail for root (UID 0) users.

## OPTIONS
-D

Standalone server mode. In this mode, popa3d will become a daemon, accepting connections on the pop3 port (110/tcp) and forking child processes to handle them. This has lower overhead than starting popa3d from an inetd equivalent (which popa3d assumes by default) and is thus useful on busy servers to reduce load. In this mode popa3d also does quite a few checks to significantly reduce the impact of connection flood attacks.

-V

Print version information and exit.

## COMMANDS
A normal POP3 session progresses through three states: AUTHORIZATION, TRANSACTION, and UPDATE.

After the TCP connection opens, the client must authenticate itself to the server during the AUTHORIZATION state. The following commands are supported in the AUTHORIZATION state (all command names are case-insensitive).

USER name

Authenticate as user name.

PASS string

Authenticate using password string.

QUIT

Quit; do not enter UPDATE state.

When authorization is successful, the server enters the TRANSACTION state. The client can now list and retrieve messages or mark messages for deletion. The following commands are supported in the TRANSACTION state.

DELE msg

Mark message for deletion.

LAST

Show highest message number accessed (obsolete).

LIST [msg]

List message number and size.

NOOP

Do nothing.

QUIT

Quit; enter UPDATE state.

RETR msg

Retrieve message.

RSET

Clear deletion marks.

STAT

Return total number of messages and total size.

TOP msg n

Show top n lines of message body.

UIDL [msg]

List message number and digest.

When the client issues the QUIT command in the TRANSACTION state, the server enters the UPDATE state. All messages that were marked for deletion are now removed. The server then closes the connection.

## BUGS
POP3 transmits passwords in plaintext and thus, if you care about the security of your individual user accounts, should only be used either in trusted networks or tunneled over encrypted channels.

There exist extensions to the protocol that are supposed to fix this problem. popa3d does not support them yet, partly because this isn't going to fully fix the problem. In fact, APOP and the weaker defined SASL mechanisms such as CRAM-MD5 may potentially be even less secure than transmission of plaintext passwords because of the requirement that plaintext equivalents be stored on the server.

## AUTHORS
Solar Designer <solar at openwall.com>

This manual page is based heavily on the one Camiel Dobbelaar wrote for OpenBSD.

## SEE ALSO
Official Internet Protocol Standard STD 53, also known as RFC 1939.

http://www.openwall.com/popa3d/