https://wiki.archlinux.org/api.php?action=feedcontributions&user=Hunterthomson&feedformat=atomArchWiki - User contributions [en]2024-03-28T21:55:48ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Sudo&diff=322371Sudo2014-06-30T04:26:28Z<p>Hunterthomson: /* Harden with Sudo Example */ add Defaults targetpw and attempt to correct indent... fail</p>
<hr />
<div>[[Category:Security]]<br />
[[cs:Sudo]]<br />
[[es:Sudo]]<br />
[[fr:Sudo]]<br />
[[it:Sudo]]<br />
[[ja:Sudo]]<br />
[[ru:Sudo]]<br />
[[sr:Sudo]]<br />
[[tr:Sudo]]<br />
[[uk:Sudo]]<br />
[[zh-CN:Sudo]]<br />
{{Related articles start}}<br />
{{Related|Users and groups}}<br />
{{Related|su}}<br />
{{Related articles end}}<br />
<br />
[http://www.gratisoft.us/sudo/ sudo] ("substitute user do") allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments.<br />
<br />
== Rationale ==<br />
<br />
Sudo is an alternative to [[su]] for running commands as root. Unlike [[su]], which launches a root shell that allows all further commands root access, sudo instead grants temporary privilege escalation to a single command. By enabling root privileges only when needed, sudo usage reduces the likelihood that a typo or a bug in an invoked command will ruin the system.<br />
<br />
Sudo can also be used to run commands as other users; additionally, sudo logs all commands and failed access attempts for security auditing.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|sudo}} package, available in the [[official repositories]].<br />
<br />
To begin using {{ic|sudo}} as a non-privileged user, it must be properly configured. So make sure you read the configuration section.<br />
<br />
== Usage ==<br />
<br />
With sudo, users can prefix commands with {{ic|sudo}} to run them with superuser (or other) privileges.<br />
<br />
For example, to use pacman:<br />
<br />
$ sudo pacman -Syu<br />
<br />
See the [http://www.gratisoft.us/sudo/man/sudo.html sudo manual] for more information.<br />
<br />
== Configuration ==<br />
<br />
=== View current settings ===<br />
<br />
Run {{ic|sudo -ll}} to print out the current sudo configuration.<br />
<br />
=== Using visudo ===<br />
<br />
The configuration file for sudo is {{ic|/etc/sudoers}}. It should '''always''' be edited with the {{ic|visudo}} command. {{ic|visudo}} locks the {{ic|sudoers}} file, saves edits to a temporary file, and checks that file's grammar before copying it to {{ic|/etc/sudoers}}.<br />
<br />
{{Warning|It is imperative that {{ic|sudoers}} be free of syntax errors! Any error makes sudo unusable. '''Always''' edit it with {{ic|visudo}} to prevent errors.}}<br />
<br />
The default editor for visudo is {{ic|vi}}. It will be used if you do not specify another editor, by setting either {{ic|VISUAL}} or {{ic|EDITOR}} [[environment variables]] (used in that order) to the desired editor, e.g. {{ic|nano}}. The command is run as root:<br />
<br />
# EDITOR=nano visudo<br />
<br />
To change the editor permanently, see [[Environment variables#Defining variables locally]]. To change the editor of choice permanently system-wide only for {{ic|visudo}}, add the following to {{ic|/etc/sudoers}} (assuming {{ic|nano}} is your preferred editor):<br />
<br />
# Reset environment by default<br />
Defaults env_reset<br />
# Set default EDITOR to nano, and do not allow visudo to use EDITOR/VISUAL.<br />
Defaults editor=/usr/bin/nano, !env_editor<br />
<br />
=== Example Entries ===<br />
<br />
To allow a user to gain full root privileges when he/she precedes a command with {{ic|sudo}}, add the following line:<br />
<br />
USER_NAME ALL=(ALL) ALL<br />
<br />
To allow a user to run all commands as any user but only the machine with hostname HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=(ALL) ALL<br />
<br />
To allow members of group {{ic|wheel}} sudo access:<br />
<br />
%wheel ALL=(ALL) ALL<br />
<br />
To disable asking for a password for user USER_NAME:<br />
<br />
Defaults:USER_NAME !authenticate<br />
<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=/usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
{{note| the most customized option should go at the end of the file, as the later lines overrides the previous ones. In particular such a line should be after the {{ic|%wheel}} line if your user is in this group.}}<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME without password:<br />
USER_NAME HOST_NAME= NOPASSWD: /usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
<br />
A detailed sudoers example can be found [http://www.gratisoft.us/sudo/sample.sudoers here]. Otherwise, see the [http://www.gratisoft.us/sudo/man/sudoers.html sudoers manual] for detailed information.<br />
<br />
=== Sudoers default file permissions ===<br />
<br />
The owner and group for the sudoers file must both be 0. The file permissions must be set to 0440. These permissions are set by default, but if you accidentally change them, they should be changed back immediately or sudo will fail.<br />
<br />
# chown -c root:root /etc/sudoers<br />
# chmod -c 0440 /etc/sudoers<br />
<br />
=== Password cache timeout ===<br />
<br />
Users may wish to change the default timeout before the cached password expires. This is accomplished with the timestamp_timeout option in {{ic|/etc/sudoers}} which is in minutes.<br />
Set timeout to 20 minutes.<br />
<br />
Defaults:USER_NAME timestamp_timeout=20<br />
<br />
{{Tip|To ensure sudo always asks for a password, set the timeout to 0. To ensure the password never times out, set to less than 0.}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== File example ===<br />
<br />
This example is especially helpful for those using terminal multiplexers like screen, tmux, or ratpoison, and those using sudo from scripts/cronjobs:<br />
<br />
{{hc|/etc/sudoers|<nowiki><br />
Cmnd_Alias WHEELER = /usr/bin/lsof, /bin/nice, /bin/ps, /usr/bin/top, /usr/local/bin/nano, /usr/bin/ss, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync<br />
Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/kill, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
Cmnd_Alias EDITS = /usr/bin/vim, /usr/bin/nano, /usr/bin/cat, /usr/bin/vi<br />
Cmnd_Alias ARCHLINUX = /usr/bin/gparted, /usr/bin/pacman<br />
<br />
root ALL = (ALL) ALL<br />
USER_NAME ALL = (ALL) ALL, NOPASSWD: WHEELER, NOPASSWD: PROCESSES, NOPASSWD: ARCHLINUX, NOPASSWD: EDITS<br />
<br />
Defaults !requiretty, !tty_tickets, !umask<br />
Defaults visiblepw, path_info, insults, lecture=always<br />
Defaults loglinelen = 0, logfile =/var/log/sudo.log, log_year, log_host, syslog=auth<br />
Defaults mailto=webmaster@foobar.com, mail_badpass, mail_no_user, mail_no_perms<br />
Defaults passwd_tries = 8, passwd_timeout = 1<br />
Defaults env_reset, always_set_home, set_home, set_logname<br />
Defaults !env_editor, editor="/usr/bin/vim:/usr/bin/vi:/usr/bin/nano"<br />
Defaults timestamp_timeout=360<br />
Defaults passprompt="Sudo invoked by [%u] on [%H] - Cmd run as %U - Password for user %p:"<br />
</nowiki>}}<br />
<br />
=== Enabling Tab-completion in Bash ===<br />
<br />
See [[Bash#Tab completion]] for details.<br />
<br />
=== Run X11 apps using sudo ===<br />
<br />
To allow sudo to start graphical application in X11:<br />
<br />
{{hc|/etc/sudoers|2=<br />
Defaults env_keep += "HOME"<br />
}}<br />
<br />
=== Disable per-terminal sudo ===<br />
<br />
{{Warning|This will let any process use your sudo session.}}<br />
<br />
If you are annoyed by sudo's defaults that require you to enter your password every time you open a new terminal, disable '''tty_tickets''':<br />
<br />
Defaults !tty_tickets<br />
<br />
=== Always show security note ===<br />
<br />
By default, {{ic|/etc/sudoers}} is set so that ''sudo'' issues a security warning only the first time a user runs it: <br />
<br />
We trust you have received the usual lecture from the local System<br />
Administrator. It usually boils down to these three things:<br />
<br />
#1) Respect the privacy of others.<br />
#2) Think before you type.<br />
#3) With great power comes great responsibility.<br />
<br />
To have this message shown every time, edit {{ic|/etc/sudoers}} and change:<br />
<br />
Defaults lecture=once<br />
<br />
to:<br />
<br />
Defaults lecture=always<br />
<br />
or just add it if not already present.<br />
<br />
=== Environment variables ===<br />
<br />
If you have a lot of environment variables, or you export your proxy settings via {{ic|1=export http_proxy="..."}}, when using sudo these variables do not get passed to the root account unless you run sudo with the {{ic|-E}} option.<br />
<br />
$ sudo -E pacman -Syu<br />
<br />
The recommended way of preserving environment variables is to append them to {{ic|env_keep}}:<br />
{{hc|/etc/sudoers|<nowiki><br />
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"<br />
</nowiki>}}<br />
<br />
=== Passing aliases ===<br />
<br />
If you use a lot of aliases, you might have noticed that they do not carry over to the root account when using sudo. However, there is an easy way to make them work. Simply add the following to your {{ic|~/.bashrc}} or {{ic|/etc/bash.bashrc}}:<br />
<br />
alias sudo='sudo '<br />
<br />
=== Insults ===<br />
<br />
Users can configure sudo to display clever insults when an incorrect password is entered instead of printing the default "wrong password" message. Find the Defaults line in {{ic|/etc/sudoers}} and append "insults" after a comma to existing options. The final result might look like this:<br />
<br />
#Defaults specification<br />
Defaults insults<br />
<br />
To test, type {{ic|sudo -K}} to end the current session and let sudo ask for the password again.<br />
<br />
=== Root password ===<br />
<br />
{{Accuracy|Locking the root account does not necessarily "secure" a server. Remote logins as root can and should be disabled instead (see [[Ssh#Deny]]).}}<br />
{{Warning|This is not intended usage of sudo. You are removing the capability of securing your server by removing the password from root.}}<br />
<br />
Users can configure sudo to ask for the root password instead of the user password by adding {{ic|targetpw}} (target user, defaults to root) or {{ic|rootpw}} to the Defaults line in {{ic|/etc/sudoers}}:<br />
Defaults targetpw<br />
<br />
To prevent exposing your root password to users, you can restrict this to a specific group:<br />
Defaults:%wheel targetpw<br />
%wheel ALL=(ALL) ALL<br />
<br />
=== Disable root login ===<br />
<br />
Users may wish to disable the root login. Without root, attackers must first guess a user name configured as a sudoer as well as the user password.<br />
<br />
{{Warning|Be careful, you may lock yourself out by disabling root login. Sudo is not automatically installed and its default configuration allows neither passwordless root access nor root access with your own password. Ensure a user is properly configured as a sudoer ''before'' disabling the root account!}}<br />
{{Note|If you are already locked out, see [[Password Recovery]] for help.}}<br />
<br />
The account can be locked via {{ic|passwd}}:<br />
<br />
# passwd -l root<br />
<br />
A similar command unlocks root.<br />
<br />
$ sudo passwd -u root<br />
<br />
Alternatively, edit {{ic|/etc/shadow}} and replace the root's encrypted password with "!":<br />
<br />
root:!:12345::::::<br />
<br />
To enable root login again:<br />
<br />
$ sudo passwd root<br />
<br />
==== gksu ====<br />
<br />
To set ''gksu'' to use sudo by default:<br />
<br />
$ gconftool-2 --set --type boolean /apps/gksu/sudo-mode true<br />
<br />
==== kdesu ====<br />
<br />
kdesu may be used under KDE to launch GUI applications with root privileges. It is possible that by default kdesu will try to use su even if the root account is disabled. Fortunately one can tell kdesu to use sudo instead of su. Create/edit the file {{ic|~/.kde4/share/config/kdesurc}}:<br />
<br />
[super-user-command]<br />
super-user-command=sudo<br />
<br />
Alternatively, install {{AUR|kdesudo}} from [[AUR]], which has the added advantage of tab-completion for the command following.<br />
<br />
==== PolicyKit ====<br />
<br />
{{Out of date|As of 2014-04-22 the {{ic|/etc/polkit-1/localauthority.conf.d}} folder does not exist and therefore cannot be edited. A possible replacement may lie in the {{ic|/etc/polkit-1/lrules.d/50-default.rules}} file which already mentions by default {{ic|unix-group wheel}} as polkitAdminRule. For more info see [[PolicyKit#Administrator_identities]].}}<br />
<br />
When disabling the root account, it is necessary to change the [[PolicyKit]] configuration for local authorization to reflect that. The default is to ask for the root password, so that must be changed. With polkit-1, this can be achieved by editing {{ic|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf}} so that {{ic|1=AdminIdentities=unix-user:0}} is replaced with something else, depending on the system configuration. It can be a list of users and groups, for example:<br />
<br />
AdminIdentities=unix-group:wheel<br />
<br />
or<br />
<br />
AdminIdentities=unix-user:me;unixuser:mom;unix-group:wheel<br />
<br />
For more information, see {{ic|man pklocalauthority}}.<br />
<br />
==== NetworkManager ====<br />
<br />
Even with the above PolicyKit configuration you still need to configure a policy for NetworkManager. This is documented on the [[NetworkManager#Set_up_PolicyKit_permissions|NetworkManager]] page of this wiki.<br />
<br />
=== Harden with Sudo Example ===<br />
<br />
Lets say you create 3 users: admin, devel, and joe. The user "admin" is used for journalctl, systemctl, mount, kill, and iptables; "devel" is used for installing packages, and editing config's; and "joe" is the user you log in with. To let "joe" reboot, shutdown, and use netctl we would do the following:<br />
<br />
Edit /etc/pam.d/su and /etc/pam.d/su-1<br />
Require user be in the wheel group, but do not put anyone in it.<br />
#%PAM-1.0<br />
auth sufficient pam_rootok.so<br />
# Uncomment the following line to implicitly trust users in the "wheel" group.<br />
#auth sufficient pam_wheel.so trust use_uid<br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
auth required pam_unix.so<br />
account required pam_unix.so<br />
session required pam_unix.so<br />
<br />
Limit SSH login to the 'ssh' group. Only put "joe" will be part of this group.<br />
groupadd -r ssh<br />
gpasswd -a joe ssh<br />
echo 'AllowGroups ssh' >> /etc/ssh/sshd_config<br />
systemctl restart sshd.service<br />
<br />
Add users to other groups.<br />
for g in power network ;do ;gpasswd -a joe $g ;done<br />
for g in network power storage ;do ;gpasswd -a admin $g ;done<br />
<br />
Set permissions on configs so devel can edit them.<br />
chown -R devel:root /etc/{http,openvpn,cups,zsh,vim,screenrc}<br />
<br />
<br />
# Must use Target Users password not your password<br />
Defaults targetpw<br />
#<br />
Cmnd_Alias POWER = /usr/bin/shutdown -h now, /usr/bin/halt, /usr/bin/poweroff, /usr/bin/reboot<br />
Cmnd_Alias STORAGE = /usr/bin/mount, /usr/bin/umount<br />
Cmnd_Alias SYSTEMD = /usr/bin/journalctl, /usr/bin/systemctl<br />
Cmnd_Alias KILL = /usr/bin/kill, /usr/bin/killall<br />
Cmnd_Alias PKGMAN = /usr/bin/pacman<br />
Cmnd_Alias NETWORK = /usr/bin/netctl<br />
Cmnd_Alias FIREWALL = /usr/bin/iptables, /usr/bin/ip6tables<br />
Cmnd_Alias SHELL = /usr/bin/zsh, /usr/bin/bash<br />
%power ALL = (root) NOPASSWD: POWER<br />
%network ALL = (root) NETWORK<br />
%storage ALL = (root) STORAGE<br />
root ALL = (ALL) ALL<br />
admin ALL = (root) SYSTEMD, KILL, FIREWALL<br />
devel ALL = (root) PKGMAN<br />
Joe ALL = (devel) SHELL, (admin) SHELL <br />
<br />
With this setup, you will almost never need to login as the Root user.<br />
<br />
"Joe" can connect to his home WiFi.<br />
sudo netctl start home<br />
sudo poweroff<br />
<br />
"Joe" can not use netctl as any other user.<br />
sudo -u admin -- netctl start home<br />
<br />
When "joe" needs to use journalctl or kill run away process he can switch to that user<br />
sudo -i -u devel<br />
sudo -i -u admin<br />
<br />
But "joe" cannot switch to the root user.<br />
sudo -i -u root<br />
<br />
If "joe" want to start a gnu-screen session as admin he can do it like this:<br />
sudo -i -u admin<br />
admin% chown admin:tty `echo $TTY`<br />
admin% screen<br />
<br />
== Troubleshooting ==<br />
<br />
=== SSH TTY Problems ===<br />
<br />
SSH does not allocate a tty by default when running a remote command. Without a tty, sudo cannot disable echo when prompting for a password. You can use ssh's {{ic|-tt}} option to force it to allocate a tty (or {{ic|-t}} twice).<br />
<br />
The {{ic|Defaults}} option {{ic|requiretty}} only allows the user to run sudo if they have a tty.<br />
<br />
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear text. You have to run "ssh -t hostname sudo <cmd>".<br />
#<br />
#Defaults requiretty<br />
<br />
=== Display User Privileges ===<br />
<br />
You can find out what privileges a particular user has with the following command:<br />
<br />
$ sudo -lU yourusename<br />
<br />
Or view your own with:<br />
<br />
{{hc|$ sudo -l|<nowiki><br />
Matching Defaults entries for yourusename on this host:<br />
loglinelen=0, logfile=/var/log/sudo.log, log_year, syslog=auth, mailto=webmaster@gmail.com, mail_badpass, mail_no_user,<br />
mail_no_perms,env_reset, always_set_home, tty_tickets, lecture=always, pwfeedback, rootpw, set_home<br />
<br />
User yourusename may run the following commands on this host:<br />
<br />
(ALL) ALL<br />
(ALL) NOPASSWD: /usr/bin/lsof, /bin/nice, /usr/bin/su, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync, /usr/bin/strace,<br />
(ALL) /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
(ALL) /usr/bin/gparted, /usr/bin/pacman<br />
(ALL) /usr/local/bin/synergyc, /usr/local/bin/synergys<br />
(ALL) /usr/bin/vim, /usr/bin/nano, /usr/bin/cat<br />
(root) NOPASSWD: /usr/local/bin/synergyc</nowiki>}}<br />
<br />
=== Permissive Umask ===<br />
<br />
Sudo will union the user's [[umask]] value with its own umask (which defaults to 0022). This prevents sudo from creating files with more open permissions than the user's umask allows. While this is a sane default if no custom umask is in use, this can lead to situations where a utility run by sudo may create files with different permissions than if run by root directly. If errors arise from this, sudo provides a means to fix the umask, even if the desired umask is more permissive than the umask that the user has specified. Adding this (using {{ic|visudo}}) will override sudo's default behavior:<br />
<br />
Defaults umask = 0022<br />
Defaults umask_override<br />
<br />
This sets sudo's umask to root's default umask (0022) and overrides the default behavior, always using the indicated umask regardless of what umask the user as set.<br />
<br />
=== Defaults Skeleton ===<br />
<br />
The authors site has a [http://www.gratisoft.us/sudo/sudoers.man.html#sudoers_options list of all the options] that can be used with the {{ic|Defaults}} command in the {{ic|/etc/sudoers}} file.<br />
<br />
The full list of options ''(parsed from the version 1.8.7 source code)'' is below in a format optimized for copying and pasting into your sudoers files for quick editing.<br />
<br />
{{bc|<nowiki>#Defaults always_set_home<br />
# If enabled, sudo will set the HOME environment variable to the home directory of the target user<br />
# (which is root unless the -u option is used). This effectively means that the -H option<br />
# always_set_home is only effective for configurations where either env_reset is disabled or HOME is present<br />
# in the env_keep list. Default: OFF<br />
<br />
#Defaults authenticate<br />
# If set, users must authenticate themselves via a password (or other means of authentication)<br />
# before they may run commands. This default may be overridden via the PASSWD and NOPASSWD<br />
<br />
#Defaults closefrom_override<br />
# If set, the user may use sudo's -C option which overrides the default starting<br />
# point at which sudo begins closing open file descriptors. Default: OFF<br />
<br />
#Defaults compress_io<br />
# If set, and sudo is configured to log a command's input or output, the I/O logs will be<br />
# compressed using zlib. This flag is on by default when sudo is compiled with zlib support.<br />
<br />
#Defaults env_editor<br />
# If set, visudo will use the value of the EDITOR or VISUAL environment variables before falling back on the default<br />
# editor list. Note that this may create a security hole as it allows th separated list of editors in the editor<br />
# variable. visudo will then only use the EDITOR or VISUAL if they match a value specified in editor. On by default.<br />
<br />
#Defaults env_reset<br />
# If set, sudo will run the command in a minimal environment containing the TERM, PATH, HOME, MAIL, SHELL, LOGNAME,<br />
# USER, USERNAME and SUDO_* variables. Any variables in the caller's env in the file specified by the env_file<br />
# option (if any). The default contents of the env_keep and env_check lists are displayed when sudo is run by<br />
# root with the -V option.<br />
<br />
#Defaults fast_glob<br />
# Normally, sudo uses the glob(3) function to do shell-style globbing when matching path names.<br />
# However, since it accesses the file system, glob(3) can take a long time to complete for som (automounted).<br />
# The fast_glob option causes sudo to use the fnmatch(3) function, which does not access the file system to do<br />
# its matching. The disadvantage of fast_glob is that it is unable to ma names that include globbing characters<br />
# are used with the negation operator, '!', as such rules can be trivially bypassed. As such, this option should<br />
# not be used when sudoers contains rules that<br />
<br />
#Defaults fqdn<br />
# Set this flag if you want to put fully qualified host names in the sudoers file. I.e., instead of myhost you<br />
# would use myhost.mydomain.edu. You may still use the short form if you wish (and sudo unusable if DNS stops<br />
# working (for example if the machine is not plugged into the network). Also note that you must use the<br />
# host's official name as DNS knows it. That is, you may not use a all aliases from DNS. If your machine's<br />
# host name (as returned by the hostname command) is already fully qualified you should not need to set fqdn.<br />
# Default: OFF<br />
<br />
#Defaults ignore_dot<br />
# If set, sudo will ignore '.' or '' (current dir) in the PATH environment variable; the PATH<br />
# itself is not modified. Default: OFF<br />
<br />
#Defaults ignore_local_sudoers<br />
# If set via LDAP, parsing of /etc/sudoers will be skipped. This is intended for Enterprises that wish to prevent<br />
# the usage of local sudoers files so that only LDAP is used. /etc/sudoers does not even need to exist.<br />
# Since this option tells sudo how to behave when no specific LDAP entries have been matched, this sudo<br />
# Option is only meaningful for the cn=default<br />
<br />
#Defaults insults<br />
# If set, sudo will insult users when they enter an incorrect password. Default: OFF<br />
<br />
#Defaults log_host<br />
# If set, the host name will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults log_input<br />
# If set, sudo will run the command in a pseudo tty and log all user input. If the standard<br />
# input is not connected to the user's tty, due to I/O redirection or because the command is part Input is logged<br />
# to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that<br />
# is included in the normal sudo log line, prefixed with TSID=. Note that user input may contain sensitive<br />
# information such as passwords (even if they are not echoed to the screen), which will be stored in the log file<br />
# unencrypted.<br />
<br />
#Defaults log_output<br />
# If set, sudo will run the command in a pseudo tty and log all output that is sent to the<br />
# screen, similar to the script(1) command. If the standard output or standard error is not connec is also captured and<br />
# stored in separate log files. Output is logged to the directory specified by the iolog_dir option (/var/log/sudo-io<br />
# by default) using a unique session ID that is included in the normal sudo log line, prefixed with TSID=. The Output<br />
# logs may be viewed with the sudoreplay(8) utility, which can also be used to list or search the available logs.<br />
<br />
#Defaults log_year<br />
# If set, the four-digit year will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults long_otp_prompt<br />
# When validating with a One Time Password (OTP) scheme such as S/Key or OPIE, a two-line<br />
# prompt is used to make it easier to cut and paste the challenge to a local window<br />
<br />
#Defaults mail_always<br />
# Send mail to the mailto user every time a users runs sudo. Default: OFF<br />
<br />
#Defaults mail_badpass<br />
# Send mail to the mailto user if the user running sudo does not enter the correct password.<br />
# Default: OFF<br />
<br />
#Defaults mail_no_host<br />
# If set, mail will be sent to the mailto user if the invoking user exists in the sudoers<br />
# file, but is not allowed to run commands on the current host. Default: OFF<br />
<br />
#Defaults mail_no_perms<br />
# If set, mail will be sent to the mailto user if the invoking user is allowed to use sudo<br />
# but the command they are trying is not listed in their sudoers file entry or is explicitly denied<br />
<br />
#Defaults mail_no_user<br />
# If set, mail will be sent to the mailto user if the invoking user is not in the sudoers file.<br />
# Default: ON<br />
<br />
#Defaults noexec<br />
# If set, all commands run via sudo will behave as if the NOEXEC tag has been set, unless overridden<br />
# by a EXEC tag. See the description of NOEXEC and EXEC below as well as the "PREVENTING SHE<br />
<br />
#Defaults path_info<br />
# Normally, sudo will tell the user when a command could not be found in their PATH environment<br />
# variable. Some sites may wish to disable this as it could be used to gather information on t the executable is<br />
# simply not in the user's PATH, sudo will tell the user that they are not allowed to run it, which can be confusing.<br />
# Default: ON<br />
<br />
#Defaults passprompt_override<br />
# The password prompt specified by passprompt will normally only be used if the password prompt provided by<br />
# systems such as PAM matches the string "Password:"<br />
<br />
#Defaults preserve_groups<br />
# By default, sudo will initialize the group vector to the list of groups the target<br />
# user is in. When preserve_groups is set, the user's existing group vector is left unaltered.<br />
<br />
#Defaults pwfeedback<br />
# By default, sudo reads the password like most other Unix programs, by turning off echo<br />
# until the user hits the return (or enter) key. Some users become confused by this as it appears to the user<br />
# presses a key. Note that this does have a security impact as an onlooker may be able to determine the length of<br />
# the password being entered. Default: OFF<br />
<br />
#Defaults requiretty<br />
# If set, sudo will only run when the user is logged in to a real tty. When this flag is set,<br />
# sudo can only be run from a login session and not via other means such as cron(8) or cgi-bin<br />
<br />
#Defaults root_sudo<br />
# If set, root is allowed to run sudo too. Disabling this prevents users from "chaining" sudo<br />
# commands to get a root shell by doing something like "sudo sudo /bin/sh". Note, however, that real additional<br />
# security; it exists purely for historical reasons. Default: ON<br />
<br />
#Defaults rootpw<br />
# If set, sudo will prompt for the root password instead of the password of the invoking user.<br />
# Default: OFF<br />
<br />
#Defaults runaspw<br />
# If set, sudo will prompt for the password of the user defined by the runas_default option<br />
# (defaults to root) instead of the password of the invoking user. Default: OFF<br />
<br />
#Defaults set_home<br />
# If enabled and sudo is invoked with the -s option the HOME environment variable will be set<br />
# to the home directory of the target user (which is root unless the -u option is used). So set_home is only<br />
# effective for configs where either env_reset is disabled or HOME is present in the env_keep list. Default: OFF<br />
<br />
#Defaults set_logname<br />
# Normally, sudo will set the LOGNAME, USER and USERNAME environment variables to the name<br />
# of the target user (usually root unless the -u option is given). However, since some programs ( may be desirable<br />
# to change this behavior. This can be done by negating the set_logname option. Note that if the env_reset option<br />
# has not been disabled, entries in the env_keep list will override<br />
<br />
#Defaults set_utmp<br />
# When enabled, sudo will create an entry in the utmp (or utmpx) file when a pseudo-tty is<br />
# allocated. A pseudo-tty is allocated by sudo when the log_input, log_output or use_pty flags are e the tty, time,<br />
# type and pid fields updated. Default: ON<br />
<br />
#Defaults setenv<br />
# Allow the user to disable the env_reset option from the command line via the -E option.<br />
# Additionally, environment variables set via the command line are not subject to the restrictions impo variables<br />
# in this manner. Default: OFF<br />
<br />
#Defaults shell_noargs<br />
# If set and sudo is invoked with no arguments it acts as if the -s option had been given.<br />
# That is, it runs a shell as root (the shell is determined by the SHELL environment variable if is off by default.<br />
<br />
#Defaults stay_setuid<br />
# Normally, when sudo executes a command the real and effective UIDs are set to the target<br />
# user (root by default). This option changes that behaviour such that the real UID is left as the systems that<br />
# disable some potentially dangerous functionality when a program is run setuid. This option is only effective on<br />
# systems with either the setreuid() or setresuid() function. This flag<br />
<br />
#Defaults targetpw<br />
# If set, sudo will prompt for the password of the user specified by the -u option (defaults to root) instead<br />
# of the password of the invoking user. In addition, the timestamp file name will passwd database as an argument<br />
# to the -u option. Default: OFF<br />
<br />
#Defaults tty_tickets<br />
# If set, users must authenticate on a per-tty basis. With this flag enabled, sudo will<br />
# use a file named for the tty the user is logged in on in the user's time stamp directory.<br />
<br />
#Defaults umask_override<br />
# If set, sudo will set the umask as specified by sudoers without modification. This makes<br />
# it possible to specify a more permissive umask in sudoers than the user's own umask and match user's umask and what<br />
# is specified in sudoers. Default: OFF<br />
<br />
#Defaults use_pty<br />
# If set, sudo will run the command in a pseudo-pty even if no I/O logging is being gone.<br />
# A malicious program run under sudo could conceivably fork a background process that retains to the u that impossible.<br />
# Default: OFF<br />
<br />
#Defaults utmp_runas<br />
# If set, sudo will store the name of the runas user when updating the utmp (or utmpx) file.<br />
# By default, sudo stores the name of the invoking user. Default: OFF<br />
<br />
#Defaults visiblepw<br />
# By default, sudo will refuse to run if the user must enter a password but it is not possible to disable echo on the <br />
# terminal. If the visiblepw flag is set, sudo will prompt for a password even when it would be visible on the screen. <br />
# This makes it possible to run things like "rsh somehost sudo ls" since rsh(1) does not allocate a tty. Default: OFF<br />
<br />
#Defaults closefrom<br />
# Before it executes a command, sudo will close all open file descriptors other than standard<br />
# input, standard output and standard error (ie: file descriptors 0-2).<br />
<br />
#Defaults passwd_tries<br />
# The number of tries a user gets to enter his/her password before sudo logs the failure<br />
# and exits. The default is 3.<br />
<br />
#Defaults loglinelen<br />
# Number of characters per line for the file log. This value is used to decide when to wrap<br />
# lines for nicer log files. This has no effect on the syslog log file, only the file log.<br />
<br />
#Defaults passwd_timeout<br />
# Number of minutes before the sudo password prompt times out, or 0 for no timeout.<br />
# The timeout may include a fractional component if minute granularity is insufficient, for example 2<br />
<br />
#Defaults timestamp_timeout<br />
# Number of minutes that can elapse before sudo will ask for a passwd again. The timeout<br />
# may include a fractional component if minute granularity is insufficient, for example 2.5. timestamp will never expire.<br />
# This can be used to allow users to create or delete their own timestamps via sudo -v and sudo -k respectively.<br />
<br />
#Defaults umask<br />
# Umask to use when running the command. Negate this option or set it to 0777 to preserve<br />
# the user's umask. The actual umask that is used will be the union of the user's umask and the value o running<br />
# a command. Note on systems that use PAM, the default PAM configuration may specify its own umask which will<br />
# override the value set in sudoers.<br />
<br />
#Defaults badpass_message<br />
# Message that is displayed if a user enters an incorrect password. The default is Sorry,<br />
# try again. unless insults are enabled.<br />
<br />
#Defaults editor<br />
# A colon (':') separated list of editors allowed to be used with visudo. visudo will choose<br />
# the editor that matches the user's EDITOR environment variable if possible, or the first editor in<br />
<br />
#Defaults iolog_dir<br />
# The top-level directory to use when constructing the path name for the input/output log<br />
# directory. Only used if the log_input or log_output options are enabled or when the LOG_INPUT or L directory.<br />
# The default is "/var/log/sudo-io". The following percent (%) escape sequences are supported:<br />
# %{seq} - expanded to base-36 sequence number, such as 0100A5, to form a new directory, e.g. 01/00/A5<br />
# %{user} - expanded to the invoking user's login name<br />
# %{group} - expanded to the name of the invoking user's real group ID<br />
# %{runas_user} - expanded to the login name of the user the command will be run as (e.g. root)<br />
# %{runas_group} - expanded to the group name of the user the command will be run as (e.g. wheel)<br />
# %{hostname} - expanded to the local host name without the domain name<br />
# %{command} - expanded to the base name of the command being run In addition, any escape sequences supported by<br />
# strftime() function will be expanded. To include a literal % character, the string %% should be used.<br />
<br />
#Defaults iolog_file<br />
# The path name, relative to iolog_dir, in which to store input/output logs when the log_input or log_output options are<br />
# enabled or when the LOG_INPUT or LOG_OUTPUT tags are present for a See the iolog_dir option above for a list of<br />
# supported percent (%) escape sequences. In addition to the escape sequences, path names that end in six or more Xs will<br />
# have the Xs replaced with a unique combination of digits and letters, similar to the mktemp() function.<br />
<br />
#Defaults mailsub<br />
# Subject of the mail sent to the mailto user. The escape %h will expand to the host name of<br />
# the machine. Default is *** SECURITY information for %h ***.<br />
<br />
#Defaults noexec_file<br />
# This option is no longer supported. The path to the noexec file should now be set in the /etc/sudo.conf file.<br />
<br />
#Defaults passprompt<br />
# The default prompt to use when asking for a password; can be overridden via the -p option or the SUDO_PROMPT<br />
# environment variable. The following percent (%) escape sequences are supported:<br />
# %H - expanded to the local host name including the domain (only if the host name is fqdn or fqdn option is set)<br />
# %h - expanded to the local host name without the domain name<br />
# %p - expanded to the user whose password is being asked for (respects the rootpw, targetpw and runaspw flags)<br />
# %U - expanded to the login name of the user the command will be run as (defaults to root)<br />
# %u - expanded to the invoking user's login name<br />
# %% - two consecutive % characters are collapsed into a single % character<br />
# The default value is Password:.<br />
<br />
#Defaults runas_default<br />
# The default user to run commands as if the -u option is not specified on the command line. This defaults to root.<br />
<br />
#Defaults syslog_badpri<br />
# Syslog priority to use when user authenticates unsuccessfully. Defaults to alert.<br />
# alert, crit, debug, emerg, err, info, notice, and warning.<br />
<br />
#Defaults syslog_goodpri<br />
# Syslog priority to use when user authenticates successfully. Defaults to notice. See syslog_badpri for the priorities.<br />
<br />
#Defaults sudoers_locale<br />
# Locale to use when parsing the sudoers file, logging commands, and sending email.<br />
# Note that changing the locale may affect how sudoers is interpreted. Defaults to "C".<br />
<br />
#Defaults timestampdir<br />
# The directory in which sudo stores its timestamp files. The default is /var/db/sudo.<br />
<br />
#Defaults timestampowner<br />
# The owner of the timestamp directory and the timestamps stored therein. The default is root.<br />
<br />
#Defaults env_file<br />
# The env_file option specifies the fully qualified path to a file containing variables to<br />
# be set in the environment of the program being run. Entries in this file should either be of the f quotes.<br />
# Variables in this file are subject to other sudo environment settings such as env_keep and env_check.<br />
<br />
#Defaults exempt_group<br />
# Users in this group are exempt from password and PATH requirements. The group name specified should not include<br />
# a % prefix. This is not set by default.<br />
<br />
#Defaults group_plugin<br />
# A string containing a sudoers group plugin with optional arguments. This can be used to implement support for the<br />
# nonunix_group syntax described earlier. The string should consist of configuration arguments the plugin requires.<br />
# These arguments (if any) will be passed to the plugin's initialization function. If arguments are present, the<br />
# string must be enclosed in double quote For example, given /etc/sudo-group, a group file in Unix group format,<br />
# the sample group plugin can be used: Defaults group_plugin="sample_group.so /etc/sudo-group"<br />
# For more information see sudo_plugin(5).<br />
<br />
#Defaults lecture<br />
# This option controls when a short lecture will be printed along with the password prompt. The default value is once.<br />
# It has the following possible values:<br />
# always - Always lecture the user.<br />
# never - Never lecture the user.<br />
# once - Only lecture the user the first time they run sudo.<br />
# If no value is specified, a value of once is implied. Negating the option results in a value of never being used.<br />
<br />
#Defaults lecture_file<br />
# Path to a file containing an alternate sudo lecture that will be used in place of the standard lecture if the named<br />
# file exists. By default, sudo uses a built-in lecture.<br />
<br />
#Defaults listpw<br />
# This option controls when a password will be required when a user runs sudo with the -l option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD set to avoid entering a pass.<br />
# always - The user must always enter a password to use the -l option.<br />
# any - At least one of the user's sudoers entries for the current host must have the NOPASSWD set to avoid pass.<br />
# never - The user need never enter a password to use the -l option.<br />
# If no value is specified, a value of any is implied. The default value is any.<br />
<br />
#Defaults logfile<br />
# Path to the sudo log file (not the syslog log file). Setting a path turns on logging to a file;<br />
# negating this option turns it off. By default, sudo logs via syslog.<br />
<br />
#Defaults mailerflags<br />
# Flags to use when invoking mailer. Defaults to -t.<br />
<br />
#Defaults mailerpath<br />
# Path to mail program used to send warning mail. Defaults to the path to sendmail found at configure time.<br />
<br />
#Defaults mailfrom<br />
# Address to use for the "from" address when sending warning and error mail. The address should<br />
# be enclosed in double quotes (") to protect against sudo interpreting the @ sign.<br />
<br />
#Defaults mailto<br />
# Address to send warning and error mail to. The address should be enclosed in double quotes<br />
# (") to protect against sudo interpreting the @ sign. Defaults to root.<br />
<br />
#Defaults secure_path<br />
# Path used for every command run from sudo. If you do not trust the people running sudo to have a sane PATH environment<br />
# variable you may want to use this. Another use is if you want to option are not affected by secure_path.<br />
# This option is not set by default.<br />
<br />
#Defaults syslog<br />
# Syslog facility if syslog is being used for logging (negate to disable syslog logging). Defaults to auth.<br />
# authpriv (if OS supports it), auth, daemon, user, local0, local1, local2, local3, local4, local5, local6, and local7.<br />
<br />
#Defaults verifypw<br />
# This option controls when a password will be required when a user runs sudo with the -v option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD flag to avoid pw.<br />
# always - The user must always enter a password to use the -v option.<br />
# any - At least one of the user's sudoers entries for the current host must have NOPASSWD to avoid pw.<br />
# never - The user need never enter a password to use the -v option<br />
# If no value is specified, a value of all is implied. Negating the option results in a value of never being used.<br />
# The default value is all.<br />
<br />
#Defaults env_check<br />
# Environment variables to be removed from the user's environment if the variable's value contains % or / characters.<br />
# This can be used to guard against printf-style format vulnerabilities value without double-quotes. The list can be<br />
# replaced, added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively. Regardless of<br />
# whether the env_reset option is ena they pass the aforementioned check. The default list of environment variables<br />
# to check is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_delete<br />
# Environment variables to be removed from the user's environment when the env_reset option is not in effect. The<br />
# argument may be a double-quoted, space-separated list or a single value w +=, -=, and ! operators respectively.<br />
# The default list of environment variables to remove is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_keep<br />
# Environment variables to be preserved in the user's environment when the env_reset option is in effect. This<br />
# allows fine-grained control over the environment sudo-spawned processes will r quotes. The list can be replaced,<br />
# added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively.</nowiki>}}</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Nextcloud&diff=296027Nextcloud2014-02-03T11:19:55Z<p>Hunterthomson: /* Nginx + uwsgi_php alternative */ After spending all day on this I've figured out how to get this more secure but will add a section at the bottom instead of putting it here</p>
<hr />
<div>[[Category:Web Server]]<br />
[[fr:Owncloud]]<br />
[[ja:Owncloud]]<br />
From [[Wikipedia:ownCloud|Wikipedia]]:<br />
: ''ownCloud is a software suite that provides a location-independent storage area for data (cloud storage).''<br />
<br />
== Installation ==<br />
<br />
Set up the [[LAMP]] stack. <br />
<br />
You will probably need to install the MDB2 pear package as well. Install {{pkg|php-pear}}, then:<br />
# pear install MDB2<br />
<br />
# [[pacman|Install]] {{Pkg|owncloud}} from the [[official repositories]]. Alternatively see the packages available in the [[Arch User Repository]]: [https://aur.archlinux.org/packages.php?K=owncloud&O=0].<br />
# Copy {{ic|/etc/webapps/owncloud/apache.example.conf}} to {{ic|/etc/httpd/conf/extra/owncloud.conf}} (version 6+)<br />
# Add the following lines into {{ic|/etc/httpd/conf/httpd.conf}} (the php5 line should have already been added during the LAMP stack setup):<br />
Include /etc/httpd/conf/extra/owncloud.conf<br />
LoadModule php5_module modules/libphp5.so<br />
Include conf/extra/php5_module.conf<br />
<br />
Uncomment extensions in {{ic|/etc/php/php.ini}}:<br />
gd.so<br />
intl.so<br />
openssl.so<br />
xmlrpc.so<br />
zip.so<br />
iconv.so<br />
<br />
=== Database support ===<br />
Depending on which database backend you are going to use uncomment either one of the following extensions in {{ic|/etc/php/php.ini}}:<br />
{|border=1 class="wikitable"<br />
!SQLite!!MySQL!!PostgreSQL<br />
|-<br />
|<br />
sqlite.so<br />
sqlite3.so<br />
pdo_sqlite.so<br />
|<br />
mysql.so<br />
mysqli.so<br />
pdo_mysql.so<br />
|<br />
pgsql.so<br />
pdo_pgsql.so<br />
|-<br />
|}<br />
Don't forget to install the appropriate php-module for the database. In the PostgreSQL case thats {{Pkg|php-pgsql}} or for SQLite {{Pkg|php-sqlite}}.<br />
<br />
=== Exif support ===<br />
Additionally install exif support with<br />
# pacman -S exiv2<br />
and uncomment the exif.so extension in php.ini<br />
<br />
=== Disable Webdav ===<br />
Owncloud comes with its own Webdav enabled which conflict. Owncloud [http://forum.owncloud.org/viewtopic.php?f=17&t=7240 recommends] to disable mod_dav and mod_dav_fs. This should be done in {{ic|/etc/httpd/conf/httpd.conf}}<br />
<br />
Now [[Daemons#Restarting|restart]] httpd (Apache)<br />
# systemctl restart httpd<br />
Open [http://localhost http://localhost] in your browser. You should now be able to create a user account and follow the installation wizard.<br />
<br />
== Custom configurations ==<br />
<br />
=== Filesize limitations ===<br />
<br />
With the default configuration ownCloud only allows the upload of filesizes less than 2MB.<br />
This can be changed by changing the following line in {{ic|/etc/php/php.ini}} to your liking.<br />
<br />
'''As of version 4.0 this is no longer necessary! The maximum upload size is now set via the ownCloud gui'''<br />
upload_max_filesize = 2M<br />
<br />
As of version 4.5, upload limits are set in {{ic|/usr/share/webapps/owncloud/.htaccess}}. This won't work if [[LAMP#Using_php5_with_apache2-mpm-worker_and_mod_fcgid|PHP is set up to run as CGI]], so you need to change the limits in {{ic|/etc/php/php.ini}}. You also need to change open_basedir.<br />
{{bc|<nowiki><br />
upload_max_filesize = 512M<br />
post_max_size = 512M<br />
memory_limit = 512M<br />
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/<br />
</nowiki>}}<br />
<br />
=== Running ownCloud in a subdirectory ===<br />
<br />
By including the default '''owncloud.conf''' in '''httpd.conf''', owncloud will take control of port 80 and your localhost domain. If you would like to have owncloud run in a subdirectory, then skip the 'Include /etc/httpd/conf/extra/owncloud.conf' line altogether and just use a symbolic link like so: <br />
# ln -s /usr/share/webapps/owncloud/ /srv/http/<br />
<br />
In that case, you'll also have to ensure /usr/share/webapps is in the open_basedir line of php.ini, and that per-directory .htaccess files are read by apache. <br />
<br />
Alternatively, you could follow the standard procedure, but comment out the VirtualHost part of the include file, and skip the symlink/basedir/htaccess part.<br />
<br />
== Filling ownCloud with data ==<br />
<br />
=== Small files ===<br />
<br />
==== WebDav ====<br />
<br />
Always use [[WebDAV]] or the web interface to add new files to your ownCloud. Otherwise they will not show up correctly, as they do not get indexed right.<br />
No further configuration is necessary to enable [[WebDAV]] uploads in ownCloud. <br />
<br />
Consider installing and enabling [[php-apc]] to speed up WebDAV.<br />
<br />
==== SABnzbd ====<br />
<br />
When using [[SABnzbd]], you might want to set<br />
folder_rename 0<br />
in your sabnzbd.ini file, because ownCloud will scan the files as soon as they get uploaded, preventing SABnzbd from removing UNPACKING prefixes etc.<br />
<br />
=== Big files ===<br />
<br />
WebDAV isn't suitable for big files, because it fills up all the RAM and CPU.<br />
<br />
With the current version, it looks like, there is no good way of copying huge amounts of data to your ownCloud.<br />
<br />
Here's a Workaround:<br />
<br />
Copy the files directly to your ownCloud and do a full re-scan of your database (you could use the [http://apps.owncloud.com/content/show.php?content=151948&forumpage=0&PHPSESSID=37b915160effcc0f37cc761ad2ab88be Re-scan filesystem] add-on for example).<br />
<br />
But beware that this will not work as easily in the future, when end-to-end encryption gets added to ownCloud (this is a planned feature).<br />
<br />
== Important notes ==<br />
<br />
* When using a subdomain (like cloud.example.net), make sure it is covered by your certificate. Otherwise, connection via the owncloud client or webdav might fail.<br />
<br />
* If you are planning on using OwnCloud's [http://owncloud.org/sync-clients/ sync-clients], make sure to have [[NTP]] installed and running on your OwnCloud server, otherwise the sync-clients will fail.<br />
<br />
* Add some [[LAMP#SSL|SSL encryption]] to your connection!<br />
(If adding SSL encryption as above, be sure to edit /etc/httpd/conf/extra/httpd-ssl.conf and change DocumentRoot "/srv/http" to DocumentRoot "/usr/share/webapps/owncloud" )<br />
<br />
* More Apps for ownCloud can be found [http://apps.owncloud.com/ here]<br />
<br />
* To install an new application, download the zip from the apps store, extract it into /srv/http/owncloud/apps/.<br />
Afterwards restart httpd:<br />
<br />
systemctl restart httpd<br />
<br />
log into your server go to the app sections you should see the new apps in there,<br />
<br />
* If you are protecting access to your owncloud location with HTTP basic auth, the file "status.php" must be excluded from auth and be publicly accessible. [https://github.com/owncloud/mirall/issues/734]<br />
<br />
== Nginx + uwsgi_php alternative ==<br />
<br />
You can avoid the use of Apache, and run owncloud in it's own process by using the [https://www.archlinux.org/packages/uwsgi-plugin-php wsgi_php] application server. uWSGI itself has a wealth of features to limit the resource use, and to harden the security of the application, and by being a separate process it can run under its own user.<br />
<br />
The nginx config is:<br />
{{bc|<nowiki><br />
#this is to avoid Request Entity Too Large error<br />
client_max_body_size 1000M;<br />
# deny access to some special files<br />
location ~ ^/(data|config|\.ht|db_structure\.xml|README) {<br />
deny all;<br />
}<br />
# pass all .php or .php/path urls to uWSGI<br />
location ~ ^(.+\.php)(.*)$ {<br />
include uwsgi_params;<br />
uwsgi_modifier1 14;<br />
uwsgi_pass 127.0.0.1:3001;<br />
}<br />
# everything else goes to the filesystem,<br />
# but / will be mapped to index.php and run through uwsgi<br />
location / {<br />
root /usr/share/webapps/owncloud;<br />
index index.php;<br />
rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;<br />
rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;<br />
}<br />
</nowiki>}}<br />
The uWSGI /etc/uwsgi/owncloud.ini config file (run it with uwsgi_php --ini /etc/uwsgi/owncloud.ini):<br />
{{bc|<nowiki><br />
[uwsgi]<br />
socket = 127.0.0.1:3001<br />
master = true<br />
chdir = /srv/http/owncloud<br />
php-docroot = /usr/share/webapps/owncloud<br />
php-index = index.php<br />
<br />
# only allow these php files, I don't want to inadvertently run something else<br />
php-allowed-ext = /index.php<br />
php-allowed-ext = /public.php<br />
php-allowed-ext = /remote.php<br />
php-allowed-ext = /cron.php<br />
#php-allowed-ext = /status.php<br />
php-allowed-ext = /settings/apps.php<br />
php-allowed-ext = /core/ajax/update.php<br />
php-allowed-ext = /core/ajax/share.php<br />
php-allowed-ext = /core/ajax/requesttoken.php<br />
php-allowed-ext = /core/ajax/translations.php<br />
php-allowed-ext = /search/ajax/search.php<br />
php-allowed-ext = /search/templates/part.results.php<br />
php-allowed-ext = /settings/admin.php<br />
php-allowed-ext = /settings/users.php<br />
php-allowed-ext = /settings/personal.php<br />
php-allowed-ext = /settings/help.php<br />
php-allowed-ext = /settings/ajax/getlog.php<br />
php-allowed-ext = /settings/ajax/setlanguage.php<br />
php-allowed-ext = /settings/ajax/setquota.php<br />
php-allowed-ext = /settings/ajax/userlist.php<br />
php-allowed-ext = /settings/ajax/createuser.php<br />
php-allowed-ext = /settings/ajax/removeuser.php<br />
php-allowed-ext = /settings/ajax/enableapp.php<br />
php-allowed-ext = /core/ajax/appconfig.php<br />
<br />
php-set = date.timezone=Etc/UTC<br />
php-set = open_basedir=/srv/http/owncloud:/tmp/:/usr/share/pear/:/usr/share/webapps/owncloud<br />
<br />
processes = 10<br />
cheaper = 2<br />
cron = -3 -1 -1 -1 -1 /usr/bin/php -f /usr/share/webapps/owncloud/cron.php 1>/dev/null<br />
<br />
</nowiki>}}<br />
Finally, a simple systemd unit file to start the uwsgi instance can be (this is without using the emperor):<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=OwnCloud service via uWSGI-PHP<br />
<br />
[Service]<br />
User=http<br />
ExecStart=/usr/bin/uwsgi_php --ini /etc/uwsgi/owncloud.ini<br />
ExecReload=/bin/kill -HUP $MAINPID<br />
KillSignal=SIGQUIT<br />
Restart=always<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Sync Clients ==<br />
<br />
The offical clients can be found in this page : [http://owncloud.org/install/ Sync Clients]<br />
Also take notice that while the offical owncloud android app is a paid app on the play store, it is not a paid app on [https://f-droid.org/ F-Droid].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Self-signed certificate not accepted ===<br />
<br />
OwnCloud uses [[Wikipedia:cURL]] and [[Wikipedia:SabreDAV]] to check if [[WebDAV]] is enabled. If you use a SSL/TLS with a self-signed certificate, e.g. as shown in [[LAMP]] and access ownClouds admin panel, you will see the following error message:<br />
<br />
Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken.<br />
<br />
Assuming that you followed the [[LAMP]]-tutorial, execute the following steps:<br />
<br />
Create local directory for non-distribution certificates and copy [[LAMP]]s certificate there. This will prevent {{Ic|ca-certificates}}-updates to overwrite it.<br />
<br />
$ cp /etc/httpd/conf/server.crt /usr/share/ca-certificates/''WWW.EXAMPLE.COM.crt''<br />
<br />
Add ''WWW.EXAMPLE.COM.crt'' to {{ic|/etc/ca-certificates.conf}}:<br />
<br />
''WWW.EXAMPLE.COM.crt''<br />
<br />
Now, regenerate your certificate store:<br />
<br />
$ update-ca-certificates<br />
<br />
Restart the httpd service to activate your certificate.<br />
<br />
<br />
Should this not work consider disabling mod_curl in /etc/php/php.ini.<br />
<br />
=== Can't create data directory (/path/to/dir) ===<br />
<br />
Check your httpd conf file (like owncloud.conf). Add your data dir to <br />
php_admin_value open_basedir "/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/path/to/dir/"<br />
<br />
You should also modify php.ini in the same way. Restart the httpd service to activate the change.<br />
<br />
=== CSync faild to find a specific file. ===<br />
<br />
Most probably a certificate issue, recreate it, and don't leave the common name empty or you will see the error again.<br />
<br />
openssl genrsa -out server.key 2048<br />
openssl req -new -key server.key -x509 -days 365 -out server.crt<br />
<br />
=== Seeing white page after login ===<br />
<br />
The cause is probably a new app that you installed, to fix that you can either use phpMyAdmin by editing the oc_appconfig table(in the case you got lucky and the table has edit option) or do it by hand with mysql:<br />
<br />
mysql -u root -p owncloud<br />
MariaDB [owncloud]> '''delete from''' oc_appconfig '''where''' appid='<nameOfExtension>' '''and''' configkey='enabled' '''and''' configvalue='yes'<br />
MariaDB [owncloud]> '''insert into''' oc_appconfig (appid,configkey,configvalue) '''values''' ('<nameOfExtension>','enabled','no');<br />
<br />
This should delete the relevant configuration from the table and add it again.<br />
<br />
=== GUI sync client fails to connect ===<br />
<br />
If using HTTP basic auth, make sure to exclude "status.php", which must be publicly accessible [https://github.com/owncloud/mirall/issues/734]<br />
<br />
=== "Can't write into apps directory" ===<br />
As mentioned here, http://doc.owncloud.org/server/6.0/admin_manual/configuration/configuration_apps.html either you need an apps directory that is writable by the http user, or you need to set "appstoreenabled" to false. <br />
<br />
''Also'', not mentioned there, the directory needs to be in the open_basedir line in /etc/php/php.ini<br />
<br />
One clean method is to have the package-installed directory at /usr/share/webapps/owncloud/apps stay owned by root, and have the user-installed apps go into e.g. /var/www/owncloud/apps which is owned by http. Then you can set "appstoreenabled" to true and package upgrades of apps should work fine as well. Relevant lines from /etc/webapps/owncloud/config/config.php:<br />
<pre><br />
'apps_paths' => <br />
array (<br />
0 => <br />
array (<br />
'path' => '/usr/share/webapps/owncloud/apps',<br />
'url' => '/apps',<br />
'writable' => false,<br />
),<br />
1 => <br />
array (<br />
'path' => '/var/www/owncloud/apps',<br />
'url' => '/wapps',<br />
'writable' => true,<br />
),<br />
),<br />
</pre><br />
Example open_basedir line from /etc/php/php.ini (you might have other dirs in there as well):<br />
<pre><br />
open_basedir = /srv/http/:/usr/share/webapps/:/var/www/owncloud/apps/<br />
</pre><br />
<br />
Directory permissions:<br />
<pre><br />
$ ls -ld /usr/share/webapps/owncloud/apps /var/www/owncloud/apps/<br />
drwxr-xr-x 26 root root 4096 des. 14 20:48 /usr/share/webapps/owncloud/apps<br />
drwxr-xr-x 2 http http 48 jan. 20 20:01 /var/www/owncloud/apps/<br />
</pre></div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Nextcloud&diff=295962Nextcloud2014-02-03T03:37:39Z<p>Hunterthomson: /* Document Root Security */ Spelling</p>
<hr />
<div>[[Category:Web Server]]<br />
[[fr:Owncloud]]<br />
[[ja:Owncloud]]<br />
From [[Wikipedia:ownCloud|Wikipedia]]:<br />
: ''ownCloud is a software suite that provides a location-independent storage area for data (cloud storage).''<br />
<br />
== Installation ==<br />
<br />
Set up the [[LAMP]] stack. <br />
<br />
You will probably need to install the MDB2 pear package as well. Install {{pkg|php-pear}}, then:<br />
# pear install MDB2<br />
<br />
# [[pacman|Install]] {{Pkg|owncloud}} from the [[official repositories]]. Alternatively see the packages available in the [[Arch User Repository]]: [https://aur.archlinux.org/packages.php?K=owncloud&O=0].<br />
# Copy {{ic|/etc/webapps/owncloud/apache.example.conf}} to {{ic|/etc/httpd/conf/extra/owncloud.conf}} (version 6+)<br />
# Add the following lines into {{ic|/etc/httpd/conf/httpd.conf}} (the php5 line should have already been added during the LAMP stack setup):<br />
Include /etc/httpd/conf/extra/owncloud.conf<br />
LoadModule php5_module modules/libphp5.so<br />
Include conf/extra/php5_module.conf<br />
<br />
Uncomment extensions in {{ic|/etc/php/php.ini}}:<br />
gd.so<br />
intl.so<br />
openssl.so<br />
xmlrpc.so<br />
zip.so<br />
iconv.so<br />
<br />
=== Database support ===<br />
Depending on which database backend you are going to use uncomment either one of the following extensions in {{ic|/etc/php/php.ini}}:<br />
{|border=1 class="wikitable"<br />
!SQLite!!MySQL!!PostgreSQL<br />
|-<br />
|<br />
sqlite.so<br />
sqlite3.so<br />
pdo_sqlite.so<br />
|<br />
mysql.so<br />
mysqli.so<br />
pdo_mysql.so<br />
|<br />
pgsql.so<br />
pdo_pgsql.so<br />
|-<br />
|}<br />
Don't forget to install the appropriate php-module for the database. In the PostgreSQL case thats {{Pkg|php-pgsql}} or for SQLite {{Pkg|php-sqlite}}.<br />
<br />
=== Exif support ===<br />
Additionally install exif support with<br />
# pacman -S exiv2<br />
and uncomment the exif.so extension in php.ini<br />
<br />
=== Disable Webdav ===<br />
Owncloud comes with its own Webdav enabled which conflict. Owncloud [http://forum.owncloud.org/viewtopic.php?f=17&t=7240 recommends] to disable mod_dav and mod_dav_fs. This should be done in {{ic|/etc/httpd/conf/httpd.conf}}<br />
<br />
Now [[Daemons#Restarting|restart]] httpd (Apache)<br />
# systemctl restart httpd<br />
Open [http://localhost http://localhost] in your browser. You should now be able to create a user account and follow the installation wizard.<br />
<br />
== Custom configurations ==<br />
<br />
=== Filesize limitations ===<br />
<br />
With the default configuration ownCloud only allows the upload of filesizes less than 2MB.<br />
This can be changed by changing the following line in {{ic|/etc/php/php.ini}} to your liking.<br />
<br />
'''As of version 4.0 this is no longer necessary! The maximum upload size is now set via the ownCloud gui'''<br />
upload_max_filesize = 2M<br />
<br />
As of version 4.5, upload limits are set in {{ic|/usr/share/webapps/owncloud/.htaccess}}. This won't work if [[LAMP#Using_php5_with_apache2-mpm-worker_and_mod_fcgid|PHP is set up to run as CGI]], so you need to change the limits in {{ic|/etc/php/php.ini}}. You also need to change open_basedir.<br />
{{bc|<nowiki><br />
upload_max_filesize = 512M<br />
post_max_size = 512M<br />
memory_limit = 512M<br />
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/<br />
</nowiki>}}<br />
<br />
=== Running ownCloud in a subdirectory ===<br />
<br />
By including the default '''owncloud.conf''' in '''httpd.conf''', owncloud will take control of port 80 and your localhost domain. If you would like to have owncloud run in a subdirectory, then skip the 'Include /etc/httpd/conf/extra/owncloud.conf' line altogether and just use a symbolic link like so: <br />
# ln -s /usr/share/webapps/owncloud/ /srv/http/<br />
<br />
In that case, you'll also have to ensure /usr/share/webapps is in the open_basedir line of php.ini, and that per-directory .htaccess files are read by apache. <br />
<br />
Alternatively, you could follow the standard procedure, but comment out the VirtualHost part of the include file, and skip the symlink/basedir/htaccess part.<br />
<br />
== Filling ownCloud with data ==<br />
<br />
=== Small files ===<br />
<br />
==== WebDav ====<br />
<br />
Always use [[WebDAV]] or the web interface to add new files to your ownCloud. Otherwise they will not show up correctly, as they do not get indexed right.<br />
No further configuration is necessary to enable [[WebDAV]] uploads in ownCloud. <br />
<br />
Consider installing and enabling [[php-apc]] to speed up WebDAV.<br />
<br />
==== SABnzbd ====<br />
<br />
When using [[SABnzbd]], you might want to set<br />
folder_rename 0<br />
in your sabnzbd.ini file, because ownCloud will scan the files as soon as they get uploaded, preventing SABnzbd from removing UNPACKING prefixes etc.<br />
<br />
=== Big files ===<br />
<br />
WebDAV isn't suitable for big files, because it fills up all the RAM and CPU.<br />
<br />
With the current version, it looks like, there is no good way of copying huge amounts of data to your ownCloud.<br />
<br />
Here's a Workaround:<br />
<br />
Copy the files directly to your ownCloud and do a full re-scan of your database (you could use the [http://apps.owncloud.com/content/show.php?content=151948&forumpage=0&PHPSESSID=37b915160effcc0f37cc761ad2ab88be Re-scan filesystem] add-on for example).<br />
<br />
But beware that this will not work as easily in the future, when end-to-end encryption gets added to ownCloud (this is a planned feature).<br />
<br />
== Important notes ==<br />
<br />
* When using a subdomain (like cloud.example.net), make sure it is covered by your certificate. Otherwise, connection via the owncloud client or webdav might fail.<br />
<br />
* If you are planning on using OwnCloud's [http://owncloud.org/sync-clients/ sync-clients], make sure to have [[NTP]] installed and running on your OwnCloud server, otherwise the sync-clients will fail.<br />
<br />
* Add some [[LAMP#SSL|SSL encryption]] to your connection!<br />
(If adding SSL encryption as above, be sure to edit /etc/httpd/conf/extra/httpd-ssl.conf and change DocumentRoot "/srv/http" to DocumentRoot "/usr/share/webapps/owncloud" )<br />
<br />
* More Apps for ownCloud can be found [http://apps.owncloud.com/ here]<br />
<br />
* To install an new application, download the zip from the apps store, extract it into /srv/http/owncloud/apps/.<br />
Afterwards restart httpd:<br />
<br />
systemctl restart httpd<br />
<br />
log into your server go to the app sections you should see the new apps in there,<br />
<br />
* If you are protecting access to your owncloud location with HTTP basic auth, the file "status.php" must be excluded from auth and be publicly accessible. [https://github.com/owncloud/mirall/issues/734]<br />
<br />
== Nginx + uwsgi_php alternative ==<br />
<br />
You can avoid the use of Apache, and run owncloud in it's own process by using the [https://www.archlinux.org/packages/uwsgi-plugin-php wsgi_php] application server. uWSGI itself has a wealth of features to limit the resource use, and to harden the security of the application, and by being a separate process it can run under its own user.<br />
<br />
=== Document Root Security ===<br />
<br />
There are a few things you should do to protect your website and data. An important step is to not have your OwnCloud data directory in your document root. However, it is also important not to have OwnCloud itself in your document root.<br />
<br />
Create a sanitized document root in /srv/http<br />
mkdir -p /srv/http/owncloud/core<br />
<br />
Copy the index files and img directory to the document root. You may also need to copy images from your installed apps to the document root for them to be accessible.<br />
cp /usr/share/webapps/owncloud/index.php /srv/http/owncloud<br />
cp /usr/share/webapps/owncloud/index.html /srv/http/owncloud<br />
cp -r /usr/share/webapps/owncloud/core/img /srv/http/owncloud/core<br />
<br />
The following configuration will now use this unprivileged document root. Any URL containing *.php or *.php/ will be directed to uWSGI_PHP. In the uWSGI_PHP config file we will specify the *.php files allowd to run; requests for all other PHP files will return 'Forbidden'. Attempts to access non PHP files that are not in /srv/http/owncloud will return a 404.<br />
<br />
The nginx config is:<br />
{{bc|<nowiki><br />
#this is to avoid Request Entity Too Large error<br />
client_max_body_size 1000M;<br />
# deny access to some special files<br />
location ~ ^/(data|config|\.ht|db_structure\.xml|README) {<br />
deny all;<br />
}<br />
# pass all .php or .php/path urls to uWSGI<br />
location ~ ^(.+\.php)(.*)$ {<br />
include uwsgi_params;<br />
uwsgi_modifier1 14;<br />
uwsgi_pass 127.0.0.1:3001;<br />
}<br />
# everything else goes to the filesystem,<br />
# but / will be mapped to index.php and run through uwsgi<br />
location / {<br />
root /srv/http/owncloud;<br />
index index.php;<br />
rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;<br />
rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;<br />
}<br />
</nowiki>}}<br />
The uWSGI /etc/uwsgi/owncloud.ini config file (run it with uwsgi_php --ini /etc/uwsgi/owncloud.ini):<br />
{{bc|<nowiki><br />
[uwsgi]<br />
socket = 127.0.0.1:3001<br />
master = true<br />
chdir = /srv/http/owncloud<br />
php-docroot = /usr/share/webapps/owncloud<br />
php-index = index.php<br />
<br />
# only allow these php files, I don't want to inadvertently run something else<br />
php-allowed-ext = /index.php<br />
php-allowed-ext = /public.php<br />
php-allowed-ext = /remote.php<br />
php-allowed-ext = /cron.php<br />
#php-allowed-ext = /status.php<br />
php-allowed-ext = /settings/apps.php<br />
php-allowed-ext = /core/ajax/update.php<br />
php-allowed-ext = /core/ajax/share.php<br />
php-allowed-ext = /core/ajax/requesttoken.php<br />
php-allowed-ext = /core/ajax/translations.php<br />
php-allowed-ext = /search/ajax/search.php<br />
php-allowed-ext = /search/templates/part.results.php<br />
php-allowed-ext = /settings/admin.php<br />
php-allowed-ext = /settings/users.php<br />
php-allowed-ext = /settings/personal.php<br />
php-allowed-ext = /settings/help.php<br />
php-allowed-ext = /settings/ajax/getlog.php<br />
php-allowed-ext = /settings/ajax/setlanguage.php<br />
php-allowed-ext = /settings/ajax/setquota.php<br />
php-allowed-ext = /settings/ajax/userlist.php<br />
php-allowed-ext = /settings/ajax/createuser.php<br />
php-allowed-ext = /settings/ajax/removeuser.php<br />
php-allowed-ext = /settings/ajax/enableapp.php<br />
php-allowed-ext = /core/ajax/appconfig.php<br />
<br />
php-set = date.timezone=Etc/UTC<br />
php-set = open_basedir=/srv/http/owncloud:/tmp/:/usr/share/pear/:/usr/share/webapps/owncloud<br />
<br />
processes = 10<br />
cheaper = 2<br />
# Local<br />
cron = -1 -1 -1 -1 -1 /usr/bin/php -f /usr/share/webapps/owncloud/cron.php 1>/dev/null<br />
# Remote<br />
#cron = -1 -1 -1 -1 -1 /usr/bin/curl -g http://localhost/ >>/dev/null<br />
<br />
</nowiki>}}<br />
Finally, a simple systemd unit file to start the uwsgi instance can be (this is without using the emperor):<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=OwnCloud service via uWSGI-PHP<br />
<br />
[Service]<br />
User=http<br />
ExecStart=/usr/bin/uwsgi_php --ini /etc/uwsgi/owncloud.ini<br />
ExecReload=/bin/kill -HUP $MAINPID<br />
KillSignal=SIGQUIT<br />
Restart=always<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Sync Clients ==<br />
<br />
The offical clients can be found in this page : [http://owncloud.org/install/ Sync Clients]<br />
Also take notice that while the offical owncloud android app is a paid app on the play store, it is not a paid app on [https://f-droid.org/ F-Droid].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Self-signed certificate not accepted ===<br />
<br />
OwnCloud uses [[Wikipedia:cURL]] and [[Wikipedia:SabreDAV]] to check if [[WebDAV]] is enabled. If you use a SSL/TLS with a self-signed certificate, e.g. as shown in [[LAMP]] and access ownClouds admin panel, you will see the following error message:<br />
<br />
Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken.<br />
<br />
Assuming that you followed the [[LAMP]]-tutorial, execute the following steps:<br />
<br />
Create local directory for non-distribution certificates and copy [[LAMP]]s certificate there. This will prevent {{Ic|ca-certificates}}-updates to overwrite it.<br />
<br />
$ cp /etc/httpd/conf/server.crt /usr/share/ca-certificates/''WWW.EXAMPLE.COM.crt''<br />
<br />
Add ''WWW.EXAMPLE.COM.crt'' to {{ic|/etc/ca-certificates.conf}}:<br />
<br />
''WWW.EXAMPLE.COM.crt''<br />
<br />
Now, regenerate your certificate store:<br />
<br />
$ update-ca-certificates<br />
<br />
Restart the httpd service to activate your certificate.<br />
<br />
<br />
Should this not work consider disabling mod_curl in /etc/php/php.ini.<br />
<br />
=== Can't create data directory (/path/to/dir) ===<br />
<br />
Check your httpd conf file (like owncloud.conf). Add your data dir to <br />
php_admin_value open_basedir "/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/path/to/dir/"<br />
<br />
You should also modify php.ini in the same way. Restart the httpd service to activate the change.<br />
<br />
=== CSync faild to find a specific file. ===<br />
<br />
Most probably a certificate issue, recreate it, and don't leave the common name empty or you will see the error again.<br />
<br />
openssl genrsa -out server.key 2048<br />
openssl req -new -key server.key -x509 -days 365 -out server.crt<br />
<br />
=== Seeing white page after login ===<br />
<br />
The cause is probably a new app that you installed, to fix that you can either use phpMyAdmin by editing the oc_appconfig table(in the case you got lucky and the table has edit option) or do it by hand with mysql:<br />
<br />
mysql -u root -p owncloud<br />
MariaDB [owncloud]> '''delete from''' oc_appconfig '''where''' appid='<nameOfExtension>' '''and''' configkey='enabled' '''and''' configvalue='yes'<br />
MariaDB [owncloud]> '''insert into''' oc_appconfig (appid,configkey,configvalue) '''values''' ('<nameOfExtension>','enabled','no');<br />
<br />
This should delete the relevant configuration from the table and add it again.<br />
<br />
=== GUI sync client fails to connect ===<br />
<br />
If using HTTP basic auth, make sure to exclude "status.php", which must be publicly accessible [https://github.com/owncloud/mirall/issues/734]<br />
<br />
=== "Can't write into apps directory" ===<br />
As mentioned here, http://doc.owncloud.org/server/6.0/admin_manual/configuration/configuration_apps.html either you need an apps directory that is writable by the http user, or you need to set "appstoreenabled" to false. <br />
<br />
''Also'', not mentioned there, the directory needs to be in the open_basedir line in /etc/php/php.ini<br />
<br />
One clean method is to have the package-installed directory at /usr/share/webapps/owncloud/apps stay owned by root, and have the user-installed apps go into e.g. /var/www/owncloud/apps which is owned by http. Then you can set "appstoreenabled" to true and package upgrades of apps should work fine as well. Relevant lines from /etc/webapps/owncloud/config/config.php:<br />
<pre><br />
'apps_paths' => <br />
array (<br />
0 => <br />
array (<br />
'path' => '/usr/share/webapps/owncloud/apps',<br />
'url' => '/apps',<br />
'writable' => false,<br />
),<br />
1 => <br />
array (<br />
'path' => '/var/www/owncloud/apps',<br />
'url' => '/wapps',<br />
'writable' => true,<br />
),<br />
),<br />
</pre><br />
Example open_basedir line from /etc/php/php.ini (you might have other dirs in there as well):<br />
<pre><br />
open_basedir = /srv/http/:/usr/share/webapps/:/var/www/owncloud/apps/<br />
</pre><br />
<br />
Directory permissions:<br />
<pre><br />
$ ls -ld /usr/share/webapps/owncloud/apps /var/www/owncloud/apps/<br />
drwxr-xr-x 26 root root 4096 des. 14 20:48 /usr/share/webapps/owncloud/apps<br />
drwxr-xr-x 2 http http 48 jan. 20 20:01 /var/www/owncloud/apps/<br />
</pre></div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Nextcloud&diff=295961Nextcloud2014-02-03T03:26:31Z<p>Hunterthomson: /* Nginx + uwsgi_php alternative */ A little less hyperbolic</p>
<hr />
<div>[[Category:Web Server]]<br />
[[fr:Owncloud]]<br />
[[ja:Owncloud]]<br />
From [[Wikipedia:ownCloud|Wikipedia]]:<br />
: ''ownCloud is a software suite that provides a location-independent storage area for data (cloud storage).''<br />
<br />
== Installation ==<br />
<br />
Set up the [[LAMP]] stack. <br />
<br />
You will probably need to install the MDB2 pear package as well. Install {{pkg|php-pear}}, then:<br />
# pear install MDB2<br />
<br />
# [[pacman|Install]] {{Pkg|owncloud}} from the [[official repositories]]. Alternatively see the packages available in the [[Arch User Repository]]: [https://aur.archlinux.org/packages.php?K=owncloud&O=0].<br />
# Copy {{ic|/etc/webapps/owncloud/apache.example.conf}} to {{ic|/etc/httpd/conf/extra/owncloud.conf}} (version 6+)<br />
# Add the following lines into {{ic|/etc/httpd/conf/httpd.conf}} (the php5 line should have already been added during the LAMP stack setup):<br />
Include /etc/httpd/conf/extra/owncloud.conf<br />
LoadModule php5_module modules/libphp5.so<br />
Include conf/extra/php5_module.conf<br />
<br />
Uncomment extensions in {{ic|/etc/php/php.ini}}:<br />
gd.so<br />
intl.so<br />
openssl.so<br />
xmlrpc.so<br />
zip.so<br />
iconv.so<br />
<br />
=== Database support ===<br />
Depending on which database backend you are going to use uncomment either one of the following extensions in {{ic|/etc/php/php.ini}}:<br />
{|border=1 class="wikitable"<br />
!SQLite!!MySQL!!PostgreSQL<br />
|-<br />
|<br />
sqlite.so<br />
sqlite3.so<br />
pdo_sqlite.so<br />
|<br />
mysql.so<br />
mysqli.so<br />
pdo_mysql.so<br />
|<br />
pgsql.so<br />
pdo_pgsql.so<br />
|-<br />
|}<br />
Don't forget to install the appropriate php-module for the database. In the PostgreSQL case thats {{Pkg|php-pgsql}} or for SQLite {{Pkg|php-sqlite}}.<br />
<br />
=== Exif support ===<br />
Additionally install exif support with<br />
# pacman -S exiv2<br />
and uncomment the exif.so extension in php.ini<br />
<br />
=== Disable Webdav ===<br />
Owncloud comes with its own Webdav enabled which conflict. Owncloud [http://forum.owncloud.org/viewtopic.php?f=17&t=7240 recommends] to disable mod_dav and mod_dav_fs. This should be done in {{ic|/etc/httpd/conf/httpd.conf}}<br />
<br />
Now [[Daemons#Restarting|restart]] httpd (Apache)<br />
# systemctl restart httpd<br />
Open [http://localhost http://localhost] in your browser. You should now be able to create a user account and follow the installation wizard.<br />
<br />
== Custom configurations ==<br />
<br />
=== Filesize limitations ===<br />
<br />
With the default configuration ownCloud only allows the upload of filesizes less than 2MB.<br />
This can be changed by changing the following line in {{ic|/etc/php/php.ini}} to your liking.<br />
<br />
'''As of version 4.0 this is no longer necessary! The maximum upload size is now set via the ownCloud gui'''<br />
upload_max_filesize = 2M<br />
<br />
As of version 4.5, upload limits are set in {{ic|/usr/share/webapps/owncloud/.htaccess}}. This won't work if [[LAMP#Using_php5_with_apache2-mpm-worker_and_mod_fcgid|PHP is set up to run as CGI]], so you need to change the limits in {{ic|/etc/php/php.ini}}. You also need to change open_basedir.<br />
{{bc|<nowiki><br />
upload_max_filesize = 512M<br />
post_max_size = 512M<br />
memory_limit = 512M<br />
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/<br />
</nowiki>}}<br />
<br />
=== Running ownCloud in a subdirectory ===<br />
<br />
By including the default '''owncloud.conf''' in '''httpd.conf''', owncloud will take control of port 80 and your localhost domain. If you would like to have owncloud run in a subdirectory, then skip the 'Include /etc/httpd/conf/extra/owncloud.conf' line altogether and just use a symbolic link like so: <br />
# ln -s /usr/share/webapps/owncloud/ /srv/http/<br />
<br />
In that case, you'll also have to ensure /usr/share/webapps is in the open_basedir line of php.ini, and that per-directory .htaccess files are read by apache. <br />
<br />
Alternatively, you could follow the standard procedure, but comment out the VirtualHost part of the include file, and skip the symlink/basedir/htaccess part.<br />
<br />
== Filling ownCloud with data ==<br />
<br />
=== Small files ===<br />
<br />
==== WebDav ====<br />
<br />
Always use [[WebDAV]] or the web interface to add new files to your ownCloud. Otherwise they will not show up correctly, as they do not get indexed right.<br />
No further configuration is necessary to enable [[WebDAV]] uploads in ownCloud. <br />
<br />
Consider installing and enabling [[php-apc]] to speed up WebDAV.<br />
<br />
==== SABnzbd ====<br />
<br />
When using [[SABnzbd]], you might want to set<br />
folder_rename 0<br />
in your sabnzbd.ini file, because ownCloud will scan the files as soon as they get uploaded, preventing SABnzbd from removing UNPACKING prefixes etc.<br />
<br />
=== Big files ===<br />
<br />
WebDAV isn't suitable for big files, because it fills up all the RAM and CPU.<br />
<br />
With the current version, it looks like, there is no good way of copying huge amounts of data to your ownCloud.<br />
<br />
Here's a Workaround:<br />
<br />
Copy the files directly to your ownCloud and do a full re-scan of your database (you could use the [http://apps.owncloud.com/content/show.php?content=151948&forumpage=0&PHPSESSID=37b915160effcc0f37cc761ad2ab88be Re-scan filesystem] add-on for example).<br />
<br />
But beware that this will not work as easily in the future, when end-to-end encryption gets added to ownCloud (this is a planned feature).<br />
<br />
== Important notes ==<br />
<br />
* When using a subdomain (like cloud.example.net), make sure it is covered by your certificate. Otherwise, connection via the owncloud client or webdav might fail.<br />
<br />
* If you are planning on using OwnCloud's [http://owncloud.org/sync-clients/ sync-clients], make sure to have [[NTP]] installed and running on your OwnCloud server, otherwise the sync-clients will fail.<br />
<br />
* Add some [[LAMP#SSL|SSL encryption]] to your connection!<br />
(If adding SSL encryption as above, be sure to edit /etc/httpd/conf/extra/httpd-ssl.conf and change DocumentRoot "/srv/http" to DocumentRoot "/usr/share/webapps/owncloud" )<br />
<br />
* More Apps for ownCloud can be found [http://apps.owncloud.com/ here]<br />
<br />
* To install an new application, download the zip from the apps store, extract it into /srv/http/owncloud/apps/.<br />
Afterwards restart httpd:<br />
<br />
systemctl restart httpd<br />
<br />
log into your server go to the app sections you should see the new apps in there,<br />
<br />
* If you are protecting access to your owncloud location with HTTP basic auth, the file "status.php" must be excluded from auth and be publicly accessible. [https://github.com/owncloud/mirall/issues/734]<br />
<br />
== Nginx + uwsgi_php alternative ==<br />
<br />
You can avoid the use of Apache, and run owncloud in it's own process by using the [https://www.archlinux.org/packages/uwsgi-plugin-php wsgi_php] application server. uWSGI itself has a wealth of features to limit the resource use, and to harden the security of the application, and by being a separate process it can run under its own user.<br />
<br />
=== Document Root Security ===<br />
<br />
There are a few things you should do to protect your website and data. An important step is to not have your OwnCloud data directory in your document root. However, it is also important not to have OwnCloud itself your document root.<br />
<br />
Create a sanitized document root in /srv/http<br />
mkdir -p /srv/http/owncloud/core<br />
<br />
Copy the index files to avoid haveing to type in index.php and so the landing page and public.php images will display.<br />
cp /usr/share/webapps/owncloud/index.php /srv/http/owncloud<br />
cp /usr/share/webapps/owncloud/index.php /srv/http/owncloud<br />
cp -r /usr/share/webapps/owncloud/core/img /srv/http/owncloud/core<br />
<br />
The following configuration will now use this unprivileged document root. Any URL containing *.php or *.php/ will be directed to uWSGI_PHP. In the uWSGI_PHP config file we will specify the *.php files allowd to run; all other will return 'Forbidden'. Attempts to access non PHP files that are not in /srv/http/owncloud will return a 404.<br />
<br />
The nginx config is:<br />
{{bc|<nowiki><br />
#this is to avoid Request Entity Too Large error<br />
client_max_body_size 1000M;<br />
# deny access to some special files<br />
location ~ ^/(data|config|\.ht|db_structure\.xml|README) {<br />
deny all;<br />
}<br />
# pass all .php or .php/path urls to uWSGI<br />
location ~ ^(.+\.php)(.*)$ {<br />
include uwsgi_params;<br />
uwsgi_modifier1 14;<br />
uwsgi_pass 127.0.0.1:3001;<br />
}<br />
# everything else goes to the filesystem,<br />
# but / will be mapped to index.php and run through uwsgi<br />
location / {<br />
root /srv/http/owncloud;<br />
index index.php;<br />
rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;<br />
rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;<br />
}<br />
</nowiki>}}<br />
The uWSGI /etc/uwsgi/owncloud.ini config file (run it with uwsgi_php --ini /etc/uwsgi/owncloud.ini):<br />
{{bc|<nowiki><br />
[uwsgi]<br />
socket = 127.0.0.1:3001<br />
master = true<br />
chdir = /srv/http/owncloud<br />
php-docroot = /usr/share/webapps/owncloud<br />
php-index = index.php<br />
<br />
# only allow these php files, I don't want to inadvertently run something else<br />
php-allowed-ext = /index.php<br />
php-allowed-ext = /public.php<br />
php-allowed-ext = /remote.php<br />
php-allowed-ext = /cron.php<br />
#php-allowed-ext = /status.php<br />
php-allowed-ext = /settings/apps.php<br />
php-allowed-ext = /core/ajax/update.php<br />
php-allowed-ext = /core/ajax/share.php<br />
php-allowed-ext = /core/ajax/requesttoken.php<br />
php-allowed-ext = /core/ajax/translations.php<br />
php-allowed-ext = /search/ajax/search.php<br />
php-allowed-ext = /search/templates/part.results.php<br />
php-allowed-ext = /settings/admin.php<br />
php-allowed-ext = /settings/users.php<br />
php-allowed-ext = /settings/personal.php<br />
php-allowed-ext = /settings/help.php<br />
php-allowed-ext = /settings/ajax/getlog.php<br />
php-allowed-ext = /settings/ajax/setlanguage.php<br />
php-allowed-ext = /settings/ajax/setquota.php<br />
php-allowed-ext = /settings/ajax/userlist.php<br />
php-allowed-ext = /settings/ajax/createuser.php<br />
php-allowed-ext = /settings/ajax/removeuser.php<br />
php-allowed-ext = /settings/ajax/enableapp.php<br />
php-allowed-ext = /core/ajax/appconfig.php<br />
<br />
php-set = date.timezone=Etc/UTC<br />
php-set = open_basedir=/srv/http/owncloud:/tmp/:/usr/share/pear/:/usr/share/webapps/owncloud<br />
<br />
processes = 10<br />
cheaper = 2<br />
# Local<br />
cron = -1 -1 -1 -1 -1 /usr/bin/php -f /usr/share/webapps/owncloud/cron.php 1>/dev/null<br />
# Remote<br />
#cron = -1 -1 -1 -1 -1 /usr/bin/curl -g http://localhost/ >>/dev/null<br />
<br />
</nowiki>}}<br />
Finally, a simple systemd unit file to start the uwsgi instance can be (this is without using the emperor):<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=OwnCloud service via uWSGI-PHP<br />
<br />
[Service]<br />
User=http<br />
ExecStart=/usr/bin/uwsgi_php --ini /etc/uwsgi/owncloud.ini<br />
ExecReload=/bin/kill -HUP $MAINPID<br />
KillSignal=SIGQUIT<br />
Restart=always<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Sync Clients ==<br />
<br />
The offical clients can be found in this page : [http://owncloud.org/install/ Sync Clients]<br />
Also take notice that while the offical owncloud android app is a paid app on the play store, it is not a paid app on [https://f-droid.org/ F-Droid].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Self-signed certificate not accepted ===<br />
<br />
OwnCloud uses [[Wikipedia:cURL]] and [[Wikipedia:SabreDAV]] to check if [[WebDAV]] is enabled. If you use a SSL/TLS with a self-signed certificate, e.g. as shown in [[LAMP]] and access ownClouds admin panel, you will see the following error message:<br />
<br />
Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken.<br />
<br />
Assuming that you followed the [[LAMP]]-tutorial, execute the following steps:<br />
<br />
Create local directory for non-distribution certificates and copy [[LAMP]]s certificate there. This will prevent {{Ic|ca-certificates}}-updates to overwrite it.<br />
<br />
$ cp /etc/httpd/conf/server.crt /usr/share/ca-certificates/''WWW.EXAMPLE.COM.crt''<br />
<br />
Add ''WWW.EXAMPLE.COM.crt'' to {{ic|/etc/ca-certificates.conf}}:<br />
<br />
''WWW.EXAMPLE.COM.crt''<br />
<br />
Now, regenerate your certificate store:<br />
<br />
$ update-ca-certificates<br />
<br />
Restart the httpd service to activate your certificate.<br />
<br />
<br />
Should this not work consider disabling mod_curl in /etc/php/php.ini.<br />
<br />
=== Can't create data directory (/path/to/dir) ===<br />
<br />
Check your httpd conf file (like owncloud.conf). Add your data dir to <br />
php_admin_value open_basedir "/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/path/to/dir/"<br />
<br />
You should also modify php.ini in the same way. Restart the httpd service to activate the change.<br />
<br />
=== CSync faild to find a specific file. ===<br />
<br />
Most probably a certificate issue, recreate it, and don't leave the common name empty or you will see the error again.<br />
<br />
openssl genrsa -out server.key 2048<br />
openssl req -new -key server.key -x509 -days 365 -out server.crt<br />
<br />
=== Seeing white page after login ===<br />
<br />
The cause is probably a new app that you installed, to fix that you can either use phpMyAdmin by editing the oc_appconfig table(in the case you got lucky and the table has edit option) or do it by hand with mysql:<br />
<br />
mysql -u root -p owncloud<br />
MariaDB [owncloud]> '''delete from''' oc_appconfig '''where''' appid='<nameOfExtension>' '''and''' configkey='enabled' '''and''' configvalue='yes'<br />
MariaDB [owncloud]> '''insert into''' oc_appconfig (appid,configkey,configvalue) '''values''' ('<nameOfExtension>','enabled','no');<br />
<br />
This should delete the relevant configuration from the table and add it again.<br />
<br />
=== GUI sync client fails to connect ===<br />
<br />
If using HTTP basic auth, make sure to exclude "status.php", which must be publicly accessible [https://github.com/owncloud/mirall/issues/734]<br />
<br />
=== "Can't write into apps directory" ===<br />
As mentioned here, http://doc.owncloud.org/server/6.0/admin_manual/configuration/configuration_apps.html either you need an apps directory that is writable by the http user, or you need to set "appstoreenabled" to false. <br />
<br />
''Also'', not mentioned there, the directory needs to be in the open_basedir line in /etc/php/php.ini<br />
<br />
One clean method is to have the package-installed directory at /usr/share/webapps/owncloud/apps stay owned by root, and have the user-installed apps go into e.g. /var/www/owncloud/apps which is owned by http. Then you can set "appstoreenabled" to true and package upgrades of apps should work fine as well. Relevant lines from /etc/webapps/owncloud/config/config.php:<br />
<pre><br />
'apps_paths' => <br />
array (<br />
0 => <br />
array (<br />
'path' => '/usr/share/webapps/owncloud/apps',<br />
'url' => '/apps',<br />
'writable' => false,<br />
),<br />
1 => <br />
array (<br />
'path' => '/var/www/owncloud/apps',<br />
'url' => '/wapps',<br />
'writable' => true,<br />
),<br />
),<br />
</pre><br />
Example open_basedir line from /etc/php/php.ini (you might have other dirs in there as well):<br />
<pre><br />
open_basedir = /srv/http/:/usr/share/webapps/:/var/www/owncloud/apps/<br />
</pre><br />
<br />
Directory permissions:<br />
<pre><br />
$ ls -ld /usr/share/webapps/owncloud/apps /var/www/owncloud/apps/<br />
drwxr-xr-x 26 root root 4096 des. 14 20:48 /usr/share/webapps/owncloud/apps<br />
drwxr-xr-x 2 http http 48 jan. 20 20:01 /var/www/owncloud/apps/<br />
</pre></div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Nextcloud&diff=295913Nextcloud2014-02-02T15:15:47Z<p>Hunterthomson: /* Nginx + uwsgi_php alternative */ Critical Security Change. DO NOT put OwnCloud webapp in the document root of Nginx</p>
<hr />
<div>[[Category:Web Server]]<br />
[[fr:Owncloud]]<br />
[[ja:Owncloud]]<br />
From [[Wikipedia:ownCloud|Wikipedia]]:<br />
: ''ownCloud is a software suite that provides a location-independent storage area for data (cloud storage).''<br />
<br />
== Installation ==<br />
<br />
Set up the [[LAMP]] stack. <br />
<br />
You will probably need to install the MDB2 pear package as well. Install {{pkg|php-pear}}, then:<br />
# pear install MDB2<br />
<br />
# [[pacman|Install]] {{Pkg|owncloud}} from the [[official repositories]]. Alternatively see the packages available in the [[Arch User Repository]]: [https://aur.archlinux.org/packages.php?K=owncloud&O=0].<br />
# Copy {{ic|/etc/webapps/owncloud/apache.example.conf}} to {{ic|/etc/httpd/conf/extra/owncloud.conf}} (version 6+)<br />
# Add the following lines into {{ic|/etc/httpd/conf/httpd.conf}} (the php5 line should have already been added during the LAMP stack setup):<br />
Include /etc/httpd/conf/extra/owncloud.conf<br />
LoadModule php5_module modules/libphp5.so<br />
Include conf/extra/php5_module.conf<br />
<br />
Uncomment extensions in {{ic|/etc/php/php.ini}}:<br />
gd.so<br />
intl.so<br />
openssl.so<br />
xmlrpc.so<br />
zip.so<br />
iconv.so<br />
<br />
=== Database support ===<br />
Depending on which database backend you are going to use uncomment either one of the following extensions in {{ic|/etc/php/php.ini}}:<br />
{|border=1 class="wikitable"<br />
!SQLite!!MySQL!!PostgreSQL<br />
|-<br />
|<br />
sqlite.so<br />
sqlite3.so<br />
pdo_sqlite.so<br />
|<br />
mysql.so<br />
mysqli.so<br />
pdo_mysql.so<br />
|<br />
pgsql.so<br />
pdo_pgsql.so<br />
|-<br />
|}<br />
Don't forget to install the appropriate php-module for the database. In the PostgreSQL case thats {{Pkg|php-pgsql}} or for SQLite {{Pkg|php-sqlite}}.<br />
<br />
=== Exif support ===<br />
Additionally install exif support with<br />
# pacman -S exiv2<br />
and uncomment the exif.so extension in php.ini<br />
<br />
=== Disable Webdav ===<br />
Owncloud comes with its own Webdav enabled which conflict. Owncloud [http://forum.owncloud.org/viewtopic.php?f=17&t=7240 recommends] to disable mod_dav and mod_dav_fs. This should be done in {{ic|/etc/httpd/conf/httpd.conf}}<br />
<br />
Now [[Daemons#Restarting|restart]] httpd (Apache)<br />
# systemctl restart httpd<br />
Open [http://localhost http://localhost] in your browser. You should now be able to create a user account and follow the installation wizard.<br />
<br />
== Custom configurations ==<br />
<br />
=== Filesize limitations ===<br />
<br />
With the default configuration ownCloud only allows the upload of filesizes less than 2MB.<br />
This can be changed by changing the following line in {{ic|/etc/php/php.ini}} to your liking.<br />
<br />
'''As of version 4.0 this is no longer necessary! The maximum upload size is now set via the ownCloud gui'''<br />
upload_max_filesize = 2M<br />
<br />
As of version 4.5, upload limits are set in {{ic|/usr/share/webapps/owncloud/.htaccess}}. This won't work if [[LAMP#Using_php5_with_apache2-mpm-worker_and_mod_fcgid|PHP is set up to run as CGI]], so you need to change the limits in {{ic|/etc/php/php.ini}}. You also need to change open_basedir.<br />
{{bc|<nowiki><br />
upload_max_filesize = 512M<br />
post_max_size = 512M<br />
memory_limit = 512M<br />
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/<br />
</nowiki>}}<br />
<br />
=== Running ownCloud in a subdirectory ===<br />
<br />
By including the default '''owncloud.conf''' in '''httpd.conf''', owncloud will take control of port 80 and your localhost domain. If you would like to have owncloud run in a subdirectory, then skip the 'Include /etc/httpd/conf/extra/owncloud.conf' line altogether and just use a symbolic link like so: <br />
# ln -s /usr/share/webapps/owncloud/ /srv/http/<br />
<br />
In that case, you'll also have to ensure /usr/share/webapps is in the open_basedir line of php.ini, and that per-directory .htaccess files are read by apache. <br />
<br />
Alternatively, you could follow the standard procedure, but comment out the VirtualHost part of the include file, and skip the symlink/basedir/htaccess part.<br />
<br />
== Filling ownCloud with data ==<br />
<br />
=== Small files ===<br />
<br />
==== WebDav ====<br />
<br />
Always use [[WebDAV]] or the web interface to add new files to your ownCloud. Otherwise they will not show up correctly, as they do not get indexed right.<br />
No further configuration is necessary to enable [[WebDAV]] uploads in ownCloud. <br />
<br />
Consider installing and enabling [[php-apc]] to speed up WebDAV.<br />
<br />
==== SABnzbd ====<br />
<br />
When using [[SABnzbd]], you might want to set<br />
folder_rename 0<br />
in your sabnzbd.ini file, because ownCloud will scan the files as soon as they get uploaded, preventing SABnzbd from removing UNPACKING prefixes etc.<br />
<br />
=== Big files ===<br />
<br />
WebDAV isn't suitable for big files, because it fills up all the RAM and CPU.<br />
<br />
With the current version, it looks like, there is no good way of copying huge amounts of data to your ownCloud.<br />
<br />
Here's a Workaround:<br />
<br />
Copy the files directly to your ownCloud and do a full re-scan of your database (you could use the [http://apps.owncloud.com/content/show.php?content=151948&forumpage=0&PHPSESSID=37b915160effcc0f37cc761ad2ab88be Re-scan filesystem] add-on for example).<br />
<br />
But beware that this will not work as easily in the future, when end-to-end encryption gets added to ownCloud (this is a planned feature).<br />
<br />
== Important notes ==<br />
<br />
* When using a subdomain (like cloud.example.net), make sure it is covered by your certificate. Otherwise, connection via the owncloud client or webdav might fail.<br />
<br />
* If you are planning on using OwnCloud's [http://owncloud.org/sync-clients/ sync-clients], make sure to have [[NTP]] installed and running on your OwnCloud server, otherwise the sync-clients will fail.<br />
<br />
* Add some [[LAMP#SSL|SSL encryption]] to your connection!<br />
(If adding SSL encryption as above, be sure to edit /etc/httpd/conf/extra/httpd-ssl.conf and change DocumentRoot "/srv/http" to DocumentRoot "/usr/share/webapps/owncloud" )<br />
<br />
* More Apps for ownCloud can be found [http://apps.owncloud.com/ here]<br />
<br />
* To install an new application, download the zip from the apps store, extract it into /srv/http/owncloud/apps/.<br />
Afterwards restart httpd:<br />
<br />
systemctl restart httpd<br />
<br />
log into your server go to the app sections you should see the new apps in there,<br />
<br />
* If you are protecting access to your owncloud location with HTTP basic auth, the file "status.php" must be excluded from auth and be publicly accessible. [https://github.com/owncloud/mirall/issues/734]<br />
<br />
== Nginx + uwsgi_php alternative ==<br />
<br />
You can avoid the use of Apache, and run owncloud in it's own process by using the [https://www.archlinux.org/packages/uwsgi-plugin-php wsgi_php] application server. uWSGI itself has a wealth of features to limit the resource use, and to harden the security of the application, and by being a separate process it can run under its own user.<br />
<br />
=== Basic Document Root Security ===<br />
<br />
There are a few things you should do to protect your website and data. An important step is to not have your OwnCloud data directory in your document root. However, it is also important not to have OwnCloud itself your document root.<br />
<br />
Create a sanitized document root in /srv/http<br />
mkdir -p /srv/http/owncloud/core<br />
<br />
Copy the index files to avoid haveing to type in index.php and so the landing page and public.php images will display.<br />
cp /usr/share/webapps/owncloud/index.php /srv/http/owncloud<br />
cp /usr/share/webapps/owncloud/index.php /srv/http/owncloud<br />
cp -r /usr/share/webapps/owncloud/core/img /srv/http/owncloud/core<br />
<br />
The following configuration will now use this unprivileged document root. Any URL containing *.php or *.php/ will be directed to uWSGI_PHP. In the uWSGI_PHP config file we will specify the *.php files allowd to run; all other will return 'Forbidden'. Attempts to access non PHP files that are not in /srv/http/owncloud will return a 404.<br />
<br />
The nginx config is:<br />
{{bc|<nowiki><br />
#this is to avoid Request Entity Too Large error<br />
client_max_body_size 1000M;<br />
# deny access to some special files<br />
location ~ ^/(data|config|\.ht|db_structure\.xml|README) {<br />
deny all;<br />
}<br />
# pass all .php or .php/path urls to uWSGI<br />
location ~ ^(.+\.php)(.*)$ {<br />
include uwsgi_params;<br />
uwsgi_modifier1 14;<br />
uwsgi_pass 127.0.0.1:3001;<br />
}<br />
# everything else goes to the filesystem,<br />
# but / will be mapped to index.php and run through uwsgi<br />
location / {<br />
root /srv/http/owncloud;<br />
index index.php;<br />
rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;<br />
rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;<br />
}<br />
</nowiki>}}<br />
The uWSGI /etc/uwsgi/owncloud.ini config file (run it with uwsgi_php --ini /etc/uwsgi/owncloud.ini):<br />
{{bc|<nowiki><br />
[uwsgi]<br />
socket = 127.0.0.1:3001<br />
master = true<br />
chdir = /srv/http/owncloud<br />
php-docroot = /usr/share/webapps/owncloud<br />
php-index = index.php<br />
<br />
# only allow these php files, I don't want to inadvertently run something else<br />
php-allowed-ext = /index.php<br />
php-allowed-ext = /public.php<br />
php-allowed-ext = /remote.php<br />
php-allowed-ext = /cron.php<br />
#php-allowed-ext = /status.php<br />
php-allowed-ext = /settings/apps.php<br />
php-allowed-ext = /core/ajax/update.php<br />
php-allowed-ext = /core/ajax/share.php<br />
php-allowed-ext = /core/ajax/requesttoken.php<br />
php-allowed-ext = /core/ajax/translations.php<br />
php-allowed-ext = /search/ajax/search.php<br />
php-allowed-ext = /search/templates/part.results.php<br />
php-allowed-ext = /settings/admin.php<br />
php-allowed-ext = /settings/users.php<br />
php-allowed-ext = /settings/personal.php<br />
php-allowed-ext = /settings/help.php<br />
php-allowed-ext = /settings/ajax/getlog.php<br />
php-allowed-ext = /settings/ajax/setlanguage.php<br />
php-allowed-ext = /settings/ajax/setquota.php<br />
php-allowed-ext = /settings/ajax/userlist.php<br />
php-allowed-ext = /settings/ajax/createuser.php<br />
php-allowed-ext = /settings/ajax/removeuser.php<br />
php-allowed-ext = /settings/ajax/enableapp.php<br />
php-allowed-ext = /core/ajax/appconfig.php<br />
<br />
php-set = date.timezone=Etc/UTC<br />
php-set = open_basedir=/srv/http/owncloud:/tmp/:/usr/share/pear/:/usr/share/webapps/owncloud<br />
<br />
processes = 10<br />
cheaper = 2<br />
# Local<br />
cron = -1 -1 -1 -1 -1 /usr/bin/php -f /usr/share/webapps/owncloud/cron.php 1>/dev/null<br />
# Remote<br />
#cron = -1 -1 -1 -1 -1 /usr/bin/curl -g http://localhost/ >>/dev/null<br />
<br />
</nowiki>}}<br />
Finally, a simple systemd unit file to start the uwsgi instance can be (this is without using the emperor):<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=OwnCloud service via uWSGI-PHP<br />
<br />
[Service]<br />
User=http<br />
ExecStart=/usr/bin/uwsgi_php --ini /etc/uwsgi/owncloud.ini<br />
ExecReload=/bin/kill -HUP $MAINPID<br />
KillSignal=SIGQUIT<br />
Restart=always<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Sync Clients ==<br />
<br />
The offical clients can be found in this page : [http://owncloud.org/install/ Sync Clients]<br />
Also take notice that while the offical owncloud android app is a paid app on the play store, it is not a paid app on [https://f-droid.org/ F-Droid].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Self-signed certificate not accepted ===<br />
<br />
OwnCloud uses [[Wikipedia:cURL]] and [[Wikipedia:SabreDAV]] to check if [[WebDAV]] is enabled. If you use a SSL/TLS with a self-signed certificate, e.g. as shown in [[LAMP]] and access ownClouds admin panel, you will see the following error message:<br />
<br />
Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken.<br />
<br />
Assuming that you followed the [[LAMP]]-tutorial, execute the following steps:<br />
<br />
Create local directory for non-distribution certificates and copy [[LAMP]]s certificate there. This will prevent {{Ic|ca-certificates}}-updates to overwrite it.<br />
<br />
$ cp /etc/httpd/conf/server.crt /usr/share/ca-certificates/''WWW.EXAMPLE.COM.crt''<br />
<br />
Add ''WWW.EXAMPLE.COM.crt'' to {{ic|/etc/ca-certificates.conf}}:<br />
<br />
''WWW.EXAMPLE.COM.crt''<br />
<br />
Now, regenerate your certificate store:<br />
<br />
$ update-ca-certificates<br />
<br />
Restart the httpd service to activate your certificate.<br />
<br />
<br />
Should this not work consider disabling mod_curl in /etc/php/php.ini.<br />
<br />
=== Can't create data directory (/path/to/dir) ===<br />
<br />
Check your httpd conf file (like owncloud.conf). Add your data dir to <br />
php_admin_value open_basedir "/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/path/to/dir/"<br />
<br />
You should also modify php.ini in the same way. Restart the httpd service to activate the change.<br />
<br />
=== CSync faild to find a specific file. ===<br />
<br />
Most probably a certificate issue, recreate it, and don't leave the common name empty or you will see the error again.<br />
<br />
openssl genrsa -out server.key 2048<br />
openssl req -new -key server.key -x509 -days 365 -out server.crt<br />
<br />
=== Seeing white page after login ===<br />
<br />
The cause is probably a new app that you installed, to fix that you can either use phpMyAdmin by editing the oc_appconfig table(in the case you got lucky and the table has edit option) or do it by hand with mysql:<br />
<br />
mysql -u root -p owncloud<br />
MariaDB [owncloud]> '''delete from''' oc_appconfig '''where''' appid='<nameOfExtension>' '''and''' configkey='enabled' '''and''' configvalue='yes'<br />
MariaDB [owncloud]> '''insert into''' oc_appconfig (appid,configkey,configvalue) '''values''' ('<nameOfExtension>','enabled','no');<br />
<br />
This should delete the relevant configuration from the table and add it again.<br />
<br />
=== GUI sync client fails to connect ===<br />
<br />
If using HTTP basic auth, make sure to exclude "status.php", which must be publicly accessible [https://github.com/owncloud/mirall/issues/734]<br />
<br />
=== "Can't write into apps directory" ===<br />
As mentioned here, http://doc.owncloud.org/server/6.0/admin_manual/configuration/configuration_apps.html either you need an apps directory that is writable by the http user, or you need to set "appstoreenabled" to false. <br />
<br />
''Also'', not mentioned there, the directory needs to be in the open_basedir line in /etc/php/php.ini<br />
<br />
One clean method is to have the package-installed directory at /usr/share/webapps/owncloud/apps stay owned by root, and have the user-installed apps go into e.g. /var/www/owncloud/apps which is owned by http. Then you can set "appstoreenabled" to true and package upgrades of apps should work fine as well. Relevant lines from /etc/webapps/owncloud/config/config.php:<br />
<pre><br />
'apps_paths' => <br />
array (<br />
0 => <br />
array (<br />
'path' => '/usr/share/webapps/owncloud/apps',<br />
'url' => '/apps',<br />
'writable' => false,<br />
),<br />
1 => <br />
array (<br />
'path' => '/var/www/owncloud/apps',<br />
'url' => '/wapps',<br />
'writable' => true,<br />
),<br />
),<br />
</pre><br />
Example open_basedir line from /etc/php/php.ini (you might have other dirs in there as well):<br />
<pre><br />
open_basedir = /srv/http/:/usr/share/webapps/:/var/www/owncloud/apps/<br />
</pre><br />
<br />
Directory permissions:<br />
<pre><br />
$ ls -ld /usr/share/webapps/owncloud/apps /var/www/owncloud/apps/<br />
drwxr-xr-x 26 root root 4096 des. 14 20:48 /usr/share/webapps/owncloud/apps<br />
drwxr-xr-x 2 http http 48 jan. 20 20:01 /var/www/owncloud/apps/<br />
</pre></div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Nextcloud&diff=294879Nextcloud2014-01-29T10:06:43Z<p>Hunterthomson: /* Nginx + uwsgi_php alternative */ typo</p>
<hr />
<div>[[Category:Web Server]]<br />
[[fr:Owncloud]]<br />
[[ja:Owncloud]]<br />
From [[Wikipedia:ownCloud|Wikipedia]]:<br />
: ''ownCloud is a software suite that provides a location-independent storage area for data (cloud storage).''<br />
<br />
== Installation ==<br />
<br />
Set up the [[LAMP]] stack. <br />
<br />
You will probably need to install the MDB2 pear package as well. Install {{pkg|php-pear}}, then:<br />
# pear install MDB2<br />
<br />
# [[pacman|Install]] {{Pkg|owncloud}} from the [[official repositories]]. Alternatively see the packages available in the [[Arch User Repository]]: [https://aur.archlinux.org/packages.php?K=owncloud&O=0].<br />
# Copy {{ic|/etc/webapps/owncloud/apache.example.conf}} to {{ic|/etc/httpd/conf/extra/owncloud.conf}} (version 6+)<br />
# Add the following lines into {{ic|/etc/httpd/conf/httpd.conf}} (the php5 line should have already been added during the LAMP stack setup):<br />
Include /etc/httpd/conf/extra/owncloud.conf<br />
LoadModule php5_module modules/libphp5.so<br />
Include conf/extra/php5_module.conf<br />
<br />
Uncomment extensions in {{ic|/etc/php/php.ini}}:<br />
gd.so<br />
intl.so<br />
openssl.so<br />
xmlrpc.so<br />
zip.so<br />
iconv.so<br />
<br />
=== Database support ===<br />
Depending on which database backend you are going to use uncomment either one of the following extensions in {{ic|/etc/php/php.ini}}:<br />
{|border=1 class="wikitable"<br />
!SQLite!!MySQL!!PostgreSQL<br />
|-<br />
|<br />
sqlite.so<br />
sqlite3.so<br />
pdo_sqlite.so<br />
|<br />
mysql.so<br />
mysqli.so<br />
pdo_mysql.so<br />
|<br />
pgsql.so<br />
pdo_pgsql.so<br />
|-<br />
|}<br />
Don't forget to install the appropriate php-module for the database. In the PostgreSQL case thats {{Pkg|php-pgsql}} or for SQLite {{Pkg|php-sqlite}}.<br />
<br />
=== Exif support ===<br />
Additionally install exif support with<br />
# pacman -S exiv2<br />
and uncomment the exif.so extension in php.ini<br />
<br />
=== Disable Webdav ===<br />
Owncloud comes with its own Webdav enabled which conflict. Owncloud [http://forum.owncloud.org/viewtopic.php?f=17&t=7240 recommends] to disable mod_dav and mod_dav_fs. This should be done in {{ic|/etc/httpd/conf/httpd.conf}}<br />
<br />
Now [[Daemons#Restarting|restart]] httpd (Apache)<br />
# systemctl restart httpd<br />
Open [http://localhost http://localhost] in your browser. You should now be able to create a user account and follow the installation wizard.<br />
<br />
== Custom configurations ==<br />
<br />
=== Filesize limitations ===<br />
<br />
With the default configuration ownCloud only allows the upload of filesizes less than 2MB.<br />
This can be changed by changing the following line in {{ic|/etc/php/php.ini}} to your liking.<br />
<br />
'''As of version 4.0 this is no longer necessary! The maximum upload size is now set via the ownCloud gui'''<br />
upload_max_filesize = 2M<br />
<br />
As of version 4.5, upload limits are set in {{ic|/usr/share/webapps/owncloud/.htaccess}}. This won't work if [[LAMP#Using_php5_with_apache2-mpm-worker_and_mod_fcgid|PHP is set up to run as CGI]], so you need to change the limits in {{ic|/etc/php/php.ini}}. You also need to change open_basedir.<br />
{{bc|<nowiki><br />
upload_max_filesize = 512M<br />
post_max_size = 512M<br />
memory_limit = 512M<br />
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/<br />
</nowiki>}}<br />
<br />
=== Running ownCloud in a subdirectory ===<br />
<br />
By including the default '''owncloud.conf''' in '''httpd.conf''', owncloud will take control of port 80 and your localhost domain. If you would like to have owncloud run in a subdirectory, then skip the 'Include /etc/httpd/conf/extra/owncloud.conf' line altogether and just use a symbolic link like so: <br />
# ln -s /usr/share/webapps/owncloud/ /srv/http/<br />
<br />
In that case, you'll also have to ensure /usr/share/webapps is in the open_basedir line of php.ini, and that per-directory .htaccess files are read by apache. <br />
<br />
Alternatively, you could follow the standard procedure, but comment out the VirtualHost part of the include file, and skip the symlink/basedir/htaccess part.<br />
<br />
== Filling ownCloud with data ==<br />
<br />
=== Small files ===<br />
<br />
==== WebDav ====<br />
<br />
Always use [[WebDAV]] or the web interface to add new files to your ownCloud. Otherwise they will not show up correctly, as they do not get indexed right.<br />
No further configuration is necessary to enable [[WebDAV]] uploads in ownCloud. <br />
<br />
Consider installing and enabling [[php-apc]] to speed up WebDAV.<br />
<br />
==== SABnzbd ====<br />
<br />
When using [[SABnzbd]], you might want to set<br />
folder_rename 0<br />
in your sabnzbd.ini file, because ownCloud will scan the files as soon as they get uploaded, preventing SABnzbd from removing UNPACKING prefixes etc.<br />
<br />
=== Big files ===<br />
<br />
WebDAV isn't suitable for big files, because it fills up all the RAM and CPU.<br />
<br />
With the current version, it looks like, there is no good way of copying huge amounts of data to your ownCloud.<br />
<br />
Here's a Workaround:<br />
<br />
Copy the files directly to your ownCloud and do a full re-scan of your database (you could use the [http://apps.owncloud.com/content/show.php?content=151948&forumpage=0&PHPSESSID=37b915160effcc0f37cc761ad2ab88be Re-scan filesystem] add-on for example).<br />
<br />
But beware that this will not work as easily in the future, when end-to-end encryption gets added to ownCloud (this is a planned feature).<br />
<br />
== Important notes ==<br />
<br />
* When using a subdomain (like cloud.example.net), make sure it is covered by your certificate. Otherwise, connection via the owncloud client or webdav might fail.<br />
<br />
* If you are planning on using OwnCloud's [http://owncloud.org/sync-clients/ sync-clients], make sure to have [[NTP]] installed and running on your OwnCloud server, otherwise the sync-clients will fail.<br />
<br />
* Add some [[LAMP#SSL|SSL encryption]] to your connection!<br />
(If adding SSL encryption as above, be sure to edit /etc/httpd/conf/extra/httpd-ssl.conf and change DocumentRoot "/srv/http" to DocumentRoot "/usr/share/webapps/owncloud" )<br />
<br />
* More Apps for ownCloud can be found [http://apps.owncloud.com/ here]<br />
<br />
* To install an new application, download the zip from the apps store, extract it into /srv/http/owncloud/apps/.<br />
Afterwards restart httpd:<br />
<br />
systemctl restart httpd<br />
<br />
log into your server go to the app sections you should see the new apps in there,<br />
<br />
* If you are protecting access to your owncloud location with HTTP basic auth, the file "status.php" must be excluded from auth and be publicly accessible. [https://github.com/owncloud/mirall/issues/734]<br />
<br />
== Nginx + uwsgi_php alternative ==<br />
<br />
You can avoid the use of Apache, and run owncloud in it's own process by using the [https://www.archlinux.org/packages/uwsgi-plugin-php wsgi_php] application server. uWSGI itself has a wealth of features to limit the resource use, and to harden the security of the application, and by being a separate process it can run under its own user.<br />
<br />
The nginx config is:<br />
{{bc|<nowiki><br />
#this is to avoid Request Entity Too Large error<br />
client_max_body_size 1000M;<br />
# deny access to some special files<br />
location ~ ^/(data|config|\.ht|db_structure\.xml|README) {<br />
deny all;<br />
}<br />
# pass all .php or .php/path urls to uWSGI<br />
location ~ ^(.+\.php)(.*)$ {<br />
include uwsgi_params;<br />
uwsgi_modifier1 14;<br />
uwsgi_pass 127.0.0.1:3001;<br />
}<br />
# everything else goes to the filesystem,<br />
# but / will be mapped to index.php and run through uwsgi<br />
location / {<br />
root /usr/share/webapps/owncloud;<br />
index index.php;<br />
rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;<br />
rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;<br />
}<br />
</nowiki>}}<br />
The uWSGI /etc/uwsgi/owncloud.ini config file (run it with uwsgi_php --ini /etc/uwsgi/owncloud.ini):<br />
{{bc|<nowiki><br />
[uwsgi]<br />
socket = 127.0.0.1:3001<br />
master = true<br />
chdir = /srv/http/owncloud<br />
php-docroot = /usr/share/webapps/owncloud<br />
php-index = index.php<br />
<br />
# only allow these php files, I don't want to inadvertently run something else<br />
php-allowed-ext = /index.php<br />
php-allowed-ext = /public.php<br />
php-allowed-ext = /remote.php<br />
php-allowed-ext = /cron.php<br />
php-allowed-ext = /status.php<br />
php-allowed-ext = /settings/apps.php<br />
php-allowed-ext = /core/ajax/update.php<br />
php-allowed-ext = /core/ajax/share.php<br />
php-allowed-ext = /core/ajax/requesttoken.php<br />
php-allowed-ext = /core/ajax/translations.php<br />
php-allowed-ext = /search/ajax/search.php<br />
php-allowed-ext = /search/templates/part.results.php<br />
php-allowed-ext = /settings/admin.php<br />
php-allowed-ext = /settings/users.php<br />
php-allowed-ext = /settings/personal.php<br />
php-allowed-ext = /settings/help.php<br />
php-allowed-ext = /settings/ajax/getlog.php<br />
php-allowed-ext = /settings/ajax/setlanguage.php<br />
php-allowed-ext = /settings/ajax/setquota.php<br />
php-allowed-ext = /settings/ajax/userlist.php<br />
php-allowed-ext = /settings/ajax/createuser.php<br />
php-allowed-ext = /settings/ajax/removeuser.php<br />
php-allowed-ext = /settings/ajax/enableapp.php<br />
php-allowed-ext = /core/ajax/appconfig.php<br />
<br />
php-set = date.timezone=Europe/Skopje<br />
php-set = open_basedir=/srv/http/owncloud:/tmp/:/usr/share/pear/:/usr/share/webapps/owncloud<br />
<br />
processes = 10<br />
cheaper = 2<br />
# Local<br />
cron = -1 -1 -1 -1 -1 /usr/bin/php -f /usr/share/webapps/owncloud/cron.php 1>/dev/null<br />
# Remote<br />
#cron = -1 -1 -1 -1 -1 /usr/bin/curl -g http://localhost/ >>/dev/null<br />
<br />
</nowiki>}}<br />
Finally, a simple systemd unit file to start the uwsgi instance can be (this is without using the emperor):<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=OwnCloud service via uWSGI-PHP<br />
<br />
[Service]<br />
User=http<br />
ExecStart=/usr/bin/uwsgi_php --ini /etc/uwsgi/owncloud.ini<br />
ExecReload=/bin/kill -HUP $MAINPID<br />
KillSignal=SIGQUIT<br />
Restart=always<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Sync Clients ==<br />
<br />
The offical clients can be found in this page : [http://owncloud.org/install/ Sync Clients]<br />
Also take notice that while the offical owncloud android app is a paid app on the play store, it is not a paid app on [https://f-droid.org/ F-Droid].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Self-signed certificate not accepted ===<br />
<br />
OwnCloud uses [[Wikipedia:cURL]] and [[Wikipedia:SabreDAV]] to check if [[WebDAV]] is enabled. If you use a SSL/TLS with a self-signed certificate, e.g. as shown in [[LAMP]] and access ownClouds admin panel, you will see the following error message:<br />
<br />
Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken.<br />
<br />
Assuming that you followed the [[LAMP]]-tutorial, execute the following steps:<br />
<br />
Create local directory for non-distribution certificates and copy [[LAMP]]s certificate there. This will prevent {{Ic|ca-certificates}}-updates to overwrite it.<br />
<br />
$ cp /etc/httpd/conf/server.crt /usr/share/ca-certificates/''WWW.EXAMPLE.COM.crt''<br />
<br />
Add ''WWW.EXAMPLE.COM.crt'' to {{ic|/etc/ca-certificates.conf}}:<br />
<br />
''WWW.EXAMPLE.COM.crt''<br />
<br />
Now, regenerate your certificate store:<br />
<br />
$ update-ca-certificates<br />
<br />
Restart the httpd service to activate your certificate.<br />
<br />
<br />
Should this not work consider disabling mod_curl in /etc/php/php.ini.<br />
<br />
=== Can't create data directory (/path/to/dir) ===<br />
<br />
Check your httpd conf file (like owncloud.conf). Add your data dir to <br />
php_admin_value open_basedir "/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/path/to/dir/"<br />
<br />
You should also modify php.ini in the same way. Restart the httpd service to activate the change.<br />
<br />
=== CSync faild to find a specific file. ===<br />
<br />
Most probably a certificate issue, recreate it, and don't leave the common name empty or you will see the error again.<br />
<br />
openssl genrsa -out server.key 2048<br />
openssl req -new -key server.key -x509 -days 365 -out server.crt<br />
<br />
=== Seeing white page after login ===<br />
<br />
The cause is probably a new app that you installed, to fix that you can either use phpMyAdmin by editing the oc_appconfig table(in the case you got lucky and the table has edit option) or do it by hand with mysql:<br />
<br />
mysql -u root -p owncloud<br />
MariaDB [owncloud]> '''delete from''' oc_appconfig '''where''' appid='<nameOfExtension>' '''and''' configkey='enabled' '''and''' configvalue='yes'<br />
MariaDB [owncloud]> '''insert into''' oc_appconfig (appid,configkey,configvalue) '''values''' ('<nameOfExtension>','enabled','no');<br />
<br />
This should delete the relevant configuration from the table and add it again.<br />
<br />
=== GUI sync client fails to connect ===<br />
<br />
If using HTTP basic auth, make sure to exclude "status.php", which must be publicly accessible [https://github.com/owncloud/mirall/issues/734]<br />
<br />
=== "Can't write into apps directory" ===<br />
As mentioned here, http://doc.owncloud.org/server/6.0/admin_manual/configuration/configuration_apps.html either you need an apps directory that is writable by the http user, or you need to set "appstoreenabled" to false. <br />
<br />
''Also'', not mentioned there, the directory needs to be in the open_basedir line in /etc/php/php.ini<br />
<br />
One clean method is to have the package-installed directory at /usr/share/webapps/owncloud/apps stay owned by root, and have the user-installed apps go into e.g. /var/www/owncloud/apps which is owned by http. Then you can set "appstoreenabled" to true and package upgrades of apps should work fine as well. Relevant lines from /etc/webapps/owncloud/config/config.php:<br />
<pre><br />
'apps_paths' => <br />
array (<br />
0 => <br />
array (<br />
'path' => '/usr/share/webapps/owncloud/apps',<br />
'url' => '/apps',<br />
'writable' => false,<br />
),<br />
1 => <br />
array (<br />
'path' => '/var/www/owncloud/apps',<br />
'url' => '/wapps',<br />
'writable' => true,<br />
),<br />
),<br />
</pre><br />
Example open_basedir line from /etc/php/php.ini (you might have other dirs in there as well):<br />
<pre><br />
open_basedir = /srv/http/:/usr/share/webapps/:/var/www/owncloud/apps/<br />
</pre><br />
<br />
Directory permissions:<br />
<pre><br />
$ ls -ld /usr/share/webapps/owncloud/apps /var/www/owncloud/apps/<br />
drwxr-xr-x 26 root root 4096 des. 14 20:48 /usr/share/webapps/owncloud/apps<br />
drwxr-xr-x 2 http http 48 jan. 20 20:01 /var/www/owncloud/apps/<br />
</pre></div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Nextcloud&diff=294877Nextcloud2014-01-29T10:06:21Z<p>Hunterthomson: /* Nginx + uwsgi_php alternative */ curl -g works and I see now that curl will work even if uwsgi is no running on the same host</p>
<hr />
<div>[[Category:Web Server]]<br />
[[fr:Owncloud]]<br />
[[ja:Owncloud]]<br />
From [[Wikipedia:ownCloud|Wikipedia]]:<br />
: ''ownCloud is a software suite that provides a location-independent storage area for data (cloud storage).''<br />
<br />
== Installation ==<br />
<br />
Set up the [[LAMP]] stack. <br />
<br />
You will probably need to install the MDB2 pear package as well. Install {{pkg|php-pear}}, then:<br />
# pear install MDB2<br />
<br />
# [[pacman|Install]] {{Pkg|owncloud}} from the [[official repositories]]. Alternatively see the packages available in the [[Arch User Repository]]: [https://aur.archlinux.org/packages.php?K=owncloud&O=0].<br />
# Copy {{ic|/etc/webapps/owncloud/apache.example.conf}} to {{ic|/etc/httpd/conf/extra/owncloud.conf}} (version 6+)<br />
# Add the following lines into {{ic|/etc/httpd/conf/httpd.conf}} (the php5 line should have already been added during the LAMP stack setup):<br />
Include /etc/httpd/conf/extra/owncloud.conf<br />
LoadModule php5_module modules/libphp5.so<br />
Include conf/extra/php5_module.conf<br />
<br />
Uncomment extensions in {{ic|/etc/php/php.ini}}:<br />
gd.so<br />
intl.so<br />
openssl.so<br />
xmlrpc.so<br />
zip.so<br />
iconv.so<br />
<br />
=== Database support ===<br />
Depending on which database backend you are going to use uncomment either one of the following extensions in {{ic|/etc/php/php.ini}}:<br />
{|border=1 class="wikitable"<br />
!SQLite!!MySQL!!PostgreSQL<br />
|-<br />
|<br />
sqlite.so<br />
sqlite3.so<br />
pdo_sqlite.so<br />
|<br />
mysql.so<br />
mysqli.so<br />
pdo_mysql.so<br />
|<br />
pgsql.so<br />
pdo_pgsql.so<br />
|-<br />
|}<br />
Don't forget to install the appropriate php-module for the database. In the PostgreSQL case thats {{Pkg|php-pgsql}} or for SQLite {{Pkg|php-sqlite}}.<br />
<br />
=== Exif support ===<br />
Additionally install exif support with<br />
# pacman -S exiv2<br />
and uncomment the exif.so extension in php.ini<br />
<br />
=== Disable Webdav ===<br />
Owncloud comes with its own Webdav enabled which conflict. Owncloud [http://forum.owncloud.org/viewtopic.php?f=17&t=7240 recommends] to disable mod_dav and mod_dav_fs. This should be done in {{ic|/etc/httpd/conf/httpd.conf}}<br />
<br />
Now [[Daemons#Restarting|restart]] httpd (Apache)<br />
# systemctl restart httpd<br />
Open [http://localhost http://localhost] in your browser. You should now be able to create a user account and follow the installation wizard.<br />
<br />
== Custom configurations ==<br />
<br />
=== Filesize limitations ===<br />
<br />
With the default configuration ownCloud only allows the upload of filesizes less than 2MB.<br />
This can be changed by changing the following line in {{ic|/etc/php/php.ini}} to your liking.<br />
<br />
'''As of version 4.0 this is no longer necessary! The maximum upload size is now set via the ownCloud gui'''<br />
upload_max_filesize = 2M<br />
<br />
As of version 4.5, upload limits are set in {{ic|/usr/share/webapps/owncloud/.htaccess}}. This won't work if [[LAMP#Using_php5_with_apache2-mpm-worker_and_mod_fcgid|PHP is set up to run as CGI]], so you need to change the limits in {{ic|/etc/php/php.ini}}. You also need to change open_basedir.<br />
{{bc|<nowiki><br />
upload_max_filesize = 512M<br />
post_max_size = 512M<br />
memory_limit = 512M<br />
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/<br />
</nowiki>}}<br />
<br />
=== Running ownCloud in a subdirectory ===<br />
<br />
By including the default '''owncloud.conf''' in '''httpd.conf''', owncloud will take control of port 80 and your localhost domain. If you would like to have owncloud run in a subdirectory, then skip the 'Include /etc/httpd/conf/extra/owncloud.conf' line altogether and just use a symbolic link like so: <br />
# ln -s /usr/share/webapps/owncloud/ /srv/http/<br />
<br />
In that case, you'll also have to ensure /usr/share/webapps is in the open_basedir line of php.ini, and that per-directory .htaccess files are read by apache. <br />
<br />
Alternatively, you could follow the standard procedure, but comment out the VirtualHost part of the include file, and skip the symlink/basedir/htaccess part.<br />
<br />
== Filling ownCloud with data ==<br />
<br />
=== Small files ===<br />
<br />
==== WebDav ====<br />
<br />
Always use [[WebDAV]] or the web interface to add new files to your ownCloud. Otherwise they will not show up correctly, as they do not get indexed right.<br />
No further configuration is necessary to enable [[WebDAV]] uploads in ownCloud. <br />
<br />
Consider installing and enabling [[php-apc]] to speed up WebDAV.<br />
<br />
==== SABnzbd ====<br />
<br />
When using [[SABnzbd]], you might want to set<br />
folder_rename 0<br />
in your sabnzbd.ini file, because ownCloud will scan the files as soon as they get uploaded, preventing SABnzbd from removing UNPACKING prefixes etc.<br />
<br />
=== Big files ===<br />
<br />
WebDAV isn't suitable for big files, because it fills up all the RAM and CPU.<br />
<br />
With the current version, it looks like, there is no good way of copying huge amounts of data to your ownCloud.<br />
<br />
Here's a Workaround:<br />
<br />
Copy the files directly to your ownCloud and do a full re-scan of your database (you could use the [http://apps.owncloud.com/content/show.php?content=151948&forumpage=0&PHPSESSID=37b915160effcc0f37cc761ad2ab88be Re-scan filesystem] add-on for example).<br />
<br />
But beware that this will not work as easily in the future, when end-to-end encryption gets added to ownCloud (this is a planned feature).<br />
<br />
== Important notes ==<br />
<br />
* When using a subdomain (like cloud.example.net), make sure it is covered by your certificate. Otherwise, connection via the owncloud client or webdav might fail.<br />
<br />
* If you are planning on using OwnCloud's [http://owncloud.org/sync-clients/ sync-clients], make sure to have [[NTP]] installed and running on your OwnCloud server, otherwise the sync-clients will fail.<br />
<br />
* Add some [[LAMP#SSL|SSL encryption]] to your connection!<br />
(If adding SSL encryption as above, be sure to edit /etc/httpd/conf/extra/httpd-ssl.conf and change DocumentRoot "/srv/http" to DocumentRoot "/usr/share/webapps/owncloud" )<br />
<br />
* More Apps for ownCloud can be found [http://apps.owncloud.com/ here]<br />
<br />
* To install an new application, download the zip from the apps store, extract it into /srv/http/owncloud/apps/.<br />
Afterwards restart httpd:<br />
<br />
systemctl restart httpd<br />
<br />
log into your server go to the app sections you should see the new apps in there,<br />
<br />
* If you are protecting access to your owncloud location with HTTP basic auth, the file "status.php" must be excluded from auth and be publicly accessible. [https://github.com/owncloud/mirall/issues/734]<br />
<br />
== Nginx + uwsgi_php alternative ==<br />
<br />
You can avoid the use of Apache, and run owncloud in it's own process by using the [https://www.archlinux.org/packages/uwsgi-plugin-php wsgi_php] application server. uWSGI itself has a wealth of features to limit the resource use, and to harden the security of the application, and by being a separate process it can run under its own user.<br />
<br />
The nginx config is:<br />
{{bc|<nowiki><br />
#this is to avoid Request Entity Too Large error<br />
client_max_body_size 1000M;<br />
# deny access to some special files<br />
location ~ ^/(data|config|\.ht|db_structure\.xml|README) {<br />
deny all;<br />
}<br />
# pass all .php or .php/path urls to uWSGI<br />
location ~ ^(.+\.php)(.*)$ {<br />
include uwsgi_params;<br />
uwsgi_modifier1 14;<br />
uwsgi_pass 127.0.0.1:3001;<br />
}<br />
# everything else goes to the filesystem,<br />
# but / will be mapped to index.php and run through uwsgi<br />
location / {<br />
root /usr/share/webapps/owncloud;<br />
index index.php;<br />
rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;<br />
rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;<br />
}<br />
</nowiki>}}<br />
The uWSGI /etc/uwsgi/owncloud.ini config file (run it with uwsgi_php --ini /etc/uwsgi/owncloud.ini):<br />
{{bc|<nowiki><br />
[uwsgi]<br />
socket = 127.0.0.1:3001<br />
master = true<br />
chdir = /srv/http/owncloud<br />
php-docroot = /usr/share/webapps/owncloud<br />
php-index = index.php<br />
<br />
# only allow these php files, I don't want to inadvertently run something else<br />
php-allowed-ext = /index.php<br />
php-allowed-ext = /public.php<br />
php-allowed-ext = /remote.php<br />
php-allowed-ext = /cron.php<br />
php-allowed-ext = /status.php<br />
php-allowed-ext = /settings/apps.php<br />
php-allowed-ext = /core/ajax/update.php<br />
php-allowed-ext = /core/ajax/share.php<br />
php-allowed-ext = /core/ajax/requesttoken.php<br />
php-allowed-ext = /core/ajax/translations.php<br />
php-allowed-ext = /search/ajax/search.php<br />
php-allowed-ext = /search/templates/part.results.php<br />
php-allowed-ext = /settings/admin.php<br />
php-allowed-ext = /settings/users.php<br />
php-allowed-ext = /settings/personal.php<br />
php-allowed-ext = /settings/help.php<br />
php-allowed-ext = /settings/ajax/getlog.php<br />
php-allowed-ext = /settings/ajax/setlanguage.php<br />
php-allowed-ext = /settings/ajax/setquota.php<br />
php-allowed-ext = /settings/ajax/userlist.php<br />
php-allowed-ext = /settings/ajax/createuser.php<br />
php-allowed-ext = /settings/ajax/removeuser.php<br />
php-allowed-ext = /settings/ajax/enableapp.php<br />
php-allowed-ext = /core/ajax/appconfig.php<br />
<br />
php-set = date.timezone=Europe/Skopje<br />
php-set = open_basedir=/srv/http/owncloud:/tmp/:/usr/share/pear/:/usr/share/webapps/owncloud<br />
<br />
processes = 10<br />
cheaper = 2<br />
# Local<br />
cron = -1 -1 -1 -1 -1 /usr/bin/php -f /usr/share/webapps/owncloud/cron.php 1>/dev/null<br />
# Remote<br />
cron = -1 -1 -1 -1 -1 /usr/bin/curl -g http://localhost/ >>/dev/null<br />
<br />
</nowiki>}}<br />
Finally, a simple systemd unit file to start the uwsgi instance can be (this is without using the emperor):<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=OwnCloud service via uWSGI-PHP<br />
<br />
[Service]<br />
User=http<br />
ExecStart=/usr/bin/uwsgi_php --ini /etc/uwsgi/owncloud.ini<br />
ExecReload=/bin/kill -HUP $MAINPID<br />
KillSignal=SIGQUIT<br />
Restart=always<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Sync Clients ==<br />
<br />
The offical clients can be found in this page : [http://owncloud.org/install/ Sync Clients]<br />
Also take notice that while the offical owncloud android app is a paid app on the play store, it is not a paid app on [https://f-droid.org/ F-Droid].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Self-signed certificate not accepted ===<br />
<br />
OwnCloud uses [[Wikipedia:cURL]] and [[Wikipedia:SabreDAV]] to check if [[WebDAV]] is enabled. If you use a SSL/TLS with a self-signed certificate, e.g. as shown in [[LAMP]] and access ownClouds admin panel, you will see the following error message:<br />
<br />
Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken.<br />
<br />
Assuming that you followed the [[LAMP]]-tutorial, execute the following steps:<br />
<br />
Create local directory for non-distribution certificates and copy [[LAMP]]s certificate there. This will prevent {{Ic|ca-certificates}}-updates to overwrite it.<br />
<br />
$ cp /etc/httpd/conf/server.crt /usr/share/ca-certificates/''WWW.EXAMPLE.COM.crt''<br />
<br />
Add ''WWW.EXAMPLE.COM.crt'' to {{ic|/etc/ca-certificates.conf}}:<br />
<br />
''WWW.EXAMPLE.COM.crt''<br />
<br />
Now, regenerate your certificate store:<br />
<br />
$ update-ca-certificates<br />
<br />
Restart the httpd service to activate your certificate.<br />
<br />
<br />
Should this not work consider disabling mod_curl in /etc/php/php.ini.<br />
<br />
=== Can't create data directory (/path/to/dir) ===<br />
<br />
Check your httpd conf file (like owncloud.conf). Add your data dir to <br />
php_admin_value open_basedir "/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/path/to/dir/"<br />
<br />
You should also modify php.ini in the same way. Restart the httpd service to activate the change.<br />
<br />
=== CSync faild to find a specific file. ===<br />
<br />
Most probably a certificate issue, recreate it, and don't leave the common name empty or you will see the error again.<br />
<br />
openssl genrsa -out server.key 2048<br />
openssl req -new -key server.key -x509 -days 365 -out server.crt<br />
<br />
=== Seeing white page after login ===<br />
<br />
The cause is probably a new app that you installed, to fix that you can either use phpMyAdmin by editing the oc_appconfig table(in the case you got lucky and the table has edit option) or do it by hand with mysql:<br />
<br />
mysql -u root -p owncloud<br />
MariaDB [owncloud]> '''delete from''' oc_appconfig '''where''' appid='<nameOfExtension>' '''and''' configkey='enabled' '''and''' configvalue='yes'<br />
MariaDB [owncloud]> '''insert into''' oc_appconfig (appid,configkey,configvalue) '''values''' ('<nameOfExtension>','enabled','no');<br />
<br />
This should delete the relevant configuration from the table and add it again.<br />
<br />
=== GUI sync client fails to connect ===<br />
<br />
If using HTTP basic auth, make sure to exclude "status.php", which must be publicly accessible [https://github.com/owncloud/mirall/issues/734]<br />
<br />
=== "Can't write into apps directory" ===<br />
As mentioned here, http://doc.owncloud.org/server/6.0/admin_manual/configuration/configuration_apps.html either you need an apps directory that is writable by the http user, or you need to set "appstoreenabled" to false. <br />
<br />
''Also'', not mentioned there, the directory needs to be in the open_basedir line in /etc/php/php.ini<br />
<br />
One clean method is to have the package-installed directory at /usr/share/webapps/owncloud/apps stay owned by root, and have the user-installed apps go into e.g. /var/www/owncloud/apps which is owned by http. Then you can set "appstoreenabled" to true and package upgrades of apps should work fine as well. Relevant lines from /etc/webapps/owncloud/config/config.php:<br />
<pre><br />
'apps_paths' => <br />
array (<br />
0 => <br />
array (<br />
'path' => '/usr/share/webapps/owncloud/apps',<br />
'url' => '/apps',<br />
'writable' => false,<br />
),<br />
1 => <br />
array (<br />
'path' => '/var/www/owncloud/apps',<br />
'url' => '/wapps',<br />
'writable' => true,<br />
),<br />
),<br />
</pre><br />
Example open_basedir line from /etc/php/php.ini (you might have other dirs in there as well):<br />
<pre><br />
open_basedir = /srv/http/:/usr/share/webapps/:/var/www/owncloud/apps/<br />
</pre><br />
<br />
Directory permissions:<br />
<pre><br />
$ ls -ld /usr/share/webapps/owncloud/apps /var/www/owncloud/apps/<br />
drwxr-xr-x 26 root root 4096 des. 14 20:48 /usr/share/webapps/owncloud/apps<br />
drwxr-xr-x 2 http http 48 jan. 20 20:01 /var/www/owncloud/apps/<br />
</pre></div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Nextcloud&diff=294874Nextcloud2014-01-29T09:24:19Z<p>Hunterthomson: /* Nginx + uwsgi_php alternative */ /usr/bin/curl -H http://localhost/cron.php is not a valid command. OwnCloud docs suggest php -f cron.php</p>
<hr />
<div>[[Category:Web Server]]<br />
[[fr:Owncloud]]<br />
[[ja:Owncloud]]<br />
From [[Wikipedia:ownCloud|Wikipedia]]:<br />
: ''ownCloud is a software suite that provides a location-independent storage area for data (cloud storage).''<br />
<br />
== Installation ==<br />
<br />
Set up the [[LAMP]] stack. <br />
<br />
You will probably need to install the MDB2 pear package as well. Install {{pkg|php-pear}}, then:<br />
# pear install MDB2<br />
<br />
# [[pacman|Install]] {{Pkg|owncloud}} from the [[official repositories]]. Alternatively see the packages available in the [[Arch User Repository]]: [https://aur.archlinux.org/packages.php?K=owncloud&O=0].<br />
# Copy {{ic|/etc/webapps/owncloud/apache.example.conf}} to {{ic|/etc/httpd/conf/extra/owncloud.conf}} (version 6+)<br />
# Add the following lines into {{ic|/etc/httpd/conf/httpd.conf}} (the php5 line should have already been added during the LAMP stack setup):<br />
Include /etc/httpd/conf/extra/owncloud.conf<br />
LoadModule php5_module modules/libphp5.so<br />
Include conf/extra/php5_module.conf<br />
<br />
Uncomment extensions in {{ic|/etc/php/php.ini}}:<br />
gd.so<br />
intl.so<br />
openssl.so<br />
xmlrpc.so<br />
zip.so<br />
iconv.so<br />
<br />
=== Database support ===<br />
Depending on which database backend you are going to use uncomment either one of the following extensions in {{ic|/etc/php/php.ini}}:<br />
{|border=1 class="wikitable"<br />
!SQLite!!MySQL!!PostgreSQL<br />
|-<br />
|<br />
sqlite.so<br />
sqlite3.so<br />
pdo_sqlite.so<br />
|<br />
mysql.so<br />
mysqli.so<br />
pdo_mysql.so<br />
|<br />
pgsql.so<br />
pdo_pgsql.so<br />
|-<br />
|}<br />
Don't forget to install the appropriate php-module for the database. In the PostgreSQL case thats {{Pkg|php-pgsql}} or for SQLite {{Pkg|php-sqlite}}.<br />
<br />
=== Exif support ===<br />
Additionally install exif support with<br />
# pacman -S exiv2<br />
and uncomment the exif.so extension in php.ini<br />
<br />
=== Disable Webdav ===<br />
Owncloud comes with its own Webdav enabled which conflict. Owncloud [http://forum.owncloud.org/viewtopic.php?f=17&t=7240 recommends] to disable mod_dav and mod_dav_fs. This should be done in {{ic|/etc/httpd/conf/httpd.conf}}<br />
<br />
Now [[Daemons#Restarting|restart]] httpd (Apache)<br />
# systemctl restart httpd<br />
Open [http://localhost http://localhost] in your browser. You should now be able to create a user account and follow the installation wizard.<br />
<br />
== Custom configurations ==<br />
<br />
=== Filesize limitations ===<br />
<br />
With the default configuration ownCloud only allows the upload of filesizes less than 2MB.<br />
This can be changed by changing the following line in {{ic|/etc/php/php.ini}} to your liking.<br />
<br />
'''As of version 4.0 this is no longer necessary! The maximum upload size is now set via the ownCloud gui'''<br />
upload_max_filesize = 2M<br />
<br />
As of version 4.5, upload limits are set in {{ic|/usr/share/webapps/owncloud/.htaccess}}. This won't work if [[LAMP#Using_php5_with_apache2-mpm-worker_and_mod_fcgid|PHP is set up to run as CGI]], so you need to change the limits in {{ic|/etc/php/php.ini}}. You also need to change open_basedir.<br />
{{bc|<nowiki><br />
upload_max_filesize = 512M<br />
post_max_size = 512M<br />
memory_limit = 512M<br />
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/<br />
</nowiki>}}<br />
<br />
=== Running ownCloud in a subdirectory ===<br />
<br />
By including the default '''owncloud.conf''' in '''httpd.conf''', owncloud will take control of port 80 and your localhost domain. If you would like to have owncloud run in a subdirectory, then skip the 'Include /etc/httpd/conf/extra/owncloud.conf' line altogether and just use a symbolic link like so: <br />
# ln -s /usr/share/webapps/owncloud/ /srv/http/<br />
<br />
In that case, you'll also have to ensure /usr/share/webapps is in the open_basedir line of php.ini, and that per-directory .htaccess files are read by apache. <br />
<br />
Alternatively, you could follow the standard procedure, but comment out the VirtualHost part of the include file, and skip the symlink/basedir/htaccess part.<br />
<br />
== Filling ownCloud with data ==<br />
<br />
=== Small files ===<br />
<br />
==== WebDav ====<br />
<br />
Always use [[WebDAV]] or the web interface to add new files to your ownCloud. Otherwise they will not show up correctly, as they do not get indexed right.<br />
No further configuration is necessary to enable [[WebDAV]] uploads in ownCloud. <br />
<br />
Consider installing and enabling [[php-apc]] to speed up WebDAV.<br />
<br />
==== SABnzbd ====<br />
<br />
When using [[SABnzbd]], you might want to set<br />
folder_rename 0<br />
in your sabnzbd.ini file, because ownCloud will scan the files as soon as they get uploaded, preventing SABnzbd from removing UNPACKING prefixes etc.<br />
<br />
=== Big files ===<br />
<br />
WebDAV isn't suitable for big files, because it fills up all the RAM and CPU.<br />
<br />
With the current version, it looks like, there is no good way of copying huge amounts of data to your ownCloud.<br />
<br />
Here's a Workaround:<br />
<br />
Copy the files directly to your ownCloud and do a full re-scan of your database (you could use the [http://apps.owncloud.com/content/show.php?content=151948&forumpage=0&PHPSESSID=37b915160effcc0f37cc761ad2ab88be Re-scan filesystem] add-on for example).<br />
<br />
But beware that this will not work as easily in the future, when end-to-end encryption gets added to ownCloud (this is a planned feature).<br />
<br />
== Important notes ==<br />
<br />
* When using a subdomain (like cloud.example.net), make sure it is covered by your certificate. Otherwise, connection via the owncloud client or webdav might fail.<br />
<br />
* If you are planning on using OwnCloud's [http://owncloud.org/sync-clients/ sync-clients], make sure to have [[NTP]] installed and running on your OwnCloud server, otherwise the sync-clients will fail.<br />
<br />
* Add some [[LAMP#SSL|SSL encryption]] to your connection!<br />
(If adding SSL encryption as above, be sure to edit /etc/httpd/conf/extra/httpd-ssl.conf and change DocumentRoot "/srv/http" to DocumentRoot "/usr/share/webapps/owncloud" )<br />
<br />
* More Apps for ownCloud can be found [http://apps.owncloud.com/ here]<br />
<br />
* To install an new application, download the zip from the apps store, extract it into /srv/http/owncloud/apps/.<br />
Afterwards restart httpd:<br />
<br />
systemctl restart httpd<br />
<br />
log into your server go to the app sections you should see the new apps in there,<br />
<br />
* If you are protecting access to your owncloud location with HTTP basic auth, the file "status.php" must be excluded from auth and be publicly accessible. [https://github.com/owncloud/mirall/issues/734]<br />
<br />
== Nginx + uwsgi_php alternative ==<br />
<br />
You can avoid the use of Apache, and run owncloud in it's own process by using the [https://www.archlinux.org/packages/uwsgi-plugin-php wsgi_php] application server. uWSGI itself has a wealth of features to limit the resource use, and to harden the security of the application, and by being a separate process it can run under its own user.<br />
<br />
The nginx config is:<br />
{{bc|<nowiki><br />
#this is to avoid Request Entity Too Large error<br />
client_max_body_size 1000M;<br />
# deny access to some special files<br />
location ~ ^/(data|config|\.ht|db_structure\.xml|README) {<br />
deny all;<br />
}<br />
# pass all .php or .php/path urls to uWSGI<br />
location ~ ^(.+\.php)(.*)$ {<br />
include uwsgi_params;<br />
uwsgi_modifier1 14;<br />
uwsgi_pass 127.0.0.1:3001;<br />
}<br />
# everything else goes to the filesystem,<br />
# but / will be mapped to index.php and run through uwsgi<br />
location / {<br />
root /usr/share/webapps/owncloud;<br />
index index.php;<br />
rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;<br />
rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;<br />
}<br />
</nowiki>}}<br />
The uWSGI /etc/uwsgi/owncloud.ini config file (run it with uwsgi_php --ini /etc/uwsgi/owncloud.ini):<br />
{{bc|<nowiki><br />
[uwsgi]<br />
socket = 127.0.0.1:3001<br />
master = true<br />
chdir = /srv/http/owncloud<br />
php-docroot = /usr/share/webapps/owncloud<br />
php-index = index.php<br />
<br />
# only allow these php files, I don't want to inadvertently run something else<br />
php-allowed-ext = /index.php<br />
php-allowed-ext = /public.php<br />
php-allowed-ext = /remote.php<br />
php-allowed-ext = /cron.php<br />
php-allowed-ext = /status.php<br />
php-allowed-ext = /settings/apps.php<br />
php-allowed-ext = /core/ajax/update.php<br />
php-allowed-ext = /core/ajax/share.php<br />
php-allowed-ext = /core/ajax/requesttoken.php<br />
php-allowed-ext = /core/ajax/translations.php<br />
php-allowed-ext = /search/ajax/search.php<br />
php-allowed-ext = /search/templates/part.results.php<br />
php-allowed-ext = /settings/admin.php<br />
php-allowed-ext = /settings/users.php<br />
php-allowed-ext = /settings/personal.php<br />
php-allowed-ext = /settings/help.php<br />
php-allowed-ext = /settings/ajax/getlog.php<br />
php-allowed-ext = /settings/ajax/setlanguage.php<br />
php-allowed-ext = /settings/ajax/setquota.php<br />
php-allowed-ext = /settings/ajax/userlist.php<br />
php-allowed-ext = /settings/ajax/createuser.php<br />
php-allowed-ext = /settings/ajax/removeuser.php<br />
php-allowed-ext = /settings/ajax/enableapp.php<br />
php-allowed-ext = /core/ajax/appconfig.php<br />
<br />
php-set = date.timezone=Europe/Skopje<br />
php-set = open_basedir=/srv/http/owncloud:/tmp/:/usr/share/pear/:/usr/share/webapps/owncloud<br />
<br />
processes = 10<br />
cheaper = 2<br />
# Run ownCloud cron.php minute to update OC instead of using default AJAX which slows every page loads<br />
cron = -1 -1 -1 -1 -1 /usr/bin/php -f /usr/share/webapps/owncloud/cron.php 1>/dev/null<br />
<br />
</nowiki>}}<br />
Finally, a simple systemd unit file to start the uwsgi instance can be (this is without using the emperor):<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=OwnCloud service via uWSGI-PHP<br />
<br />
[Service]<br />
User=http<br />
ExecStart=/usr/bin/uwsgi_php --ini /etc/uwsgi/owncloud.ini<br />
ExecReload=/bin/kill -HUP $MAINPID<br />
KillSignal=SIGQUIT<br />
Restart=always<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Sync Clients ==<br />
<br />
The offical clients can be found in this page : [http://owncloud.org/install/ Sync Clients]<br />
Also take notice that while the offical owncloud android app is a paid app on the play store, it is not a paid app on [https://f-droid.org/ F-Droid].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Self-signed certificate not accepted ===<br />
<br />
OwnCloud uses [[Wikipedia:cURL]] and [[Wikipedia:SabreDAV]] to check if [[WebDAV]] is enabled. If you use a SSL/TLS with a self-signed certificate, e.g. as shown in [[LAMP]] and access ownClouds admin panel, you will see the following error message:<br />
<br />
Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken.<br />
<br />
Assuming that you followed the [[LAMP]]-tutorial, execute the following steps:<br />
<br />
Create local directory for non-distribution certificates and copy [[LAMP]]s certificate there. This will prevent {{Ic|ca-certificates}}-updates to overwrite it.<br />
<br />
$ cp /etc/httpd/conf/server.crt /usr/share/ca-certificates/''WWW.EXAMPLE.COM.crt''<br />
<br />
Add ''WWW.EXAMPLE.COM.crt'' to {{ic|/etc/ca-certificates.conf}}:<br />
<br />
''WWW.EXAMPLE.COM.crt''<br />
<br />
Now, regenerate your certificate store:<br />
<br />
$ update-ca-certificates<br />
<br />
Restart the httpd service to activate your certificate.<br />
<br />
<br />
Should this not work consider disabling mod_curl in /etc/php/php.ini.<br />
<br />
=== Can't create data directory (/path/to/dir) ===<br />
<br />
Check your httpd conf file (like owncloud.conf). Add your data dir to <br />
php_admin_value open_basedir "/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/path/to/dir/"<br />
<br />
You should also modify php.ini in the same way. Restart the httpd service to activate the change.<br />
<br />
=== CSync faild to find a specific file. ===<br />
<br />
Most probably a certificate issue, recreate it, and don't leave the common name empty or you will see the error again.<br />
<br />
openssl genrsa -out server.key 2048<br />
openssl req -new -key server.key -x509 -days 365 -out server.crt<br />
<br />
=== Seeing white page after login ===<br />
<br />
The cause is probably a new app that you installed, to fix that you can either use phpMyAdmin by editing the oc_appconfig table(in the case you got lucky and the table has edit option) or do it by hand with mysql:<br />
<br />
mysql -u root -p owncloud<br />
MariaDB [owncloud]> '''delete from''' oc_appconfig '''where''' appid='<nameOfExtension>' '''and''' configkey='enabled' '''and''' configvalue='yes'<br />
MariaDB [owncloud]> '''insert into''' oc_appconfig (appid,configkey,configvalue) '''values''' ('<nameOfExtension>','enabled','no');<br />
<br />
This should delete the relevant configuration from the table and add it again.<br />
<br />
=== GUI sync client fails to connect ===<br />
<br />
If using HTTP basic auth, make sure to exclude "status.php", which must be publicly accessible [https://github.com/owncloud/mirall/issues/734]<br />
<br />
=== "Can't write into apps directory" ===<br />
As mentioned here, http://doc.owncloud.org/server/6.0/admin_manual/configuration/configuration_apps.html either you need an apps directory that is writable by the http user, or you need to set "appstoreenabled" to false. <br />
<br />
''Also'', not mentioned there, the directory needs to be in the open_basedir line in /etc/php/php.ini<br />
<br />
One clean method is to have the package-installed directory at /usr/share/webapps/owncloud/apps stay owned by root, and have the user-installed apps go into e.g. /var/www/owncloud/apps which is owned by http. Then you can set "appstoreenabled" to true and package upgrades of apps should work fine as well. Relevant lines from /etc/webapps/owncloud/config/config.php:<br />
<pre><br />
'apps_paths' => <br />
array (<br />
0 => <br />
array (<br />
'path' => '/usr/share/webapps/owncloud/apps',<br />
'url' => '/apps',<br />
'writable' => false,<br />
),<br />
1 => <br />
array (<br />
'path' => '/var/www/owncloud/apps',<br />
'url' => '/wapps',<br />
'writable' => true,<br />
),<br />
),<br />
</pre><br />
Example open_basedir line from /etc/php/php.ini (you might have other dirs in there as well):<br />
<pre><br />
open_basedir = /srv/http/:/usr/share/webapps/:/var/www/owncloud/apps/<br />
</pre><br />
<br />
Directory permissions:<br />
<pre><br />
$ ls -ld /usr/share/webapps/owncloud/apps /var/www/owncloud/apps/<br />
drwxr-xr-x 26 root root 4096 des. 14 20:48 /usr/share/webapps/owncloud/apps<br />
drwxr-xr-x 2 http http 48 jan. 20 20:01 /var/www/owncloud/apps/<br />
</pre></div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Dwb&diff=294726Dwb2014-01-28T04:52:51Z<p>Hunterthomson: /* Search engines */ add example which needs manual intervention</p>
<hr />
<div>{{DISPLAYTITLE:dwb}}<br />
[[Category:Web Browser]]<br />
[[de:dwb]]<br />
[[tr:dwb]]<br />
[http://portix.bitbucket.org/dwb/ dwb] is an extremely fast, lightweight and flexible web browser using the webkit engine. It is customizable through its web interface and fully usable with keyboard shortcuts.<br />
<br />
== Installation ==<br />
<br />
The {{Pkg|dwb}} package can be found in the [[official repositories]] and can be installed with [[pacman]]. There are also other versions in the [[AUR]]: {{AUR|dwb-git}}, {{AUR|dwb-gtk3}}, and {{AUR|dwb-gtk3-git}}.<br />
<br />
== Basic usage ==<br />
<br />
Starting from a fresh configuration, use {{ic|Sk}} to open the ''Keys'' page. As you can see from there, most bindings are borrowed from [[Vim]] and [[Emacs]].<br />
<br />
Use {{ic|:}} to access the command prompt. You can use {{ic|Tab}} to auto-complete.<br />
<br />
Read the man page for more details and enable the {{ic|auto-completion}} option in the settings to help you learn the bindings.<br />
<br />
$ man dwb<br />
<br />
=== dwb-specific ===<br />
<br />
o = enter url<br />
O = enter url in new tab<br />
f = spawn hints. Use arrow keys to browse the hints while displaying their URI, or use the hint letters.<br />
F = spawn hints in new tab<br />
;b = spawn hints in new background tab<br />
;r = follow multiple background links rapidly<br />
H = back<br />
L = forward<br />
J = go to next tab<br />
K = go to previous tab<br />
'n'+T = goto 'n' tab<br />
d = close tab<br />
u = undo close tab<br />
ctrl+s = stop<br />
r = reload<br />
R = reload ignoring cache<br />
gi = go to the first input field and enter insert mode<br />
ctrl+e = open editable field in external editor. Useful for forums and wikis.<br />
;d = download via hints<br />
M = save bookmark (bookmarks are saved in ~/.config/dwb/default/bookmarks)<br />
xb = show/hide status bar<br />
gf = toggle source view<br />
+ = zoom_in<br />
- = zoom_out<br />
= = reset to 100%<br />
<br />
=== vim-like ===<br />
<br />
i = toggle_insert_mode (Esc works to go back to normal mode much like Vim)<br />
Esc = back to normal mode (ctrl+n works too)<br />
j = scroll down<br />
k = scroll up<br />
h = scroll left<br />
l = scroll right<br />
gg = go to top<br />
G = go to bottom<br />
/ = find in page<br />
n = repeat find forward<br />
ZZ = save session and exit<br />
<br />
=== Notes ===<br />
<br />
Press {{ic|v}} to switch to caret browsing, then press {{ic|space}} to toggle between caret and visual mode. Press {{ic|Esc}} one or two times to go back to normal mode. While in caret browsing, you can use the arrow keys to browse the different parts of the page. Hold {{ic|Shift}} to select text. Press {{ic|Enter}} to follow links.<br />
<br />
== Configuration ==<br />
<br />
The configuration files are stored in {{ic|$XDG_CONFIG_HOME/dwb/}} (usually {{ic| ~/.config/dwb/}}) and can be easily accessed through the web interface. Type {{ic|Ss}} to open the ''Settings'' page.<br />
<br />
=== Search engines ===<br />
<br />
Open your favorite search engine, type {{ic|gs}} to select the web page's first input field, and then enter a keyword associated with it. <br />
<br />
Now you can use the keyword in the URI prompt to search directly on the corresponding website. Typing queries directly in the address bar will search with the default search engine, which is the first entry in {{ic|$XDG_CONFIG_HOME/dwb/searchengines}}.<br />
<br />
You can also add more by editing the configuration files. This may help for tricky sites like rfc-editor.org.<br />
<br />
.config/dwb/settings to<br />
searchengine-submit-pattern=XXX<br />
<br />
.config/dwb/searchengines<br />
sp https://startpage.com/do/search?q=XXX<br />
wp https://en.wikipedia.org/w/index.php?search=XXX&title=Special:Search<br />
aw https://wiki.archlinux.org/index.php?title=Special:Search&search=XXX<br />
rfc http://www.rfc-editor.org/search/rfc_search_detail.php?rfc=&title=XXX<br />
<br />
=== Custom keybinds ===<br />
<br />
You can create custom key bindings by editing file {{ic|custom_keys}} in the profile directory. This is<br />
{{ic|~/.config/dwb/default}} by default. All keysyms which don't emit (multi)byte characters, must be enclosed in {{ic|@}}. One keybind can execute multiple ''dwb'' commands. These commands execute in same order as they are defined in bind, and must be separated by {{ic|;;}} separator. If the keybind's chord is already bound by ''dwb'', it might be ignored (behaviour is not consistent). In such case one can try to check, whether there is collison with binds defined in {{ic|~/.config/dwb/keys}} and try to unbind the chord there (eg set it to nothing). Any running ''dwb'' instance will owerwrite {{ic|keys}} file on exit, so remember to do your modifications while ''dwb'' is not runing or use default ''dwb'' interface ({{ic|Sk}}).<br />
<br />
{{hc|~/.config/dwb/default/custom_keys|<nowiki><br />
Control w :close_tab<br />
Control @Page_Up@ :focus_prev<br />
Control @Page_Down@ :focus_next<br />
</nowiki>}}<br />
<br />
== Extensions ==<br />
<br />
''dwb'' features an extension manager as a separate executable, ''dwbem''. To list all officially available extensions, use:<br />
<br />
{{hc|dwbem -a|<br />
Available extensions: Mainstream equivalent:<br />
- adblock_subscriptions Adblock<br />
- autoquvi Video DownloadHelper<br />
- contenthandler (Handle requests based on MIME type, filename extension or URI scheme)<br />
- downloadhandler (Handle downloads based on mimetype or filename extension, useful if 'download-no-confirm' is set)<br />
- formfiller LastPass, Lazarus (Save form data and fill forms with previously saved data, also with gpg-support)<br />
- googlebookmarks GBookmarks, GMarks (Add bookmarks to google bookmarks with a shortcut)<br />
- googledocs Open with Google Docs, Google Docs Viewer<br />
- grabscrolling (Adobe Acrobat style grab and drag mouse scrolling)<br />
- multimarks (Bookmark multiple urls to a single quickmark)<br />
- navtools Opera Fast Forward, IE 10 Flip Ahead<br />
- perdomainsettings (Change webkit-settings automatically on domain or url basis)<br />
- pwdhash PwdHash<br />
- requestpolicy RequestPolicy, Disconnect, Ghostery<br />
- simplyread Readability, Clearly<br />
- speeddial Speed Dial<br />
- supergenpass (Generate domain-based passwords; compatible with the bookmarklet supergenpass but with additional options)<br />
- unique_tabs (Remove duplicate tabs or avoid duplicate tabs by autoswitching to tabs with same url)<br />
- userscripts GreaseMonkey/Stylish<br />
- whitelistshortcuts (Whitelist webkit settings for certain domains with a shortcut)<br />
}}<br />
<br />
For more details, use {{ic|dwbem -I <extension>}} and read the [http://portix.bitbucket.org/dwb/resources/dwb.1.html dwb] and [http://portix.bitbucket.org/dwb/resources/dwbem.1.html dwbem] man pages.<br />
<br />
Below is a list of popular extensions (or add-ons) for which ''dwb'' has a built-in alternative:<br />
<br />
* NoScript/Flashblock: ''dwb'' blocks flash by default and can block javascript.<br />
* Omnibar: just like Chrome, ''dwb'''s address gives quick access to search, history, and bookmarks.<br />
* Download Statusbar: ''dwb'''s displays downloads in a neat status bar by default.<br />
* IE Tab: ''dwb'' can open a page in any external browser with a simple userscript.<br />
* Session Manager: ''dwb'' uses its built-in session manager by default.<br />
* Private browsing: add {{ic|xpp:toggle enable-private-browsing}} to {{ic|custom_keys}} to toggle privacy mode by typing {{ic|xpp}}.<br />
<br />
=== Adblock ===<br />
<br />
''dwb'' features an Adblock extension. Install it with<br />
<br />
$ dwbem -i adblock_subscriptions<br />
<br />
Restart ''dwb'', enable adblocker with {{ic|:set adblocker true}}, use the ''adblock_subscribe'' command and choose your favorite filter (avoid using more than one filter to prevent duplicate entries that make the adblocker much slower).<br />
<br />
== Userscripts ==<br />
<br />
''dwb'' can execute .js or .sh scripts put in {{ic|~/.config/dwb/userscripts/}}. Make sure they are executable:<br />
chmod +x ~/.config/dwb/userscripts/myscript.js<br />
<br />
Below are some example scripts, see ''dwb'' [http://portix.bitbucket.org/dwb/snippets/snippets.html userscripts snippets] for more:<br />
<br />
=== defer-loading ===<br />
<br />
Prevents tabs from last session to load all at once at startup.<br />
{{hc|~/.config/dwb/userscripts/defer-loading.js|<nowiki><br />
//!javascript<br />
if (settings.loadOnFocus === false) {<br />
execute('local_set load-on-focus true');<br />
}<br />
Signal.connect('navigation', function(webview) {<br />
if (webview == tabs.current) {<br />
execute('local_set load-on-focus false');<br />
this.disconnect();<br />
}<br />
});</nowiki>}}<br />
<br />
=== fast-forward ===<br />
<br />
Opera features a neat key binding which allows users to load to next/previous logical page. This is very useful for forum threads, documentation, and articles spread over several pages.<br />
<br />
This feature can be implemented with a simple javascript function and bound to custom keys {{ic|<nowiki>}</nowiki>}} and {{ic|{}}:<br />
<br />
{{hc|~/.config/dwb/default/custom_keys|<nowiki><br />
}:exja (function(){var e=document.querySelector("[rel='next']");if(e){location=e.href;}else{var f=document.getElementsByTagName("a");var i=f.length;while((e=f[--i])){if(e.text.search(/(\bnext\b|^>$|^(>>|»)$|^(>|»)|(>|»)$|\bmore\b)/i)>-1){location=e.href; break;}} location.href=location.href.replace(/(\d+)([^\/\d]*)$/, function(a,b,c){return ++b+c})}})();<br />
{:exja (function(){var e=document.querySelector("[rel='prev']");if(e){location=e.href;}else{var f=document.getElementsByTagName("a");var i=f.length;while((e=f[--i])){if(e.text.search(/(\b(prev|previous)\b|^<$|^(<<|«)$|^(<|«)|(<|«)$)/i)>-1){location=e.href;break;}} location.href=location.href.replace(/(\d+)([^\/\d]*)$/, function(a,b,c){return --b+c})}})();<br />
</nowiki>}}<br />
<br />
Alternatively, the {{ic|navtools}} extension provides the same functionality and more, such as going up one directory, or loading the root URI.<br />
<br />
=== open-firefox ===<br />
Opens current page in Firefox with {{ic|xf}} (uses {{Pkg|firefox}} and {{Pkg|notify-send}}).<br />
{{hc|~/.config/dwb/userscripts/open-firefox.sh|<nowiki><br />
#!/bin/bash<br />
# dwb: xf<br />
firefox $DWB_URI &<br />
notify-send -u low "Firefox opening $DWB_URI" #optional notification<br />
</nowiki>}}<br />
<br />
=== startup-noautoreload ===<br />
<br />
Prevents previously-opened tabs from reloading all at once after a restart.<br />
{{hc|~/.config/dwb/userscripts/startup-noautoreload.js|<nowiki><br />
//!javascript<br />
// prevents previously-opened tabs from reloading all at once after a restart.<br />
execute("set load-on-focus true");<br />
<br />
var sigId = Signal.connect("navigation", function(wv) {<br />
if (wv == tabs.current)<br />
{<br />
execute("set load-on-focus false");<br />
Signal.disconnect(sigId);<br />
}<br />
});</nowiki>}}<br />
<br />
=== toggle-stylesheet ===<br />
<br />
Toggles between 2 global stylesheets with {{ic|xg}}.<br />
{{hc|~/.config/dwb/userscripts/toggle-stylesheet.sh|<nowiki><br />
#!/bin/bash<br />
# dwb:xg<br />
<br />
CURRENT_STYLESHEET="$(dwbremote get setting user-stylesheet-uri)"<br />
<br />
STYLESHEET_1="file://$HOME/.config/dwb/stylesheets/foo.css"<br />
STYLESHEET_2="file://$HOME/.config/dwb/stylesheets/bar.css"<br />
<br />
if [[ "${CURRENT_STYLESHEET}" = ${STYLESHEET_1} ]]; then<br />
dwbremote :local_set user-stylesheet-uri "$STYLESHEET_2"<br />
else <br />
dwbremote :local_set user-stylesheet-uri "$STYLESHEET_1"<br />
fi</nowiki>}}<br />
<br />
=== youtube-player ===<br />
<br />
Opens YouTube videos with MPlayer (uses {{Pkg|mplayer}} and {{Pkg|youtube-dl}}).<br />
{{hc|~/.config/dwb/userscripts/youtube-mplayer.js|<nowiki><br />
//!javascript <br />
// opens YouTube videos with mplayer.<br />
var regex = new RegExp("http(.*)://www.youtube.com/watch\\?(.*&)*v=.*");<br />
<br />
signals.connect("navigation", function (wv, frame, request) {<br />
if (wv.mainFrame == frame && regex.test(request.uri)) <br />
system.spawn("sh -c 'mplayer \"$(youtube-dl -g " + request.uri + ")\"'");<br />
return false;<br />
});</nowiki>}}<br />
<br />
=== rocker gestures ===<br />
<br />
Enables Opera-like rocker gestures for navigating the history. Disable the context menu in the settings first.<br />
{{hc|~/.config/dwb/userscripts/rocker.js|<nowiki><br />
//!javascript<br />
var LMB = 1, MMB=2, RMB = 3, UNKNOWN = 10, DOWN = 11, UP = 12;<br />
<br />
var buttonStates = [UNKNOWN, UNKNOWN, UNKNOWN, UNKNOWN, UNKNOWN, UNKNOWN];<br />
var bp = new Signal("onButtonPress", function(wv, result, ev) {<br />
var mouseButton = ev.button;<br />
<br />
buttonStates[mouseButton] = DOWN;<br />
<br />
if (mouseButton == LMB && buttonStates[RMB] == DOWN) {<br />
execute("history_back");<br />
} else if (mouseButton == RMB && buttonStates[LMB] == DOWN) {<br />
execute("history_forward");<br />
}<br />
});<br />
var br = new Signal("onButtonRelease", function(wv, result, ev) {<br />
buttonStates[ev.button] = UP;<br />
});<br />
<br />
bp.connect();<br />
br.connect();</nowiki>}}<br />
<br />
== Stylesheet ==<br />
<br />
a global stylesheet can be defined in the Settings, under {{ic|user-stylesheet-uri}} (i.e. {{ic|file:///home/tux/.config/dwb/stylesheet.css}})<br />
<br />
If you browse with the status bar hidden and are annoyed by the the link previews that appear while hovering over links with the mouse, add this to the stylesheet: {{ic|#dwb_hover_element { display:none!important; }}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== HTML5 audio and video does not work ===<br />
<br />
Make sure you have the following GStreamer packages installed:<br />
# pacman -S --needed gstreamer0.10 gstreamer0.10-bad gstreamer0.10-bad-plugins gstreamer0.10-base gstreamer0.10-base-plugins gstreamer0.10-good gstreamer0.10-good-plugins gstreamer0.10-ugly gstreamer0.10-ugly-plugins gstreamer0.10-ffmpeg<br />
<br />
=== Search engines search for ''undefined'' ===<br />
<br />
If you are always searching for ''undefined'' even with the {{ic|searchengine-submit-pattern}} option set, then you should edit {{ic|$XDG_CONFIG_HOME/dwb/searchengines}} and adapt the URIs to match your {{ic|searchengine-submit-pattern}}.<br />
<br />
=== Fuzzy font in Github ===<br />
<br />
Add this in your {{ic|~/.config/fontconfig/fonts.conf}} inside the fontconfig-tags:<br />
<br />
<selectfont><br />
<rejectfont><br />
<pattern><br />
<patelt name="family"><br />
<string>Clean</string><br />
</patelt><br />
</pattern><br />
</rejectfont><br />
</selectfont><br />
<br />
== dwb-git ==<br />
<br />
[https://aur.archlinux.org/packages/dwb-git dwb-git] offers many improvements over the stable version. Most the most notable of which are listed below.<br />
<br />
=== Plugin Support ===<br />
<br />
Browser Plugins can be enabled and disabled through the new [dwb:plugins dwb:plugins] settings page. Other [https://wiki.archlinux.org/index.php/Browser_Plugins Browser Plugins] may be supported as well, but these two alone will make your dwb experience much more enjoyable.<br />
<br />
==== Flash Support ====<br />
<br />
[https://aur.archlinux.org/packages/dwb-git dwb-git] has built in support for the [https://www.archlinux.org/packages/?name=flashplugin flashplugin]. Dwb should auto-detect and enabled the plugin after it is installed.<br />
<br />
==== Java Support ====<br />
<br />
[https://aur.archlinux.org/packages/dwb-git dwb-git] has built in support for the [https://www.archlinux.org/packages/?name=icedtea-web-java7 icedtea-web-java7]. Dwb should auto-detect and enable the plugin after it is installed.<br />
<br />
=== Improved Ability to Display Websites ===<br />
<br />
If you are having problems with they layout of websites not loading correctly then give [https://aur.archlinux.org/packages/dwb-git dwb-git] a shot.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Dwb&diff=294725Dwb2014-01-28T04:38:09Z<p>Hunterthomson: /* Search engines */ add example config</p>
<hr />
<div>{{DISPLAYTITLE:dwb}}<br />
[[Category:Web Browser]]<br />
[[de:dwb]]<br />
[[tr:dwb]]<br />
[http://portix.bitbucket.org/dwb/ dwb] is an extremely fast, lightweight and flexible web browser using the webkit engine. It is customizable through its web interface and fully usable with keyboard shortcuts.<br />
<br />
== Installation ==<br />
<br />
The {{Pkg|dwb}} package can be found in the [[official repositories]] and can be installed with [[pacman]]. There are also other versions in the [[AUR]]: {{AUR|dwb-git}}, {{AUR|dwb-gtk3}}, and {{AUR|dwb-gtk3-git}}.<br />
<br />
== Basic usage ==<br />
<br />
Starting from a fresh configuration, use {{ic|Sk}} to open the ''Keys'' page. As you can see from there, most bindings are borrowed from [[Vim]] and [[Emacs]].<br />
<br />
Use {{ic|:}} to access the command prompt. You can use {{ic|Tab}} to auto-complete.<br />
<br />
Read the man page for more details and enable the {{ic|auto-completion}} option in the settings to help you learn the bindings.<br />
<br />
$ man dwb<br />
<br />
=== dwb-specific ===<br />
<br />
o = enter url<br />
O = enter url in new tab<br />
f = spawn hints. Use arrow keys to browse the hints while displaying their URI, or use the hint letters.<br />
F = spawn hints in new tab<br />
;b = spawn hints in new background tab<br />
;r = follow multiple background links rapidly<br />
H = back<br />
L = forward<br />
J = go to next tab<br />
K = go to previous tab<br />
'n'+T = goto 'n' tab<br />
d = close tab<br />
u = undo close tab<br />
ctrl+s = stop<br />
r = reload<br />
R = reload ignoring cache<br />
gi = go to the first input field and enter insert mode<br />
ctrl+e = open editable field in external editor. Useful for forums and wikis.<br />
;d = download via hints<br />
M = save bookmark (bookmarks are saved in ~/.config/dwb/default/bookmarks)<br />
xb = show/hide status bar<br />
gf = toggle source view<br />
+ = zoom_in<br />
- = zoom_out<br />
= = reset to 100%<br />
<br />
=== vim-like ===<br />
<br />
i = toggle_insert_mode (Esc works to go back to normal mode much like Vim)<br />
Esc = back to normal mode (ctrl+n works too)<br />
j = scroll down<br />
k = scroll up<br />
h = scroll left<br />
l = scroll right<br />
gg = go to top<br />
G = go to bottom<br />
/ = find in page<br />
n = repeat find forward<br />
ZZ = save session and exit<br />
<br />
=== Notes ===<br />
<br />
Press {{ic|v}} to switch to caret browsing, then press {{ic|space}} to toggle between caret and visual mode. Press {{ic|Esc}} one or two times to go back to normal mode. While in caret browsing, you can use the arrow keys to browse the different parts of the page. Hold {{ic|Shift}} to select text. Press {{ic|Enter}} to follow links.<br />
<br />
== Configuration ==<br />
<br />
The configuration files are stored in {{ic|$XDG_CONFIG_HOME/dwb/}} (usually {{ic| ~/.config/dwb/}}) and can be easily accessed through the web interface. Type {{ic|Ss}} to open the ''Settings'' page.<br />
<br />
=== Search engines ===<br />
<br />
Open your favorite search engine, type {{ic|gs}} to select the web page's first input field, and then enter a keyword associated with it. <br />
<br />
Now you can use the keyword in the URI prompt to search directly on the corresponding website. Typing queries directly in the address bar will search with the default search engine, which is the first entry in {{ic|$XDG_CONFIG_HOME/dwb/searchengines}}.<br />
<br />
You can also add more by editing the configuration files.<br />
<br />
.config/dwb/settings to<br />
searchengine-submit-pattern=XXX<br />
<br />
.config/dwb/searchengines<br />
sp https://startpage.com/do/search?q=XXX<br />
wp https://en.wikipedia.org/w/index.php?search=XXX&title=Special:Search<br />
aw https://wiki.archlinux.org/index.php?title=Special:Search&search=XXX<br />
<br />
=== Custom keybinds ===<br />
<br />
You can create custom key bindings by editing file {{ic|custom_keys}} in the profile directory. This is<br />
{{ic|~/.config/dwb/default}} by default. All keysyms which don't emit (multi)byte characters, must be enclosed in {{ic|@}}. One keybind can execute multiple ''dwb'' commands. These commands execute in same order as they are defined in bind, and must be separated by {{ic|;;}} separator. If the keybind's chord is already bound by ''dwb'', it might be ignored (behaviour is not consistent). In such case one can try to check, whether there is collison with binds defined in {{ic|~/.config/dwb/keys}} and try to unbind the chord there (eg set it to nothing). Any running ''dwb'' instance will owerwrite {{ic|keys}} file on exit, so remember to do your modifications while ''dwb'' is not runing or use default ''dwb'' interface ({{ic|Sk}}).<br />
<br />
{{hc|~/.config/dwb/default/custom_keys|<nowiki><br />
Control w :close_tab<br />
Control @Page_Up@ :focus_prev<br />
Control @Page_Down@ :focus_next<br />
</nowiki>}}<br />
<br />
== Extensions ==<br />
<br />
''dwb'' features an extension manager as a separate executable, ''dwbem''. To list all officially available extensions, use:<br />
<br />
{{hc|dwbem -a|<br />
Available extensions: Mainstream equivalent:<br />
- adblock_subscriptions Adblock<br />
- autoquvi Video DownloadHelper<br />
- contenthandler (Handle requests based on MIME type, filename extension or URI scheme)<br />
- downloadhandler (Handle downloads based on mimetype or filename extension, useful if 'download-no-confirm' is set)<br />
- formfiller LastPass, Lazarus (Save form data and fill forms with previously saved data, also with gpg-support)<br />
- googlebookmarks GBookmarks, GMarks (Add bookmarks to google bookmarks with a shortcut)<br />
- googledocs Open with Google Docs, Google Docs Viewer<br />
- grabscrolling (Adobe Acrobat style grab and drag mouse scrolling)<br />
- multimarks (Bookmark multiple urls to a single quickmark)<br />
- navtools Opera Fast Forward, IE 10 Flip Ahead<br />
- perdomainsettings (Change webkit-settings automatically on domain or url basis)<br />
- pwdhash PwdHash<br />
- requestpolicy RequestPolicy, Disconnect, Ghostery<br />
- simplyread Readability, Clearly<br />
- speeddial Speed Dial<br />
- supergenpass (Generate domain-based passwords; compatible with the bookmarklet supergenpass but with additional options)<br />
- unique_tabs (Remove duplicate tabs or avoid duplicate tabs by autoswitching to tabs with same url)<br />
- userscripts GreaseMonkey/Stylish<br />
- whitelistshortcuts (Whitelist webkit settings for certain domains with a shortcut)<br />
}}<br />
<br />
For more details, use {{ic|dwbem -I <extension>}} and read the [http://portix.bitbucket.org/dwb/resources/dwb.1.html dwb] and [http://portix.bitbucket.org/dwb/resources/dwbem.1.html dwbem] man pages.<br />
<br />
Below is a list of popular extensions (or add-ons) for which ''dwb'' has a built-in alternative:<br />
<br />
* NoScript/Flashblock: ''dwb'' blocks flash by default and can block javascript.<br />
* Omnibar: just like Chrome, ''dwb'''s address gives quick access to search, history, and bookmarks.<br />
* Download Statusbar: ''dwb'''s displays downloads in a neat status bar by default.<br />
* IE Tab: ''dwb'' can open a page in any external browser with a simple userscript.<br />
* Session Manager: ''dwb'' uses its built-in session manager by default.<br />
* Private browsing: add {{ic|xpp:toggle enable-private-browsing}} to {{ic|custom_keys}} to toggle privacy mode by typing {{ic|xpp}}.<br />
<br />
=== Adblock ===<br />
<br />
''dwb'' features an Adblock extension. Install it with<br />
<br />
$ dwbem -i adblock_subscriptions<br />
<br />
Restart ''dwb'', enable adblocker with {{ic|:set adblocker true}}, use the ''adblock_subscribe'' command and choose your favorite filter (avoid using more than one filter to prevent duplicate entries that make the adblocker much slower).<br />
<br />
== Userscripts ==<br />
<br />
''dwb'' can execute .js or .sh scripts put in {{ic|~/.config/dwb/userscripts/}}. Make sure they are executable:<br />
chmod +x ~/.config/dwb/userscripts/myscript.js<br />
<br />
Below are some example scripts, see ''dwb'' [http://portix.bitbucket.org/dwb/snippets/snippets.html userscripts snippets] for more:<br />
<br />
=== defer-loading ===<br />
<br />
Prevents tabs from last session to load all at once at startup.<br />
{{hc|~/.config/dwb/userscripts/defer-loading.js|<nowiki><br />
//!javascript<br />
if (settings.loadOnFocus === false) {<br />
execute('local_set load-on-focus true');<br />
}<br />
Signal.connect('navigation', function(webview) {<br />
if (webview == tabs.current) {<br />
execute('local_set load-on-focus false');<br />
this.disconnect();<br />
}<br />
});</nowiki>}}<br />
<br />
=== fast-forward ===<br />
<br />
Opera features a neat key binding which allows users to load to next/previous logical page. This is very useful for forum threads, documentation, and articles spread over several pages.<br />
<br />
This feature can be implemented with a simple javascript function and bound to custom keys {{ic|<nowiki>}</nowiki>}} and {{ic|{}}:<br />
<br />
{{hc|~/.config/dwb/default/custom_keys|<nowiki><br />
}:exja (function(){var e=document.querySelector("[rel='next']");if(e){location=e.href;}else{var f=document.getElementsByTagName("a");var i=f.length;while((e=f[--i])){if(e.text.search(/(\bnext\b|^>$|^(>>|»)$|^(>|»)|(>|»)$|\bmore\b)/i)>-1){location=e.href; break;}} location.href=location.href.replace(/(\d+)([^\/\d]*)$/, function(a,b,c){return ++b+c})}})();<br />
{:exja (function(){var e=document.querySelector("[rel='prev']");if(e){location=e.href;}else{var f=document.getElementsByTagName("a");var i=f.length;while((e=f[--i])){if(e.text.search(/(\b(prev|previous)\b|^<$|^(<<|«)$|^(<|«)|(<|«)$)/i)>-1){location=e.href;break;}} location.href=location.href.replace(/(\d+)([^\/\d]*)$/, function(a,b,c){return --b+c})}})();<br />
</nowiki>}}<br />
<br />
Alternatively, the {{ic|navtools}} extension provides the same functionality and more, such as going up one directory, or loading the root URI.<br />
<br />
=== open-firefox ===<br />
Opens current page in Firefox with {{ic|xf}} (uses {{Pkg|firefox}} and {{Pkg|notify-send}}).<br />
{{hc|~/.config/dwb/userscripts/open-firefox.sh|<nowiki><br />
#!/bin/bash<br />
# dwb: xf<br />
firefox $DWB_URI &<br />
notify-send -u low "Firefox opening $DWB_URI" #optional notification<br />
</nowiki>}}<br />
<br />
=== startup-noautoreload ===<br />
<br />
Prevents previously-opened tabs from reloading all at once after a restart.<br />
{{hc|~/.config/dwb/userscripts/startup-noautoreload.js|<nowiki><br />
//!javascript<br />
// prevents previously-opened tabs from reloading all at once after a restart.<br />
execute("set load-on-focus true");<br />
<br />
var sigId = Signal.connect("navigation", function(wv) {<br />
if (wv == tabs.current)<br />
{<br />
execute("set load-on-focus false");<br />
Signal.disconnect(sigId);<br />
}<br />
});</nowiki>}}<br />
<br />
=== toggle-stylesheet ===<br />
<br />
Toggles between 2 global stylesheets with {{ic|xg}}.<br />
{{hc|~/.config/dwb/userscripts/toggle-stylesheet.sh|<nowiki><br />
#!/bin/bash<br />
# dwb:xg<br />
<br />
CURRENT_STYLESHEET="$(dwbremote get setting user-stylesheet-uri)"<br />
<br />
STYLESHEET_1="file://$HOME/.config/dwb/stylesheets/foo.css"<br />
STYLESHEET_2="file://$HOME/.config/dwb/stylesheets/bar.css"<br />
<br />
if [[ "${CURRENT_STYLESHEET}" = ${STYLESHEET_1} ]]; then<br />
dwbremote :local_set user-stylesheet-uri "$STYLESHEET_2"<br />
else <br />
dwbremote :local_set user-stylesheet-uri "$STYLESHEET_1"<br />
fi</nowiki>}}<br />
<br />
=== youtube-player ===<br />
<br />
Opens YouTube videos with MPlayer (uses {{Pkg|mplayer}} and {{Pkg|youtube-dl}}).<br />
{{hc|~/.config/dwb/userscripts/youtube-mplayer.js|<nowiki><br />
//!javascript <br />
// opens YouTube videos with mplayer.<br />
var regex = new RegExp("http(.*)://www.youtube.com/watch\\?(.*&)*v=.*");<br />
<br />
signals.connect("navigation", function (wv, frame, request) {<br />
if (wv.mainFrame == frame && regex.test(request.uri)) <br />
system.spawn("sh -c 'mplayer \"$(youtube-dl -g " + request.uri + ")\"'");<br />
return false;<br />
});</nowiki>}}<br />
<br />
=== rocker gestures ===<br />
<br />
Enables Opera-like rocker gestures for navigating the history. Disable the context menu in the settings first.<br />
{{hc|~/.config/dwb/userscripts/rocker.js|<nowiki><br />
//!javascript<br />
var LMB = 1, MMB=2, RMB = 3, UNKNOWN = 10, DOWN = 11, UP = 12;<br />
<br />
var buttonStates = [UNKNOWN, UNKNOWN, UNKNOWN, UNKNOWN, UNKNOWN, UNKNOWN];<br />
var bp = new Signal("onButtonPress", function(wv, result, ev) {<br />
var mouseButton = ev.button;<br />
<br />
buttonStates[mouseButton] = DOWN;<br />
<br />
if (mouseButton == LMB && buttonStates[RMB] == DOWN) {<br />
execute("history_back");<br />
} else if (mouseButton == RMB && buttonStates[LMB] == DOWN) {<br />
execute("history_forward");<br />
}<br />
});<br />
var br = new Signal("onButtonRelease", function(wv, result, ev) {<br />
buttonStates[ev.button] = UP;<br />
});<br />
<br />
bp.connect();<br />
br.connect();</nowiki>}}<br />
<br />
== Stylesheet ==<br />
<br />
a global stylesheet can be defined in the Settings, under {{ic|user-stylesheet-uri}} (i.e. {{ic|file:///home/tux/.config/dwb/stylesheet.css}})<br />
<br />
If you browse with the status bar hidden and are annoyed by the the link previews that appear while hovering over links with the mouse, add this to the stylesheet: {{ic|#dwb_hover_element { display:none!important; }}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== HTML5 audio and video does not work ===<br />
<br />
Make sure you have the following GStreamer packages installed:<br />
# pacman -S --needed gstreamer0.10 gstreamer0.10-bad gstreamer0.10-bad-plugins gstreamer0.10-base gstreamer0.10-base-plugins gstreamer0.10-good gstreamer0.10-good-plugins gstreamer0.10-ugly gstreamer0.10-ugly-plugins gstreamer0.10-ffmpeg<br />
<br />
=== Search engines search for ''undefined'' ===<br />
<br />
If you are always searching for ''undefined'' even with the {{ic|searchengine-submit-pattern}} option set, then you should edit {{ic|$XDG_CONFIG_HOME/dwb/searchengines}} and adapt the URIs to match your {{ic|searchengine-submit-pattern}}.<br />
<br />
=== Fuzzy font in Github ===<br />
<br />
Add this in your {{ic|~/.config/fontconfig/fonts.conf}} inside the fontconfig-tags:<br />
<br />
<selectfont><br />
<rejectfont><br />
<pattern><br />
<patelt name="family"><br />
<string>Clean</string><br />
</patelt><br />
</pattern><br />
</rejectfont><br />
</selectfont><br />
<br />
== dwb-git ==<br />
<br />
[https://aur.archlinux.org/packages/dwb-git dwb-git] offers many improvements over the stable version. Most the most notable of which are listed below.<br />
<br />
=== Plugin Support ===<br />
<br />
Browser Plugins can be enabled and disabled through the new [dwb:plugins dwb:plugins] settings page. Other [https://wiki.archlinux.org/index.php/Browser_Plugins Browser Plugins] may be supported as well, but these two alone will make your dwb experience much more enjoyable.<br />
<br />
==== Flash Support ====<br />
<br />
[https://aur.archlinux.org/packages/dwb-git dwb-git] has built in support for the [https://www.archlinux.org/packages/?name=flashplugin flashplugin]. Dwb should auto-detect and enabled the plugin after it is installed.<br />
<br />
==== Java Support ====<br />
<br />
[https://aur.archlinux.org/packages/dwb-git dwb-git] has built in support for the [https://www.archlinux.org/packages/?name=icedtea-web-java7 icedtea-web-java7]. Dwb should auto-detect and enable the plugin after it is installed.<br />
<br />
=== Improved Ability to Display Websites ===<br />
<br />
If you are having problems with they layout of websites not loading correctly then give [https://aur.archlinux.org/packages/dwb-git dwb-git] a shot.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Dwb&diff=294599Dwb2014-01-27T09:45:39Z<p>Hunterthomson: Added a few notes about what dwb-git has to offer i.e. Flash, Java, better loading of CSS</p>
<hr />
<div>{{DISPLAYTITLE:dwb}}<br />
[[Category:Web Browser]]<br />
[[de:dwb]]<br />
[[tr:dwb]]<br />
[http://portix.bitbucket.org/dwb/ dwb] is an extremely fast, lightweight and flexible web browser using the webkit engine. It is customizable through its web interface and fully usable with keyboard shortcuts.<br />
<br />
== Installation ==<br />
<br />
The {{Pkg|dwb}} package can be found in the [[official repositories]] and can be installed with [[pacman]]. There are also other versions in the [[AUR]]: {{AUR|dwb-git}}, {{AUR|dwb-gtk3}}, and {{AUR|dwb-gtk3-git}}.<br />
<br />
== Basic usage ==<br />
<br />
Starting from a fresh configuration, use {{ic|Sk}} to open the ''Keys'' page. As you can see from there, most bindings are borrowed from [[Vim]] and [[Emacs]].<br />
<br />
Use {{ic|:}} to access the command prompt. You can use {{ic|Tab}} to auto-complete.<br />
<br />
Read the man page for more details and enable the {{ic|auto-completion}} option in the settings to help you learn the bindings.<br />
<br />
$ man dwb<br />
<br />
=== dwb-specific ===<br />
<br />
o = enter url<br />
O = enter url in new tab<br />
f = spawn hints. Use arrow keys to browse the hints while displaying their URI, or use the hint letters.<br />
F = spawn hints in new tab<br />
;b = spawn hints in new background tab<br />
;r = follow multiple background links rapidly<br />
H = back<br />
L = forward<br />
J = go to next tab<br />
K = go to previous tab<br />
'n'+T = goto 'n' tab<br />
d = close tab<br />
u = undo close tab<br />
ctrl+s = stop<br />
r = reload<br />
R = reload ignoring cache<br />
gi = go to the first input field and enter insert mode<br />
ctrl+e = open editable field in external editor. Useful for forums and wikis.<br />
;d = download via hints<br />
M = save bookmark (bookmarks are saved in ~/.config/dwb/default/bookmarks)<br />
xb = show/hide status bar<br />
gf = toggle source view<br />
+ = zoom_in<br />
- = zoom_out<br />
= = reset to 100%<br />
<br />
=== vim-like ===<br />
<br />
i = toggle_insert_mode (Esc works to go back to normal mode much like Vim)<br />
Esc = back to normal mode (ctrl+n works too)<br />
j = scroll down<br />
k = scroll up<br />
h = scroll left<br />
l = scroll right<br />
gg = go to top<br />
G = go to bottom<br />
/ = find in page<br />
n = repeat find forward<br />
ZZ = save session and exit<br />
<br />
=== Notes ===<br />
<br />
Press {{ic|v}} to switch to caret browsing, then press {{ic|space}} to toggle between caret and visual mode. Press {{ic|Esc}} one or two times to go back to normal mode. While in caret browsing, you can use the arrow keys to browse the different parts of the page. Hold {{ic|Shift}} to select text. Press {{ic|Enter}} to follow links.<br />
<br />
== Configuration ==<br />
<br />
The configuration files are stored in {{ic|$XDG_CONFIG_HOME/dwb/}} (usually {{ic| ~/.config/dwb/}}) and can be easily accessed through the web interface. Type {{ic|Ss}} to open the ''Settings'' page.<br />
<br />
=== Search engines ===<br />
<br />
Open your favorite search engine, type {{ic|gs}} to select the web page's first input field, and then enter a keyword associated with it. <br />
<br />
Now you can use the keyword in the URI prompt to search directly on the corresponding website. Typing queries directly in the address bar will search with the default search engine, which is the first entry in {{ic|$XDG_CONFIG_HOME/dwb/searchengines}}.<br />
<br />
=== Custom keybinds ===<br />
<br />
You can create custom key bindings by editing file {{ic|custom_keys}} in the profile directory. This is<br />
{{ic|~/.config/dwb/default}} by default. All keysyms which don't emit (multi)byte characters, must be enclosed in {{ic|@}}. One keybind can execute multiple ''dwb'' commands. These commands execute in same order as they are defined in bind, and must be separated by {{ic|;;}} separator. If the keybind's chord is already bound by ''dwb'', it might be ignored (behaviour is not consistent). In such case one can try to check, whether there is collison with binds defined in {{ic|~/.config/dwb/keys}} and try to unbind the chord there (eg set it to nothing). Any running ''dwb'' instance will owerwrite {{ic|keys}} file on exit, so remember to do your modifications while ''dwb'' is not runing or use default ''dwb'' interface ({{ic|Sk}}).<br />
<br />
{{hc|~/.config/dwb/default/custom_keys|<nowiki><br />
Control w :close_tab<br />
Control @Page_Up@ :focus_prev<br />
Control @Page_Down@ :focus_next<br />
</nowiki>}}<br />
<br />
== Extensions ==<br />
<br />
''dwb'' features an extension manager as a separate executable, ''dwbem''. To list all officially available extensions, use:<br />
<br />
{{hc|dwbem -a|<br />
Available extensions: Mainstream equivalent:<br />
- adblock_subscriptions Adblock<br />
- autoquvi Video DownloadHelper<br />
- contenthandler (Handle requests based on MIME type, filename extension or URI scheme)<br />
- downloadhandler (Handle downloads based on mimetype or filename extension, useful if 'download-no-confirm' is set)<br />
- formfiller LastPass, Lazarus (Save form data and fill forms with previously saved data, also with gpg-support)<br />
- googlebookmarks GBookmarks, GMarks (Add bookmarks to google bookmarks with a shortcut)<br />
- googledocs Open with Google Docs, Google Docs Viewer<br />
- grabscrolling (Adobe Acrobat style grab and drag mouse scrolling)<br />
- multimarks (Bookmark multiple urls to a single quickmark)<br />
- navtools Opera Fast Forward, IE 10 Flip Ahead<br />
- perdomainsettings (Change webkit-settings automatically on domain or url basis)<br />
- pwdhash PwdHash<br />
- requestpolicy RequestPolicy, Disconnect, Ghostery<br />
- simplyread Readability, Clearly<br />
- speeddial Speed Dial<br />
- supergenpass (Generate domain-based passwords; compatible with the bookmarklet supergenpass but with additional options)<br />
- unique_tabs (Remove duplicate tabs or avoid duplicate tabs by autoswitching to tabs with same url)<br />
- userscripts GreaseMonkey/Stylish<br />
- whitelistshortcuts (Whitelist webkit settings for certain domains with a shortcut)<br />
}}<br />
<br />
For more details, use {{ic|dwbem -I <extension>}} and read the [http://portix.bitbucket.org/dwb/resources/dwb.1.html dwb] and [http://portix.bitbucket.org/dwb/resources/dwbem.1.html dwbem] man pages.<br />
<br />
Below is a list of popular extensions (or add-ons) for which ''dwb'' has a built-in alternative:<br />
<br />
* NoScript/Flashblock: ''dwb'' blocks flash by default and can block javascript.<br />
* Omnibar: just like Chrome, ''dwb'''s address gives quick access to search, history, and bookmarks.<br />
* Download Statusbar: ''dwb'''s displays downloads in a neat status bar by default.<br />
* IE Tab: ''dwb'' can open a page in any external browser with a simple userscript.<br />
* Session Manager: ''dwb'' uses its built-in session manager by default.<br />
* Private browsing: add {{ic|xpp:toggle enable-private-browsing}} to {{ic|custom_keys}} to toggle privacy mode by typing {{ic|xpp}}.<br />
<br />
=== Adblock ===<br />
<br />
''dwb'' features an Adblock extension. Install it with<br />
<br />
$ dwbem -i adblock_subscriptions<br />
<br />
Restart ''dwb'', enable adblocker with {{ic|:set adblocker true}}, use the ''adblock_subscribe'' command and choose your favorite filter (avoid using more than one filter to prevent duplicate entries that make the adblocker much slower).<br />
<br />
== Userscripts ==<br />
<br />
''dwb'' can execute .js or .sh scripts put in {{ic|~/.config/dwb/userscripts/}}. Make sure they are executable:<br />
chmod +x ~/.config/dwb/userscripts/myscript.js<br />
<br />
Below are some example scripts, see ''dwb'' [http://portix.bitbucket.org/dwb/snippets/snippets.html userscripts snippets] for more:<br />
<br />
=== defer-loading ===<br />
<br />
Prevents tabs from last session to load all at once at startup.<br />
{{hc|~/.config/dwb/userscripts/defer-loading.js|<nowiki><br />
//!javascript<br />
if (settings.loadOnFocus === false) {<br />
execute('local_set load-on-focus true');<br />
}<br />
Signal.connect('navigation', function(webview) {<br />
if (webview == tabs.current) {<br />
execute('local_set load-on-focus false');<br />
this.disconnect();<br />
}<br />
});</nowiki>}}<br />
<br />
=== fast-forward ===<br />
<br />
Opera features a neat key binding which allows users to load to next/previous logical page. This is very useful for forum threads, documentation, and articles spread over several pages.<br />
<br />
This feature can be implemented with a simple javascript function and bound to custom keys {{ic|<nowiki>}</nowiki>}} and {{ic|{}}:<br />
<br />
{{hc|~/.config/dwb/default/custom_keys|<nowiki><br />
}:exja (function(){var e=document.querySelector("[rel='next']");if(e){location=e.href;}else{var f=document.getElementsByTagName("a");var i=f.length;while((e=f[--i])){if(e.text.search(/(\bnext\b|^>$|^(>>|»)$|^(>|»)|(>|»)$|\bmore\b)/i)>-1){location=e.href; break;}} location.href=location.href.replace(/(\d+)([^\/\d]*)$/, function(a,b,c){return ++b+c})}})();<br />
{:exja (function(){var e=document.querySelector("[rel='prev']");if(e){location=e.href;}else{var f=document.getElementsByTagName("a");var i=f.length;while((e=f[--i])){if(e.text.search(/(\b(prev|previous)\b|^<$|^(<<|«)$|^(<|«)|(<|«)$)/i)>-1){location=e.href;break;}} location.href=location.href.replace(/(\d+)([^\/\d]*)$/, function(a,b,c){return --b+c})}})();<br />
</nowiki>}}<br />
<br />
Alternatively, the {{ic|navtools}} extension provides the same functionality and more, such as going up one directory, or loading the root URI.<br />
<br />
=== open-firefox ===<br />
Opens current page in Firefox with {{ic|xf}} (uses {{Pkg|firefox}} and {{Pkg|notify-send}}).<br />
{{hc|~/.config/dwb/userscripts/open-firefox.sh|<nowiki><br />
#!/bin/bash<br />
# dwb: xf<br />
firefox $DWB_URI &<br />
notify-send -u low "Firefox opening $DWB_URI" #optional notification<br />
</nowiki>}}<br />
<br />
=== startup-noautoreload ===<br />
<br />
Prevents previously-opened tabs from reloading all at once after a restart.<br />
{{hc|~/.config/dwb/userscripts/startup-noautoreload.js|<nowiki><br />
//!javascript<br />
// prevents previously-opened tabs from reloading all at once after a restart.<br />
execute("set load-on-focus true");<br />
<br />
var sigId = Signal.connect("navigation", function(wv) {<br />
if (wv == tabs.current)<br />
{<br />
execute("set load-on-focus false");<br />
Signal.disconnect(sigId);<br />
}<br />
});</nowiki>}}<br />
<br />
=== toggle-stylesheet ===<br />
<br />
Toggles between 2 global stylesheets with {{ic|xg}}.<br />
{{hc|~/.config/dwb/userscripts/toggle-stylesheet.sh|<nowiki><br />
#!/bin/bash<br />
# dwb:xg<br />
<br />
CURRENT_STYLESHEET="$(dwbremote get setting user-stylesheet-uri)"<br />
<br />
STYLESHEET_1="file://$HOME/.config/dwb/stylesheets/foo.css"<br />
STYLESHEET_2="file://$HOME/.config/dwb/stylesheets/bar.css"<br />
<br />
if [[ "${CURRENT_STYLESHEET}" = ${STYLESHEET_1} ]]; then<br />
dwbremote :local_set user-stylesheet-uri "$STYLESHEET_2"<br />
else <br />
dwbremote :local_set user-stylesheet-uri "$STYLESHEET_1"<br />
fi</nowiki>}}<br />
<br />
=== youtube-player ===<br />
<br />
Opens YouTube videos with MPlayer (uses {{Pkg|mplayer}} and {{Pkg|youtube-dl}}).<br />
{{hc|~/.config/dwb/userscripts/youtube-mplayer.js|<nowiki><br />
//!javascript <br />
// opens YouTube videos with mplayer.<br />
var regex = new RegExp("http(.*)://www.youtube.com/watch\\?(.*&)*v=.*");<br />
<br />
signals.connect("navigation", function (wv, frame, request) {<br />
if (wv.mainFrame == frame && regex.test(request.uri)) <br />
system.spawn("sh -c 'mplayer \"$(youtube-dl -g " + request.uri + ")\"'");<br />
return false;<br />
});</nowiki>}}<br />
<br />
=== rocker gestures ===<br />
<br />
Enables Opera-like rocker gestures for navigating the history. Disable the context menu in the settings first.<br />
{{hc|~/.config/dwb/userscripts/rocker.js|<nowiki><br />
//!javascript<br />
var LMB = 1, MMB=2, RMB = 3, UNKNOWN = 10, DOWN = 11, UP = 12;<br />
<br />
var buttonStates = [UNKNOWN, UNKNOWN, UNKNOWN, UNKNOWN, UNKNOWN, UNKNOWN];<br />
var bp = new Signal("onButtonPress", function(wv, result, ev) {<br />
var mouseButton = ev.button;<br />
<br />
buttonStates[mouseButton] = DOWN;<br />
<br />
if (mouseButton == LMB && buttonStates[RMB] == DOWN) {<br />
execute("history_back");<br />
} else if (mouseButton == RMB && buttonStates[LMB] == DOWN) {<br />
execute("history_forward");<br />
}<br />
});<br />
var br = new Signal("onButtonRelease", function(wv, result, ev) {<br />
buttonStates[ev.button] = UP;<br />
});<br />
<br />
bp.connect();<br />
br.connect();</nowiki>}}<br />
<br />
== Stylesheet ==<br />
<br />
a global stylesheet can be defined in the Settings, under {{ic|user-stylesheet-uri}} (i.e. {{ic|file:///home/tux/.config/dwb/stylesheet.css}})<br />
<br />
If you browse with the status bar hidden and are annoyed by the the link previews that appear while hovering over links with the mouse, add this to the stylesheet: {{ic|#dwb_hover_element { display:none!important; }}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== HTML5 audio and video does not work ===<br />
<br />
Make sure you have the following GStreamer packages installed:<br />
# pacman -S --needed gstreamer0.10 gstreamer0.10-bad gstreamer0.10-bad-plugins gstreamer0.10-base gstreamer0.10-base-plugins gstreamer0.10-good gstreamer0.10-good-plugins gstreamer0.10-ugly gstreamer0.10-ugly-plugins gstreamer0.10-ffmpeg<br />
<br />
=== Search engines search for ''undefined'' ===<br />
<br />
If you are always searching for ''undefined'' even with the {{ic|searchengine-submit-pattern}} option set, then you should edit {{ic|$XDG_CONFIG_HOME/dwb/searchengines}} and adapt the URIs to match your {{ic|searchengine-submit-pattern}}.<br />
<br />
=== Fuzzy font in Github ===<br />
<br />
Add this in your {{ic|~/.config/fontconfig/fonts.conf}} inside the fontconfig-tags:<br />
<br />
<selectfont><br />
<rejectfont><br />
<pattern><br />
<patelt name="family"><br />
<string>Clean</string><br />
</patelt><br />
</pattern><br />
</rejectfont><br />
</selectfont><br />
<br />
== dwb-git ==<br />
<br />
[https://aur.archlinux.org/packages/dwb-git dwb-git] offers many improvements over the stable version. Most the most notable of which are listed below.<br />
<br />
=== Plugin Support ===<br />
<br />
Browser Plugins can be enabled and disabled through the new [dwb:plugins dwb:plugins] settings page. Other [https://wiki.archlinux.org/index.php/Browser_Plugins Browser Plugins] may be supported as well, but these two alone will make your dwb experience much more enjoyable.<br />
<br />
==== Flash Support ====<br />
<br />
[https://aur.archlinux.org/packages/dwb-git dwb-git] has built in support for the [https://www.archlinux.org/packages/?name=flashplugin flashplugin]. Dwb should auto-detect and enabled the plugin after it is installed.<br />
<br />
==== Java Support ====<br />
<br />
[https://aur.archlinux.org/packages/dwb-git dwb-git] has built in support for the [https://www.archlinux.org/packages/?name=icedtea-web-java7 icedtea-web-java7]. Dwb should auto-detect and enable the plugin after it is installed.<br />
<br />
=== Improved Ability to Display Websites ===<br />
<br />
If you are having problems with they layout of websites not loading correctly then give [https://aur.archlinux.org/packages/dwb-git dwb-git] a shot.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Working_with_the_serial_console&diff=287682Working with the serial console2013-12-12T05:52:08Z<p>Hunterthomson: /* Configuration */</p>
<hr />
<div>[[Category:Other hardware]]<br />
Configure your Arch Linux machine so you can connect to it via the serial console port (com port).<br />
This will enable you to administer the machine even if it has no keyboard, mouse, monitor, or network attached to it (a headless server).<br />
<br />
As of Arch Linux 2007.x, installation of Arch Linux is possible via the serial console as well.<br />
<br />
A basic environment for this scenario is two machines connected using a serial cable (9-pin connector cable).<br />
The administering machine can be any Linux or Windows machine with a terminal emulator program (PuTTY or Minicom, for example).<br />
<br />
The configuration instructions below will enable GRUB menu selection, boot messages, and terminal forwarding to the serial console.<br />
<br />
==Configuration==<br />
<br />
===Configure console access on the target machine===<br />
<br />
====GRUB2 and systemd====<br />
<br />
If you configure the serial console in GRUB2 systemd will create a getty listener on the same serial device as GRUB2 by default. So, this is the only configuration needed for Arch running with systemd.<br />
<br><br><br />
Edit /etc/default/grub<br />
<br><br><br />
1. Edit the GRUB_CMDLINE_DEFAULT="" line to start the console on /dev/ttyS0<br><br />
{{ic|<nowiki><br />
GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,38400n8"<br />
</nowiki>}}<br />
<br><br><br />
2. Add a serial console section<br><br />
{{ic|<nowiki><br />
# Serial console</nowiki><br><br />
<nowiki>GRUB_TERMINAL=serial</nowiki><br><br />
<nowiki>GRUB_SERIAL_COMMAND="serial --speed=38400 --unit=0 --word=8 --parity=no --stop=1"<br />
</nowiki>}}<br />
<br><br><br />
3. Rebuild the grub.cfg file<br><br />
{{ic|<nowiki><br />
grub-mkconfig > /boot/grub/grub.cfg<br />
</nowiki>}}<br />
<br><br><br />
Now you are done. After reboot getty will be listening on device /dev/ttyS0 with settings 38400 8N1 and systemd will automatically start a getty session to listen on the same device with the same settings.<br />
<br />
=====Without GRUB2, systemd only=====<br />
This step is not needed if you have configured GRUB2 to listen on the serial interface. If you do not want GRUB2 to listen on the serial device, but only want getty listening after boot then follow these steps.<br />
<br><br><br />
1. To start getty listening on /dev/ttyS0 use systemctl<br><br />
{{ic|<nowiki><br />
systemctl start getty@ttyS0.service<br />
</nowiki>}}<br />
<br><br><br />
You can check to see the speed getty is useing with systemctl, but should be 38400 8N1<br><br />
{{ic|<nowiki><br />
systemctl status serial-getty@ttyS0.service<br />
</nowiki>}}<br />
<br><br><br />
2. To have getty listening on /dev/ttyS0 every boot create this symlink<br />
{{ic|<nowiki><br />
ln -s /usr/lib/systemd/system/serial-getty@.service /etc/systemd/system/getty.target.wants/serial-getty@ttyS0.service<br />
</nowiki>}}<br />
<br><br><br />
Now after reboot getty will be listening on device /dev/ttyS0 with settings 38400 8N1<br />
<br />
====GRUB v1 and No systemd====<br />
<br />
1. Edit the GRUB config file:<br />
<br />
vi /boot/grub/menu.lst<br />
<br />
Add these lines to the general area of the configuration:<br />
<br />
{{ic|<nowiki><br />
serial --unit=0 --speed=9600</nowiki><br><br />
<nowiki>terminal --timeout=5 serial console</nowiki><br />
}}<br />
<br />
Add the console parameters at the end of your current kernel line:<br />
<br />
{{ic|<nowiki><br />
console=tty0 console=ttyS0,9600<br />
</nowiki>}}<br />
<br />
For example, the kernel line should look something like this after modification:<br />
<br />
{{ic|<nowiki><br />
kernel /vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda3,/dev/sdb3 vga=773 console=tty0 console=ttyS0,9600<br />
</nowiki>}}<br />
<br />
{{note|When the {{ic|<nowiki>terminal --timeout=5 serial console</nowiki>}} line is added to your menu.lst grub configuration, your boot sequence will now show a series of "Press any key to continue" messages. If no key is pressed, the boot menu will appear on whichever (serial or console) appears first in the 'terminal' configuration line. The lines will look like this upon boot:}}<br />
<br />
{{ic|<br />
Press any key to continue.<br><br />
Press any key to continue.<br><br />
Press any key to continue.<br><br />
Press any key to continue.<br><br />
Press any key to continue.<br><br />
Press any key to continue.<br><br />
Press any key to continue.<br />
}}<br />
<br />
2. Edit the inittab file: <br />
<br />
vi /etc/inittab<br />
<br />
Add a new agetty line below the existing ones:<br />
<br />
{{ic|<br />
c0:2345:respawn:/sbin/agetty 9600 ttyS0 linux<br />
}}<br />
<br />
3. Edit the securetty file:<br />
<br />
vi /etc/securetty<br />
<br />
Below the existing ttys, add an entry for the the serial console:<br />
<br />
{{ic|<br />
ttyS0<br />
}}<br />
<br />
4. Reboot the machine<br />
<br />
{{note|In all of the steps above, ttyS1 can also be used in case your machine has more than one serial port.}}<br />
<br />
==Making Connections==<br />
<br />
===Connect using a terminal emulator program===<br />
<br />
Perform these steps on the machine used to connect the remote console.<br />
<br />
====Minicom====<br />
<br />
1. Install {{Pkg|Minicom}}:<br />
<br />
pacman -S minicom<br />
<br />
2. Start Minicom in setup mode:<br />
<br />
minicom -s<br />
<br />
3. Using the textual navigation menu, change the serial port settings to the following:<br />
<br />
{{ic|<br />
Serial Device: /dev/ttyS0<br><br />
Bps/Par/Bits: 9600 8N1<br />
}}<br />
<br />
Press Enter to exit the menus (pressing Esc will not save changes).<br />
<br />
4. Remove the modem Init and Reset strings:<br />
<br />
Under the 'Modem and Dialing' menu, delete the Init and Reset strings.<br />
<br />
5. Save the setup:<br />
<br />
From the main menu, choose 'save setup as dfl'.<br />
<br />
6. Exit Minicom:<br />
<br />
From the main menu, choose 'Exit from Minicom'.<br />
<br />
7. Connect to the target machine:<br />
<br />
While the serial cable is connected to the target machine, start the Minicom program:<br />
<br />
minicom<br />
<br />
8. Exiting Minicom<br />
<br />
To finish the session, press 'ctrl-A' and then 'X'.<br />
<br />
====Screen====<br />
<br />
Screen is able to connect to a serial port. It will connect to a standard 9600 speed port without options.<br />
<br />
screen /dev/ttyS0<br />
<br />
If needed, see the section "WINDOW TYPES" in the screen man page for details on setting the baud rate.<br />
<br />
====Serialclient====<br />
<br />
Serialclient[https://github.com/flagos/serialclient] is a client for serial connection in command line in your shell. Install it doing:<br />
pacman -S ruby<br />
gem install serialclient<br />
<br />
Then, you can use like this:<br />
serialclient -p /dev/ttyS0<br />
<br />
====Windows Options====<br />
<br />
On Windows machines, connect to the serial port using programs like PuTTY or Hyper Terminal.<br />
<br />
==Installing Arch Linux using the serial console==<br />
<br />
1. Connect to the target machine using the method described above.<br />
<br />
2. Boot the target machine using the Arch Linux installation CD.<br />
<br />
3. When the bootloader appears, select "Boot Arch Linux (<arch>)" and press tab to edit<br />
<br />
4. Append {{ic|1=console=ttyS0}} and press enter<br />
<br />
5. Systemd should now detect ttyS0 and spawn a serial getty on it, allowing you to proceed as usual<br />
<br />
{{note|After setup is complete, the console settings will not be saved on the target machine; in order to avoid having to connect a keyboard and monitor, configure console access on the target machine before rebooting.}}<br />
<br />
{{note|While a port speed of 9600 is used in all of the examples in this document, working with higher values is recommended (List of available speeds is displayed in Minicom by pressing 'Ctrl-A' and then 'P')}}<br />
<br />
==Troubleshooting==<br />
===Ctrl-C and Minicom===<br />
If you are having trouble sending a Control-C command through minicom you need to switch off hardware flow control in the device settings (minicom -s), which then enables the break.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Sudo&diff=285342Sudo2013-11-30T05:07:49Z<p>Hunterthomson: /* Harden with Sudo Example */ how did these darn tabs get in there?</p>
<hr />
<div>[[Category:Security]]<br />
[[cs:Sudo]]<br />
[[es:Sudo]]<br />
[[fr:Sudo]]<br />
[[it:Sudo]]<br />
[[ja:Sudo]]<br />
[[ru:Sudo]]<br />
[[sr:Sudo]]<br />
[[tr:Sudo]]<br />
[[uk:Sudo]]<br />
[[zh-CN:Sudo]]<br />
{{Related articles start}}<br />
{{Related|Users and Groups}}<br />
{{Related|su}}<br />
{{Related articles end}}<br />
<br />
[http://www.gratisoft.us/sudo/ sudo] ("substitute user do") allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments.<br />
<br />
== Rationale ==<br />
<br />
Sudo is an alternative to [[su]] for running commands as root. Unlike [[su]], which launches a root shell that allows all further commands root access, sudo instead grants temporary privilege escalation to a single command. By enabling root privileges only when needed, sudo usage reduces the likelyhood that a typo or a bug in an invoked command will ruin the system.<br />
Sudo can also be used to run commands as other users; additionally, sudo logs all commands and failed access attempts for security auditing.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|sudo}} package, available in the [[Official Repositories|official repositories]]:<br />
<br />
# pacman -S sudo<br />
<br />
To begin using {{ic|sudo}} as a non-privileged user, it must be properly configured. So make sure you read the configuration section.<br />
<br />
== Usage ==<br />
<br />
With sudo, users can prefix commands with {{ic|sudo}} to run them with superuser (or other) privileges.<br />
<br />
For example, to use pacman:<br />
<br />
$ sudo pacman -Syu<br />
<br />
See the [http://www.gratisoft.us/sudo/man/sudo.html sudo manual] for more information.<br />
<br />
== Configuration ==<br />
<br />
=== View current settings ===<br />
<br />
Run {{ic|sudo -ll}} to print out the current sudo configuration.<br />
<br />
=== Using visudo ===<br />
<br />
The configuration file for sudo is {{ic|/etc/sudoers}}. It should '''always''' be edited with the {{ic|visudo}} command. {{ic|visudo}} locks the {{ic|sudoers}} file, saves edits to a temporary file, and checks that file's grammar before copying it to {{ic|/etc/sudoers}}.<br />
<br />
{{Warning|It is imperative that {{ic|sudoers}} be free of syntax errors! Any error makes sudo unusable. '''Always''' edit it with {{ic|visudo}} to prevent errors.}}<br />
<br />
The default editor for visudo is {{ic|vi}}. It will be used if you do not specify another editor, by setting either VISUAL or EDITOR environment variables (used in that order) to the desired editor, e.g. {{ic|nano}}. The command is run as root:<br />
<br />
# EDITOR=nano visudo<br />
<br />
You can permanently change the setting for your user to e.g. {{ic|nano}} by appending:<br />
<br />
export EDITOR=nano<br />
<br />
to your {{ic|~/.bashrc}} file. Note that this won't take effect for already-running shells.<br />
<br />
To change the editor of choice permanently system-wide only for {{ic|visudo}}, add the following line to {{ic|/etc/sudoers}} where {{ic|nano}} is your prefered editor:<br />
<br />
# Reset environment by default<br />
Defaults env_reset<br />
# Set default EDITOR to nano, and do not allow visudo to use EDITOR/VISUAL.<br />
Defaults editor=/usr/bin/nano, !env_editor<br />
<br />
=== Example Entries ===<br />
<br />
To allow a user to gain full root privileges when he/she precedes a command with {{ic|sudo}}, add the following line:<br />
<br />
USER_NAME ALL=(ALL) ALL<br />
<br />
To allow a user to run all commands as any user but only the machine with hostname HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=(ALL) ALL<br />
<br />
To allow members of group {{ic|wheel}} sudo access:<br />
<br />
%wheel ALL=(ALL) ALL<br />
<br />
To disable asking for a password for user USER_NAME:<br />
<br />
Defaults:USER_NAME !authenticate<br />
<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=/usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
{{note| the most customized option should go at the end of the file, as the later lines overrides the previous ones. In particular such a line should be after the {{ic|%wheel}} line if your user is in this group.}}<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME without password:<br />
USER_NAME HOST_NAME= NOPASSWD: /usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
<br />
A detailed sudoers example can be found [http://www.gratisoft.us/sudo/sample.sudoers here]. Otherwise, see the [http://www.gratisoft.us/sudo/man/sudoers.html sudoers manual] for detailed information.<br />
<br />
=== Sudoers default file permissions ===<br />
<br />
The owner and group for the sudoers file must both be 0. The file permissions must be set to 0440. These permissions are set by default, but if you accidentally change them, they should be changed back immediately or sudo will fail.<br />
<br />
# chown -c root:root /etc/sudoers<br />
# chmod -c 0440 /etc/sudoers<br />
<br />
=== Password cache timeout ===<br />
<br />
Users may wish to change the default timeout before the cached password expires. This is accomplished with the timestamp_timeout option in {{ic|/etc/sudoers}} which is in minutes.<br />
Set timeout to 20 minutes.<br />
<br />
Defaults:USER_NAME timestamp_timeout=20<br />
<br />
{{Tip|To ensure sudo always asks for a password, set the timeout to 0. To ensure the password never times out, set to less than 0.}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== File example ===<br />
<br />
This example is especially helpful for those using terminal multiplexers like screen, tmux, or ratpoison, and those using sudo from scripts/cronjobs:<br />
<br />
{{hc|/etc/sudoers|<nowiki><br />
Cmnd_Alias WHEELER = /usr/bin/lsof, /bin/nice, /bin/ps, /usr/bin/top, /usr/local/bin/nano, /usr/bin/ss, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync<br />
Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/kill, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
Cmnd_Alias EDITS = /usr/bin/vim, /usr/bin/nano, /usr/bin/cat, /usr/bin/vi<br />
Cmnd_Alias ARCHLINUX = /usr/bin/gparted, /usr/bin/pacman<br />
<br />
root ALL = (ALL) ALL<br />
USER_NAME ALL = (ALL) ALL, NOPASSWD: WHEELER, NOPASSWD: PROCESSES, NOPASSWD: ARCHLINUX, NOPASSWD: EDITS<br />
<br />
Defaults !requiretty, !tty_tickets, !umask<br />
Defaults visiblepw, path_info, insults, lecture=always<br />
Defaults loglinelen = 0, logfile =/var/log/sudo.log, log_year, log_host, syslog=auth<br />
Defaults mailto=webmaster@foobar.com, mail_badpass, mail_no_user, mail_no_perms<br />
Defaults passwd_tries = 8, passwd_timeout = 1<br />
Defaults env_reset, always_set_home, set_home, set_logname<br />
Defaults !env_editor, editor="/usr/bin/vim:/usr/bin/vi:/usr/bin/nano"<br />
Defaults timestamp_timeout=360<br />
Defaults passprompt="Sudo invoked by [%u] on [%H] - Cmd run as %U - Password for user %p:"<br />
</nowiki>}}<br />
<br />
=== Enabling Tab-completion in Bash ===<br />
<br />
{{ic|Tab}}-completion, by default, will not work when a user is initially added to the sudoers file. For example, normally john only needs to type:<br />
<br />
$ fire<{{ic|Tab}}><br />
<br />
and the shell will complete the command for him as:<br />
<br />
$ firefox<br />
<br />
If, however, john is added to the sudoers file and he types:<br />
<br />
$ sudo fire<{{ic|Tab}}><br />
<br />
the shell will do nothing.<br />
<br />
To enable {{ic|Tab}}-completion with sudo, [[pacman|install]] the {{pkg|bash-completion}} package from the [[Official Repositories|official repositories]]. see [[bash#Tab_completion]] for more information.<br />
<br />
Alternatively, add the following to your {{ic|~/.bashrc}}:<br />
<br />
complete -cf sudo<br />
<br />
=== Run X11 apps using sudo ===<br />
<br />
To allow sudo to start graphical application in X11, you need to add:<br />
<br />
Defaults env_keep += "HOME"<br />
<br />
to visudo.<br />
<br />
=== Disable per-terminal sudo ===<br />
<br />
{{Warning|This will let any process use your sudo session.}}<br />
<br />
If you are annoyed by sudo's defaults that require you to enter your password every time you open a new terminal, disable '''tty_tickets''':<br />
<br />
Defaults !tty_tickets<br />
<br />
=== Environment variables ===<br />
<br />
If you have a lot of environment variables, or you export your proxy settings via {{ic|1=export http_proxy="..."}}, when using sudo these variables do not get passed to the root account unless you run sudo with the {{ic|-E}} option.<br />
<br />
$ sudo -E pacman -Syu<br />
<br />
The recommended way of preserving environment variables is to append them to {{ic|env_keep}}:<br />
{{hc|/etc/sudoers|<nowiki><br />
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"<br />
</nowiki>}}<br />
<br />
=== Passing aliases ===<br />
<br />
If you use a lot of aliases, you might have noticed that they do not carry over to the root account when using sudo. However, there is an easy way to make them work. Simply add the following to your {{ic|~/.bashrc}} or {{ic|/etc/bash.bashrc}}:<br />
<br />
alias sudo='sudo '<br />
<br />
=== Insults ===<br />
<br />
Users can configure sudo to display clever insults when an incorrect password is entered instead of printing the default "wrong password" message. Find the Defaults line in {{ic|/etc/sudoers}} and append "insults" after a comma to existing options. The final result might look like this:<br />
<br />
#Defaults specification<br />
Defaults insults<br />
<br />
To test, type {{ic|sudo -K}} to end the current session and let sudo ask for the password again.<br />
<br />
=== Root password ===<br />
<br />
Users can configure sudo to ask for the root password instead of the user password by adding "rootpw" to the Defaults line in {{ic|/etc/sudoers}}:<br />
<br />
Defaults timestamp_timeout=0,rootpw<br />
<br />
=== Disable root login ===<br />
<br />
{{Warning|Arch Linux is not fine-tuned to run with a disabled root account. Users may encounter problems with this method.}}<br />
<br />
With sudo installed and configured, users may wish to disable the root login. Without root, attackers must first guess a user name configured as a sudoer as well as the user password.<br />
<br />
{{Warning|Ensure a user is properly configured as a sudoer ''before'' disabling the root account!}}<br />
<br />
The account can be locked via {{ic|passwd}}:<br />
<br />
# passwd -l root<br />
<br />
A similar command unlocks root.<br />
<br />
$ sudo passwd -u root<br />
<br />
Alternatively, edit {{ic|/etc/shadow}} and replace the root's encrypted password with "!":<br />
<br />
root:!:12345::::::<br />
<br />
To enable root login again:<br />
<br />
$ sudo passwd root<br />
<br />
==== kdesu ====<br />
<br />
kdesu may be used under KDE to launch GUI applications with root privileges. It is possible that by default kdesu will try to use su even if the root account is disabled. Fortunately one can tell kdesu to use sudo instead of su. Create/edit the file {{ic|~/.kde4/share/config/kdesurc}}:<br />
<br />
[super-user-command]<br />
super-user-command=sudo<br />
<br />
==== PolicyKit ====<br />
<br />
When disabling the root account, it is necessary to change the [[PolicyKit]] configuration for local authorization to reflect that. The default is to ask for the root password, so that must be changed. With polkit-1, this can be achieved by editing {{ic|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf}} so that {{ic|1=AdminIdentities=unix-user:0}} is replaced with something else, depending on the system configuration. It can be a list of users and groups, for example:<br />
<br />
AdminIdentities=unix-group:wheel<br />
<br />
or<br />
<br />
AdminIdentities=unix-user:me;unixuser:mom;unix-group:wheel<br />
<br />
For more information, see {{ic|man pklocalauthority}}.<br />
<br />
==== NetworkManager ====<br />
<br />
Even with the above PolicyKit configuration you still need to configure a policy for NetworkManager. This is documented on the [[NetworkManager#Can.27t_edit_connections_as_normal_user|NetworkManager]] page of this wiki.<br />
<br />
=== Harden with Sudo Example ===<br />
<br />
Lets say you create 3 users: admin, devel, and Joe<br />
admin is used for journalctl, systemctl, mount, kill, and iptables.<br />
devel is used for installing packages, and editing config's<br />
Joe is the user you log in with. Let's let him reboot, shutdown, and use netctl<br />
<br />
Edit /etc/pam.d/su and /etc/pam.d/su-1<br />
Require user be in the wheel group, but don't put anyone in it.<br />
#%PAM-1.0<br />
auth sufficient pam_rootok.so<br />
# Uncomment the following line to implicitly trust users in the "wheel" group.<br />
#auth sufficient pam_wheel.so trust use_uid<br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
auth required pam_unix.so<br />
account required pam_unix.so<br />
session required pam_unix.so<br />
<br />
Limit SSH login to the 'ssh' group, Only put Joe in it<br />
groupadd -r ssh<br />
gpasswd -a Joe ssh<br />
echo 'AllowGroups ssh' >> /etc/ssh/sshd_config<br />
systemctl restart sshd.service<br />
<br />
Lets add users to other goups.<br />
for g in power network ;do ;gpasswd -a Joe $g ;done<br />
for g in network power storage ;do ;gpasswd -a admin $g ;done<br />
<br />
Set permissions on configs so devel can edit them.<br />
chown -R devel:root /etc/{http,openvpn,cups,zsh,vim,screenrc}<br />
<br />
Cmnd_Alias POWER = /usr/bin/shutdown -h now, /usr/bin/halt, /usr/bin/poweroff, /usr/bin/reboot<br />
Cmnd_Alias STORAGE = /usr/bin/mount, /usr/bin/umount<br />
Cmnd_Alias SYSTEMD = /usr/bin/journalctl, /usr/bin/systemctl<br />
Cmnd_Alias KILL = /usr/bin/kill, /usr/bin/killall<br />
Cmnd_Alias PKGMAN = /usr/bin/pacman<br />
Cmnd_Alias NETWORK = /usr/bin/netctl<br />
Cmnd_Alias FIREWALL = /usr/bin/iptables, /usr/bin/ip6tables<br />
Cmnd_Alias SHELL = /usr/bin/zsh, /usr/bin/bash<br />
%power ALL = (root) NOPASSWD: POWER<br />
%network ALL = (root) NETWORK<br />
%storage ALL = (root) STORAGE<br />
root ALL = (ALL) ALL<br />
admin ALL = (root) SYSTEMD, KILL, FIREWALL<br />
devel ALL = (root) PKGMAN<br />
Joe ALL = (devel) SHELL, (admin) SHELL <br />
<br />
With this setup, you will almost never need to login as the Root user.<br />
<br />
Joe can connect to his home WiFi<br />
sudo netctl start home<br />
sudo poweroff<br />
<br />
Joe can not use netctl as any other user like admin...<br />
sudo -u admin -- netctl start home<br />
<br />
When Joe needs to use journalctl or kill run away process he can switch to that user<br />
sudo -i -u devel<br />
sudo -i -u admin<br />
<br />
But not Root<br />
sudo -i -u root<br />
<br />
If joe want to start a gnu-screen session as admin he can do it like this<br />
sudo -i -u admin<br />
admin% chown admin:tty `echo $TTY`<br />
admin% screen<br />
<br />
== Troubleshooting ==<br />
<br />
=== SSH TTY Issues ===<br />
<br />
SSH does not allocate a tty by default when running a remote command. Without a tty, sudo cannot disable echo when prompting for a password. You can use ssh's {{ic|-tt}} option to force it to allocate a tty (or {{ic|-t}} twice).<br />
<br />
The {{ic|Defaults}} option {{ic|requiretty}} only allows the user to run sudo if they have a tty.<br />
<br />
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear text. You have to run "ssh -t hostname sudo <cmd>".<br />
#<br />
#Defaults requiretty<br />
<br />
=== Display User Privileges ===<br />
<br />
You can find out what privileges a particular user has with the following command:<br />
<br />
$ sudo -lU yourusename<br />
<br />
Or view your own with:<br />
<br />
{{hc|$ sudo -l|<nowiki><br />
Matching Defaults entries for yourusename on this host:<br />
loglinelen=0, logfile=/var/log/sudo.log, log_year, syslog=auth, mailto=webmaster@gmail.com, mail_badpass, mail_no_user,<br />
mail_no_perms,env_reset, always_set_home, tty_tickets, lecture=always, pwfeedback, rootpw, set_home<br />
<br />
User yourusename may run the following commands on this host:<br />
<br />
(ALL) ALL<br />
(ALL) NOPASSWD: /usr/bin/lsof, /bin/nice, /usr/bin/su, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync, /usr/bin/strace,<br />
(ALL) /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
(ALL) /usr/bin/gparted, /usr/bin/pacman<br />
(ALL) /usr/local/bin/synergyc, /usr/local/bin/synergys<br />
(ALL) /usr/bin/vim, /usr/bin/nano, /usr/bin/cat<br />
(root) NOPASSWD: /usr/local/bin/synergyc</nowiki>}}<br />
<br />
=== Permissive Umask ===<br />
<br />
Sudo will union the user's [[umask]] value with its own umask (which defaults to 0022). This prevents sudo from creating files with more open permissions than the user's umask allows. While this is a sane default if no custom umask is in use, this can lead to situations where a utility run by sudo may create files with different permissions than if run by root directly. If errors arise from this, sudo provides a means to fix the umask, even if the desired umask is more permissive than the umask that the user has specified. Adding this (using {{ic|visudo}}) will override sudo's default behavior:<br />
<br />
Defaults umask = 0022<br />
Defaults umask_override<br />
<br />
This sets sudo's umask to root's default umask (0022) and overrides the default behavior, always using the indicated umask regardless of what umask the user as set.<br />
<br />
<br />
=== Defaults Skeleton ===<br />
<br />
The authors site has a [http://www.gratisoft.us/sudo/sudoers.man.html#sudoers_options list of all the options] that can be used with the {{ic|Defaults}} command in the {{ic|/etc/sudoers}} file.<br />
<br />
The full list of options ''(parsed from the version 1.8.7 source code)'' is below in a format optimized for copying and pasting into your sudoers files for quick editing.<br />
<br />
{{bc|<nowiki>#Defaults always_set_home<br />
# If enabled, sudo will set the HOME environment variable to the home directory of the target user<br />
# (which is root unless the -u option is used). This effectively means that the -H option<br />
# always_set_home is only effective for configurations where either env_reset is disabled or HOME is present<br />
# in the env_keep list. Default: OFF<br />
<br />
#Defaults authenticate<br />
# If set, users must authenticate themselves via a password (or other means of authentication)<br />
# before they may run commands. This default may be overridden via the PASSWD and NOPASSWD<br />
<br />
#Defaults closefrom_override<br />
# If set, the user may use sudo's -C option which overrides the default starting<br />
# point at which sudo begins closing open file descriptors. Default: OFF<br />
<br />
#Defaults compress_io<br />
# If set, and sudo is configured to log a command's input or output, the I/O logs will be<br />
# compressed using zlib. This flag is on by default when sudo is compiled with zlib support.<br />
<br />
#Defaults env_editor<br />
# If set, visudo will use the value of the EDITOR or VISUAL environment variables before falling back on the default<br />
# editor list. Note that this may create a security hole as it allows th separated list of editors in the editor<br />
# variable. visudo will then only use the EDITOR or VISUAL if they match a value specified in editor. On by default.<br />
<br />
#Defaults env_reset<br />
# If set, sudo will run the command in a minimal environment containing the TERM, PATH, HOME, MAIL, SHELL, LOGNAME,<br />
# USER, USERNAME and SUDO_* variables. Any variables in the caller's env in the file specified by the env_file<br />
# option (if any). The default contents of the env_keep and env_check lists are displayed when sudo is run by<br />
# root with the -V option.<br />
<br />
#Defaults fast_glob<br />
# Normally, sudo uses the glob(3) function to do shell-style globbing when matching path names.<br />
# However, since it accesses the file system, glob(3) can take a long time to complete for som (automounted).<br />
# The fast_glob option causes sudo to use the fnmatch(3) function, which does not access the file system to do<br />
# its matching. The disadvantage of fast_glob is that it is unable to ma names that include globbing characters<br />
# are used with the negation operator, '!', as such rules can be trivially bypassed. As such, this option should<br />
# not be used when sudoers contains rules that<br />
<br />
#Defaults fqdn<br />
# Set this flag if you want to put fully qualified host names in the sudoers file. I.e., instead of myhost you<br />
# would use myhost.mydomain.edu. You may still use the short form if you wish (and sudo unusable if DNS stops<br />
# working (for example if the machine is not plugged into the network). Also note that you must use the<br />
# host's official name as DNS knows it. That is, you may not use a all aliases from DNS. If your machine's<br />
# host name (as returned by the hostname command) is already fully qualified you shouldn't need to set fqdn.<br />
# Default: OFF<br />
<br />
#Defaults ignore_dot<br />
# If set, sudo will ignore '.' or '' (current dir) in the PATH environment variable; the PATH<br />
# itself is not modified. Default: OFF<br />
<br />
#Defaults ignore_local_sudoers<br />
# If set via LDAP, parsing of /etc/sudoers will be skipped. This is intended for Enterprises that wish to prevent<br />
# the usage of local sudoers files so that only LDAP is used. /etc/sudoers does not even need to exist.<br />
# Since this option tells sudo how to behave when no specific LDAP entries have been matched, this sudo<br />
# Option is only meaningful for the cn=default<br />
<br />
#Defaults insults<br />
# If set, sudo will insult users when they enter an incorrect password. Default: OFF<br />
<br />
#Defaults log_host<br />
# If set, the host name will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults log_input<br />
# If set, sudo will run the command in a pseudo tty and log all user input. If the standard<br />
# input is not connected to the user's tty, due to I/O redirection or because the command is part Input is logged<br />
# to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that<br />
# is included in the normal sudo log line, prefixed with TSID=. Note that user input may contain sensitive<br />
# information such as passwords (even if they are not echoed to the screen), which will be stored in the log file<br />
# unencrypted.<br />
<br />
#Defaults log_output<br />
# If set, sudo will run the command in a pseudo tty and log all output that is sent to the<br />
# screen, similar to the script(1) command. If the standard output or standard error is not connec is also captured and<br />
# stored in separate log files. Output is logged to the directory specified by the iolog_dir option (/var/log/sudo-io<br />
# by default) using a unique session ID that is included in the normal sudo log line, prefixed with TSID=. The Output<br />
# logs may be viewed with the sudoreplay(8) utility, which can also be used to list or search the available logs.<br />
<br />
#Defaults log_year<br />
# If set, the four-digit year will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults long_otp_prompt<br />
# When validating with a One Time Password (OTP) scheme such as S/Key or OPIE, a two-line<br />
# prompt is used to make it easier to cut and paste the challenge to a local window<br />
<br />
#Defaults mail_always<br />
# Send mail to the mailto user every time a users runs sudo. Default: OFF<br />
<br />
#Defaults mail_badpass<br />
# Send mail to the mailto user if the user running sudo does not enter the correct password.<br />
# Default: OFF<br />
<br />
#Defaults mail_no_host<br />
# If set, mail will be sent to the mailto user if the invoking user exists in the sudoers<br />
# file, but is not allowed to run commands on the current host. Default: OFF<br />
<br />
#Defaults mail_no_perms<br />
# If set, mail will be sent to the mailto user if the invoking user is allowed to use sudo<br />
# but the command they are trying is not listed in their sudoers file entry or is explicitly denied<br />
<br />
#Defaults mail_no_user<br />
# If set, mail will be sent to the mailto user if the invoking user is not in the sudoers file.<br />
# Default: ON<br />
<br />
#Defaults noexec<br />
# If set, all commands run via sudo will behave as if the NOEXEC tag has been set, unless overridden<br />
# by a EXEC tag. See the description of NOEXEC and EXEC below as well as the "PREVENTING SHE<br />
<br />
#Defaults path_info<br />
# Normally, sudo will tell the user when a command could not be found in their PATH environment<br />
# variable. Some sites may wish to disable this as it could be used to gather information on t the executable is<br />
# simply not in the user's PATH, sudo will tell the user that they are not allowed to run it, which can be confusing.<br />
# Default: ON<br />
<br />
#Defaults passprompt_override<br />
# The password prompt specified by passprompt will normally only be used if the password prompt provided by<br />
# systems such as PAM matches the string "Password:"<br />
<br />
#Defaults preserve_groups<br />
# By default, sudo will initialize the group vector to the list of groups the target<br />
# user is in. When preserve_groups is set, the user's existing group vector is left unaltered.<br />
<br />
#Defaults pwfeedback<br />
# By default, sudo reads the password like most other Unix programs, by turning off echo<br />
# until the user hits the return (or enter) key. Some users become confused by this as it appears to the user<br />
# presses a key. Note that this does have a security impact as an onlooker may be able to determine the length of<br />
# the password being entered. Default: OFF<br />
<br />
#Defaults requiretty<br />
# If set, sudo will only run when the user is logged in to a real tty. When this flag is set,<br />
# sudo can only be run from a login session and not via other means such as cron(8) or cgi-bin<br />
<br />
#Defaults root_sudo<br />
# If set, root is allowed to run sudo too. Disabling this prevents users from "chaining" sudo<br />
# commands to get a root shell by doing something like "sudo sudo /bin/sh". Note, however, that real additional<br />
# security; it exists purely for historical reasons. Default: ON<br />
<br />
#Defaults rootpw<br />
# If set, sudo will prompt for the root password instead of the password of the invoking user.<br />
# Default: OFF<br />
<br />
#Defaults runaspw<br />
# If set, sudo will prompt for the password of the user defined by the runas_default option<br />
# (defaults to root) instead of the password of the invoking user. Default: OFF<br />
<br />
#Defaults set_home<br />
# If enabled and sudo is invoked with the -s option the HOME environment variable will be set<br />
# to the home directory of the target user (which is root unless the -u option is used). So set_home is only<br />
# effective for configs where either env_reset is disabled or HOME is present in the env_keep list. Default: OFF<br />
<br />
#Defaults set_logname<br />
# Normally, sudo will set the LOGNAME, USER and USERNAME environment variables to the name<br />
# of the target user (usually root unless the -u option is given). However, since some programs ( may be desirable<br />
# to change this behavior. This can be done by negating the set_logname option. Note that if the env_reset option<br />
# has not been disabled, entries in the env_keep list will override<br />
<br />
#Defaults set_utmp<br />
# When enabled, sudo will create an entry in the utmp (or utmpx) file when a pseudo-tty is<br />
# allocated. A pseudo-tty is allocated by sudo when the log_input, log_output or use_pty flags are e the tty, time,<br />
# type and pid fields updated. Default: ON<br />
<br />
#Defaults setenv<br />
# Allow the user to disable the env_reset option from the command line via the -E option.<br />
# Additionally, environment variables set via the command line are not subject to the restrictions impo variables<br />
# in this manner. Default: OFF<br />
<br />
#Defaults shell_noargs<br />
# If set and sudo is invoked with no arguments it acts as if the -s option had been given.<br />
# That is, it runs a shell as root (the shell is determined by the SHELL environment variable if is off by default.<br />
<br />
#Defaults stay_setuid<br />
# Normally, when sudo executes a command the real and effective UIDs are set to the target<br />
# user (root by default). This option changes that behaviour such that the real UID is left as the systems that<br />
# disable some potentially dangerous functionality when a program is run setuid. This option is only effective on<br />
# systems with either the setreuid() or setresuid() function. This flag<br />
<br />
#Defaults targetpw<br />
# If set, sudo will prompt for the password of the user specified by the -u option (defaults to root) instead<br />
# of the password of the invoking user. In addition, the timestamp file name will passwd database as an argument<br />
# to the -u option. Default: OFF<br />
<br />
#Defaults tty_tickets<br />
# If set, users must authenticate on a per-tty basis. With this flag enabled, sudo will<br />
# use a file named for the tty the user is logged in on in the user's time stamp directory.<br />
<br />
#Defaults umask_override<br />
# If set, sudo will set the umask as specified by sudoers without modification. This makes<br />
# it possible to specify a more permissive umask in sudoers than the user's own umask and match user's umask and what<br />
# is specified in sudoers. Default: OFF<br />
<br />
#Defaults use_pty<br />
# If set, sudo will run the command in a pseudo-pty even if no I/O logging is being gone.<br />
# A malicious program run under sudo could conceivably fork a background process that retains to the u that impossible.<br />
# Default: OFF<br />
<br />
#Defaults utmp_runas<br />
# If set, sudo will store the name of the runas user when updating the utmp (or utmpx) file.<br />
# By default, sudo stores the name of the invoking user. Default: OFF<br />
<br />
#Defaults visiblepw<br />
# By default, sudo will refuse to run if the user must enter a password but it is not possible to disable echo on the <br />
# terminal. If the visiblepw flag is set, sudo will prompt for a password even when it would be visible on the screen. <br />
# This makes it possible to run things like "rsh somehost sudo ls" since rsh(1) does not allocate a tty. Default: OFF<br />
<br />
#Defaults closefrom<br />
# Before it executes a command, sudo will close all open file descriptors other than standard<br />
# input, standard output and standard error (ie: file descriptors 0-2).<br />
<br />
#Defaults passwd_tries<br />
# The number of tries a user gets to enter his/her password before sudo logs the failure<br />
# and exits. The default is 3.<br />
<br />
#Defaults loglinelen<br />
# Number of characters per line for the file log. This value is used to decide when to wrap<br />
# lines for nicer log files. This has no effect on the syslog log file, only the file log.<br />
<br />
#Defaults passwd_timeout<br />
# Number of minutes before the sudo password prompt times out, or 0 for no timeout.<br />
# The timeout may include a fractional component if minute granularity is insufficient, for example 2<br />
<br />
#Defaults timestamp_timeout<br />
# Number of minutes that can elapse before sudo will ask for a passwd again. The timeout<br />
# may include a fractional component if minute granularity is insufficient, for example 2.5. timestamp will never expire.<br />
# This can be used to allow users to create or delete their own timestamps via sudo -v and sudo -k respectively.<br />
<br />
#Defaults umask<br />
# Umask to use when running the command. Negate this option or set it to 0777 to preserve<br />
# the user's umask. The actual umask that is used will be the union of the user's umask and the value o running<br />
# a command. Note on systems that use PAM, the default PAM configuration may specify its own umask which will<br />
# override the value set in sudoers.<br />
<br />
#Defaults badpass_message<br />
# Message that is displayed if a user enters an incorrect password. The default is Sorry,<br />
# try again. unless insults are enabled.<br />
<br />
#Defaults editor<br />
# A colon (':') separated list of editors allowed to be used with visudo. visudo will choose<br />
# the editor that matches the user's EDITOR environment variable if possible, or the first editor in<br />
<br />
#Defaults iolog_dir<br />
# The top-level directory to use when constructing the path name for the input/output log<br />
# directory. Only used if the log_input or log_output options are enabled or when the LOG_INPUT or L directory.<br />
# The default is "/var/log/sudo-io". The following percent (%) escape sequences are supported:<br />
# %{seq} - expanded to base-36 sequence number, such as 0100A5, to form a new directory, e.g. 01/00/A5<br />
# %{user} - expanded to the invoking user's login name<br />
# %{group} - expanded to the name of the invoking user's real group ID<br />
# %{runas_user} - expanded to the login name of the user the command will be run as (e.g. root)<br />
# %{runas_group} - expanded to the group name of the user the command will be run as (e.g. wheel)<br />
# %{hostname} - expanded to the local host name without the domain name<br />
# %{command} - expanded to the base name of the command being run In addition, any escape sequences supported by<br />
# strftime() function will be expanded. To include a literal % character, the string %% should be used.<br />
<br />
#Defaults iolog_file<br />
# The path name, relative to iolog_dir, in which to store input/output logs when the log_input or log_output options are<br />
# enabled or when the LOG_INPUT or LOG_OUTPUT tags are present for a See the iolog_dir option above for a list of<br />
# supported percent (%) escape sequences. In addition to the escape sequences, path names that end in six or more Xs will<br />
# have the Xs replaced with a unique combination of digits and letters, similar to the mktemp() function.<br />
<br />
#Defaults mailsub<br />
# Subject of the mail sent to the mailto user. The escape %h will expand to the host name of<br />
# the machine. Default is *** SECURITY information for %h ***.<br />
<br />
#Defaults noexec_file<br />
# This option is no longer supported. The path to the noexec file should now be set in the /etc/sudo.conf file.<br />
<br />
#Defaults passprompt<br />
# The default prompt to use when asking for a password; can be overridden via the -p option or the SUDO_PROMPT<br />
# environment variable. The following percent (%) escape sequences are supported:<br />
# %H - expanded to the local host name including the domain (only if the host name is fqdn or fqdn option is set)<br />
# %h - expanded to the local host name without the domain name<br />
# %p - expanded to the user whose password is being asked for (respects the rootpw, targetpw and runaspw flags)<br />
# %U - expanded to the login name of the user the command will be run as (defaults to root)<br />
# %u - expanded to the invoking user's login name<br />
# %% - two consecutive % characters are collapsed into a single % character<br />
# The default value is Password:.<br />
<br />
#Defaults runas_default<br />
# The default user to run commands as if the -u option is not specified on the command line. This defaults to root.<br />
<br />
#Defaults syslog_badpri<br />
# Syslog priority to use when user authenticates unsuccessfully. Defaults to alert.<br />
# alert, crit, debug, emerg, err, info, notice, and warning.<br />
<br />
#Defaults syslog_goodpri<br />
# Syslog priority to use when user authenticates successfully. Defaults to notice. See syslog_badpri for the priorities.<br />
<br />
#Defaults sudoers_locale<br />
# Locale to use when parsing the sudoers file, logging commands, and sending email.<br />
# Note that changing the locale may affect how sudoers is interpreted. Defaults to "C".<br />
<br />
#Defaults timestampdir<br />
# The directory in which sudo stores its timestamp files. The default is /var/db/sudo.<br />
<br />
#Defaults timestampowner<br />
# The owner of the timestamp directory and the timestamps stored therein. The default is root.<br />
<br />
#Defaults env_file<br />
# The env_file option specifies the fully qualified path to a file containing variables to<br />
# be set in the environment of the program being run. Entries in this file should either be of the f quotes.<br />
# Variables in this file are subject to other sudo environment settings such as env_keep and env_check.<br />
<br />
#Defaults exempt_group<br />
# Users in this group are exempt from password and PATH requirements. The group name specified should not include<br />
# a % prefix. This is not set by default.<br />
<br />
#Defaults group_plugin<br />
# A string containing a sudoers group plugin with optional arguments. This can be used to implement support for the<br />
# nonunix_group syntax described earlier. The string should consist of configuration arguments the plugin requires.<br />
# These arguments (if any) will be passed to the plugin's initialization function. If arguments are present, the<br />
# string must be enclosed in double quote For example, given /etc/sudo-group, a group file in Unix group format,<br />
# the sample group plugin can be used: Defaults group_plugin="sample_group.so /etc/sudo-group"<br />
# For more information see sudo_plugin(5).<br />
<br />
#Defaults lecture<br />
# This option controls when a short lecture will be printed along with the password prompt. The default value is once.<br />
# It has the following possible values:<br />
# always - Always lecture the user.<br />
# never - Never lecture the user.<br />
# once - Only lecture the user the first time they run sudo.<br />
# If no value is specified, a value of once is implied. Negating the option results in a value of never being used.<br />
<br />
#Defaults lecture_file<br />
# Path to a file containing an alternate sudo lecture that will be used in place of the standard lecture if the named<br />
# file exists. By default, sudo uses a built-in lecture.<br />
<br />
#Defaults listpw<br />
# This option controls when a password will be required when a user runs sudo with the -l option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD set to avoid entering a pass.<br />
# always - The user must always enter a password to use the -l option.<br />
# any - At least one of the user's sudoers entries for the current host must have the NOPASSWD set to avoid pass.<br />
# never - The user need never enter a password to use the -l option.<br />
# If no value is specified, a value of any is implied. The default value is any.<br />
<br />
#Defaults logfile<br />
# Path to the sudo log file (not the syslog log file). Setting a path turns on logging to a file;<br />
# negating this option turns it off. By default, sudo logs via syslog.<br />
<br />
#Defaults mailerflags<br />
# Flags to use when invoking mailer. Defaults to -t.<br />
<br />
#Defaults mailerpath<br />
# Path to mail program used to send warning mail. Defaults to the path to sendmail found at configure time.<br />
<br />
#Defaults mailfrom<br />
# Address to use for the "from" address when sending warning and error mail. The address should<br />
# be enclosed in double quotes (") to protect against sudo interpreting the @ sign.<br />
<br />
#Defaults mailto<br />
# Address to send warning and error mail to. The address should be enclosed in double quotes<br />
# (") to protect against sudo interpreting the @ sign. Defaults to root.<br />
<br />
#Defaults secure_path<br />
# Path used for every command run from sudo. If you don't trust the people running sudo to have a sane PATH environment<br />
# variable you may want to use this. Another use is if you want to option are not affected by secure_path.<br />
# This option is not set by default.<br />
<br />
#Defaults syslog<br />
# Syslog facility if syslog is being used for logging (negate to disable syslog logging). Defaults to auth.<br />
# authpriv (if OS supports it), auth, daemon, user, local0, local1, local2, local3, local4, local5, local6, and local7.<br />
<br />
#Defaults verifypw<br />
# This option controls when a password will be required when a user runs sudo with the -v option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD flag to avoid pw.<br />
# always - The user must always enter a password to use the -v option.<br />
# any - At least one of the user's sudoers entries for the current host must have NOPASSWD to avoid pw.<br />
# never - The user need never enter a password to use the -v option<br />
# If no value is specified, a value of all is implied. Negating the option results in a value of never being used.<br />
# The default value is all.<br />
<br />
#Defaults env_check<br />
# Environment variables to be removed from the user's environment if the variable's value contains % or / characters.<br />
# This can be used to guard against printf-style format vulnerabilities value without double-quotes. The list can be<br />
# replaced, added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively. Regardless of<br />
# whether the env_reset option is ena they pass the aforementioned check. The default list of environment variables<br />
# to check is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_delete<br />
# Environment variables to be removed from the user's environment when the env_reset option is not in effect. The<br />
# argument may be a double-quoted, space-separated list or a single value w +=, -=, and ! operators respectively.<br />
# The default list of environment variables to remove is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_keep<br />
# Environment variables to be preserved in the user's environment when the env_reset option is in effect. This<br />
# allows fine-grained control over the environment sudo-spawned processes will r quotes. The list can be replaced,<br />
# added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively.</nowiki>}}</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Sudo&diff=285341Sudo2013-11-30T05:06:55Z<p>Hunterthomson: /* Harden with Sudo Example */ darn Tab, space mix up</p>
<hr />
<div>[[Category:Security]]<br />
[[cs:Sudo]]<br />
[[es:Sudo]]<br />
[[fr:Sudo]]<br />
[[it:Sudo]]<br />
[[ja:Sudo]]<br />
[[ru:Sudo]]<br />
[[sr:Sudo]]<br />
[[tr:Sudo]]<br />
[[uk:Sudo]]<br />
[[zh-CN:Sudo]]<br />
{{Related articles start}}<br />
{{Related|Users and Groups}}<br />
{{Related|su}}<br />
{{Related articles end}}<br />
<br />
[http://www.gratisoft.us/sudo/ sudo] ("substitute user do") allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments.<br />
<br />
== Rationale ==<br />
<br />
Sudo is an alternative to [[su]] for running commands as root. Unlike [[su]], which launches a root shell that allows all further commands root access, sudo instead grants temporary privilege escalation to a single command. By enabling root privileges only when needed, sudo usage reduces the likelyhood that a typo or a bug in an invoked command will ruin the system.<br />
Sudo can also be used to run commands as other users; additionally, sudo logs all commands and failed access attempts for security auditing.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|sudo}} package, available in the [[Official Repositories|official repositories]]:<br />
<br />
# pacman -S sudo<br />
<br />
To begin using {{ic|sudo}} as a non-privileged user, it must be properly configured. So make sure you read the configuration section.<br />
<br />
== Usage ==<br />
<br />
With sudo, users can prefix commands with {{ic|sudo}} to run them with superuser (or other) privileges.<br />
<br />
For example, to use pacman:<br />
<br />
$ sudo pacman -Syu<br />
<br />
See the [http://www.gratisoft.us/sudo/man/sudo.html sudo manual] for more information.<br />
<br />
== Configuration ==<br />
<br />
=== View current settings ===<br />
<br />
Run {{ic|sudo -ll}} to print out the current sudo configuration.<br />
<br />
=== Using visudo ===<br />
<br />
The configuration file for sudo is {{ic|/etc/sudoers}}. It should '''always''' be edited with the {{ic|visudo}} command. {{ic|visudo}} locks the {{ic|sudoers}} file, saves edits to a temporary file, and checks that file's grammar before copying it to {{ic|/etc/sudoers}}.<br />
<br />
{{Warning|It is imperative that {{ic|sudoers}} be free of syntax errors! Any error makes sudo unusable. '''Always''' edit it with {{ic|visudo}} to prevent errors.}}<br />
<br />
The default editor for visudo is {{ic|vi}}. It will be used if you do not specify another editor, by setting either VISUAL or EDITOR environment variables (used in that order) to the desired editor, e.g. {{ic|nano}}. The command is run as root:<br />
<br />
# EDITOR=nano visudo<br />
<br />
You can permanently change the setting for your user to e.g. {{ic|nano}} by appending:<br />
<br />
export EDITOR=nano<br />
<br />
to your {{ic|~/.bashrc}} file. Note that this won't take effect for already-running shells.<br />
<br />
To change the editor of choice permanently system-wide only for {{ic|visudo}}, add the following line to {{ic|/etc/sudoers}} where {{ic|nano}} is your prefered editor:<br />
<br />
# Reset environment by default<br />
Defaults env_reset<br />
# Set default EDITOR to nano, and do not allow visudo to use EDITOR/VISUAL.<br />
Defaults editor=/usr/bin/nano, !env_editor<br />
<br />
=== Example Entries ===<br />
<br />
To allow a user to gain full root privileges when he/she precedes a command with {{ic|sudo}}, add the following line:<br />
<br />
USER_NAME ALL=(ALL) ALL<br />
<br />
To allow a user to run all commands as any user but only the machine with hostname HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=(ALL) ALL<br />
<br />
To allow members of group {{ic|wheel}} sudo access:<br />
<br />
%wheel ALL=(ALL) ALL<br />
<br />
To disable asking for a password for user USER_NAME:<br />
<br />
Defaults:USER_NAME !authenticate<br />
<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=/usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
{{note| the most customized option should go at the end of the file, as the later lines overrides the previous ones. In particular such a line should be after the {{ic|%wheel}} line if your user is in this group.}}<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME without password:<br />
USER_NAME HOST_NAME= NOPASSWD: /usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
<br />
A detailed sudoers example can be found [http://www.gratisoft.us/sudo/sample.sudoers here]. Otherwise, see the [http://www.gratisoft.us/sudo/man/sudoers.html sudoers manual] for detailed information.<br />
<br />
=== Sudoers default file permissions ===<br />
<br />
The owner and group for the sudoers file must both be 0. The file permissions must be set to 0440. These permissions are set by default, but if you accidentally change them, they should be changed back immediately or sudo will fail.<br />
<br />
# chown -c root:root /etc/sudoers<br />
# chmod -c 0440 /etc/sudoers<br />
<br />
=== Password cache timeout ===<br />
<br />
Users may wish to change the default timeout before the cached password expires. This is accomplished with the timestamp_timeout option in {{ic|/etc/sudoers}} which is in minutes.<br />
Set timeout to 20 minutes.<br />
<br />
Defaults:USER_NAME timestamp_timeout=20<br />
<br />
{{Tip|To ensure sudo always asks for a password, set the timeout to 0. To ensure the password never times out, set to less than 0.}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== File example ===<br />
<br />
This example is especially helpful for those using terminal multiplexers like screen, tmux, or ratpoison, and those using sudo from scripts/cronjobs:<br />
<br />
{{hc|/etc/sudoers|<nowiki><br />
Cmnd_Alias WHEELER = /usr/bin/lsof, /bin/nice, /bin/ps, /usr/bin/top, /usr/local/bin/nano, /usr/bin/ss, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync<br />
Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/kill, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
Cmnd_Alias EDITS = /usr/bin/vim, /usr/bin/nano, /usr/bin/cat, /usr/bin/vi<br />
Cmnd_Alias ARCHLINUX = /usr/bin/gparted, /usr/bin/pacman<br />
<br />
root ALL = (ALL) ALL<br />
USER_NAME ALL = (ALL) ALL, NOPASSWD: WHEELER, NOPASSWD: PROCESSES, NOPASSWD: ARCHLINUX, NOPASSWD: EDITS<br />
<br />
Defaults !requiretty, !tty_tickets, !umask<br />
Defaults visiblepw, path_info, insults, lecture=always<br />
Defaults loglinelen = 0, logfile =/var/log/sudo.log, log_year, log_host, syslog=auth<br />
Defaults mailto=webmaster@foobar.com, mail_badpass, mail_no_user, mail_no_perms<br />
Defaults passwd_tries = 8, passwd_timeout = 1<br />
Defaults env_reset, always_set_home, set_home, set_logname<br />
Defaults !env_editor, editor="/usr/bin/vim:/usr/bin/vi:/usr/bin/nano"<br />
Defaults timestamp_timeout=360<br />
Defaults passprompt="Sudo invoked by [%u] on [%H] - Cmd run as %U - Password for user %p:"<br />
</nowiki>}}<br />
<br />
=== Enabling Tab-completion in Bash ===<br />
<br />
{{ic|Tab}}-completion, by default, will not work when a user is initially added to the sudoers file. For example, normally john only needs to type:<br />
<br />
$ fire<{{ic|Tab}}><br />
<br />
and the shell will complete the command for him as:<br />
<br />
$ firefox<br />
<br />
If, however, john is added to the sudoers file and he types:<br />
<br />
$ sudo fire<{{ic|Tab}}><br />
<br />
the shell will do nothing.<br />
<br />
To enable {{ic|Tab}}-completion with sudo, [[pacman|install]] the {{pkg|bash-completion}} package from the [[Official Repositories|official repositories]]. see [[bash#Tab_completion]] for more information.<br />
<br />
Alternatively, add the following to your {{ic|~/.bashrc}}:<br />
<br />
complete -cf sudo<br />
<br />
=== Run X11 apps using sudo ===<br />
<br />
To allow sudo to start graphical application in X11, you need to add:<br />
<br />
Defaults env_keep += "HOME"<br />
<br />
to visudo.<br />
<br />
=== Disable per-terminal sudo ===<br />
<br />
{{Warning|This will let any process use your sudo session.}}<br />
<br />
If you are annoyed by sudo's defaults that require you to enter your password every time you open a new terminal, disable '''tty_tickets''':<br />
<br />
Defaults !tty_tickets<br />
<br />
=== Environment variables ===<br />
<br />
If you have a lot of environment variables, or you export your proxy settings via {{ic|1=export http_proxy="..."}}, when using sudo these variables do not get passed to the root account unless you run sudo with the {{ic|-E}} option.<br />
<br />
$ sudo -E pacman -Syu<br />
<br />
The recommended way of preserving environment variables is to append them to {{ic|env_keep}}:<br />
{{hc|/etc/sudoers|<nowiki><br />
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"<br />
</nowiki>}}<br />
<br />
=== Passing aliases ===<br />
<br />
If you use a lot of aliases, you might have noticed that they do not carry over to the root account when using sudo. However, there is an easy way to make them work. Simply add the following to your {{ic|~/.bashrc}} or {{ic|/etc/bash.bashrc}}:<br />
<br />
alias sudo='sudo '<br />
<br />
=== Insults ===<br />
<br />
Users can configure sudo to display clever insults when an incorrect password is entered instead of printing the default "wrong password" message. Find the Defaults line in {{ic|/etc/sudoers}} and append "insults" after a comma to existing options. The final result might look like this:<br />
<br />
#Defaults specification<br />
Defaults insults<br />
<br />
To test, type {{ic|sudo -K}} to end the current session and let sudo ask for the password again.<br />
<br />
=== Root password ===<br />
<br />
Users can configure sudo to ask for the root password instead of the user password by adding "rootpw" to the Defaults line in {{ic|/etc/sudoers}}:<br />
<br />
Defaults timestamp_timeout=0,rootpw<br />
<br />
=== Disable root login ===<br />
<br />
{{Warning|Arch Linux is not fine-tuned to run with a disabled root account. Users may encounter problems with this method.}}<br />
<br />
With sudo installed and configured, users may wish to disable the root login. Without root, attackers must first guess a user name configured as a sudoer as well as the user password.<br />
<br />
{{Warning|Ensure a user is properly configured as a sudoer ''before'' disabling the root account!}}<br />
<br />
The account can be locked via {{ic|passwd}}:<br />
<br />
# passwd -l root<br />
<br />
A similar command unlocks root.<br />
<br />
$ sudo passwd -u root<br />
<br />
Alternatively, edit {{ic|/etc/shadow}} and replace the root's encrypted password with "!":<br />
<br />
root:!:12345::::::<br />
<br />
To enable root login again:<br />
<br />
$ sudo passwd root<br />
<br />
==== kdesu ====<br />
<br />
kdesu may be used under KDE to launch GUI applications with root privileges. It is possible that by default kdesu will try to use su even if the root account is disabled. Fortunately one can tell kdesu to use sudo instead of su. Create/edit the file {{ic|~/.kde4/share/config/kdesurc}}:<br />
<br />
[super-user-command]<br />
super-user-command=sudo<br />
<br />
==== PolicyKit ====<br />
<br />
When disabling the root account, it is necessary to change the [[PolicyKit]] configuration for local authorization to reflect that. The default is to ask for the root password, so that must be changed. With polkit-1, this can be achieved by editing {{ic|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf}} so that {{ic|1=AdminIdentities=unix-user:0}} is replaced with something else, depending on the system configuration. It can be a list of users and groups, for example:<br />
<br />
AdminIdentities=unix-group:wheel<br />
<br />
or<br />
<br />
AdminIdentities=unix-user:me;unixuser:mom;unix-group:wheel<br />
<br />
For more information, see {{ic|man pklocalauthority}}.<br />
<br />
==== NetworkManager ====<br />
<br />
Even with the above PolicyKit configuration you still need to configure a policy for NetworkManager. This is documented on the [[NetworkManager#Can.27t_edit_connections_as_normal_user|NetworkManager]] page of this wiki.<br />
<br />
=== Harden with Sudo Example ===<br />
<br />
Lets say you create 3 users: admin, devel, and Joe<br />
admin is used for journalctl, systemctl, mount, kill, and iptables.<br />
devel is used for installing packages, and editing config's<br />
Joe is the user you log in with. Let's let him reboot, shutdown, and use netctl<br />
<br />
Edit /etc/pam.d/su and /etc/pam.d/su-1<br />
Require user be in the wheel group, but don't put anyone in it.<br />
#%PAM-1.0<br />
auth sufficient pam_rootok.so<br />
# Uncomment the following line to implicitly trust users in the "wheel" group.<br />
#auth sufficient pam_wheel.so trust use_uid<br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
auth required pam_unix.so<br />
account required pam_unix.so<br />
session required pam_unix.so<br />
<br />
Limit SSH login to the 'ssh' group, Only put Joe in it<br />
groupadd -r ssh<br />
gpasswd -a Joe ssh<br />
echo 'AllowGroups ssh' >> /etc/ssh/sshd_config<br />
systemctl restart sshd.service<br />
<br />
Lets add users to other goups.<br />
for g in power network ;do ;gpasswd -a Joe $g ;done<br />
for g in network power storage ;do ;gpasswd -a admin $g ;done<br />
<br />
Set permissions on configs so devel can edit them.<br />
chown -R devel:root /etc/{http,openvpn,cups,zsh,vim,screenrc}<br />
<br />
Cmnd_Alias POWER = /usr/bin/shutdown -h now, /usr/bin/halt, /usr/bin/poweroff, /usr/bin/reboot<br />
Cmnd_Alias STORAGE = /usr/bin/mount, /usr/bin/umount<br />
Cmnd_Alias SYSTEMD = /usr/bin/journalctl, /usr/bin/systemctl<br />
Cmnd_Alias KILL = /usr/bin/kill, /usr/bin/killall<br />
Cmnd_Alias PKGMAN = /usr/bin/pacman<br />
Cmnd_Alias NETWORK = /usr/bin/netctl<br />
Cmnd_Alias FIREWALL = /usr/bin/iptables, /usr/bin/ip6tables<br />
Cmnd_Alias SHELL = /usr/bin/zsh, /usr/bin/bash<br />
%power ALL = (root) NOPASSWD: POWER<br />
%network ALL = (root) NETWORK<br />
%storage ALL = (root) STORAGE<br />
root ALL = (ALL) ALL<br />
admin ALL = (root) SYSTEMD, KILL, FIREWALL<br />
devel ALL = (root) PKGMAN<br />
Joe ALL = (devel) SHELL, (admin) SHELL <br />
<br />
With this setup, you will almost never need to login as the Root user.<br />
<br />
Joe can connect to his home WiFi<br />
sudo netctl start home<br />
sudo poweroff<br />
<br />
Joe can not use netctl as any other user like admin...<br />
sudo -u admin -- netctl start home<br />
<br />
When Joe needs to use journalctl or kill run away process he can switch to that user<br />
sudo -i -u devel<br />
sudo -i -u admin<br />
<br />
But not Root<br />
sudo -i -u root<br />
<br />
If joe want to start a gnu-screen session as admin he can do it like this<br />
sudo -i -u admin<br />
admin% chown admin:tty `echo $TTY`<br />
admin% screen<br />
<br />
== Troubleshooting ==<br />
<br />
=== SSH TTY Issues ===<br />
<br />
SSH does not allocate a tty by default when running a remote command. Without a tty, sudo cannot disable echo when prompting for a password. You can use ssh's {{ic|-tt}} option to force it to allocate a tty (or {{ic|-t}} twice).<br />
<br />
The {{ic|Defaults}} option {{ic|requiretty}} only allows the user to run sudo if they have a tty.<br />
<br />
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear text. You have to run "ssh -t hostname sudo <cmd>".<br />
#<br />
#Defaults requiretty<br />
<br />
=== Display User Privileges ===<br />
<br />
You can find out what privileges a particular user has with the following command:<br />
<br />
$ sudo -lU yourusename<br />
<br />
Or view your own with:<br />
<br />
{{hc|$ sudo -l|<nowiki><br />
Matching Defaults entries for yourusename on this host:<br />
loglinelen=0, logfile=/var/log/sudo.log, log_year, syslog=auth, mailto=webmaster@gmail.com, mail_badpass, mail_no_user,<br />
mail_no_perms,env_reset, always_set_home, tty_tickets, lecture=always, pwfeedback, rootpw, set_home<br />
<br />
User yourusename may run the following commands on this host:<br />
<br />
(ALL) ALL<br />
(ALL) NOPASSWD: /usr/bin/lsof, /bin/nice, /usr/bin/su, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync, /usr/bin/strace,<br />
(ALL) /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
(ALL) /usr/bin/gparted, /usr/bin/pacman<br />
(ALL) /usr/local/bin/synergyc, /usr/local/bin/synergys<br />
(ALL) /usr/bin/vim, /usr/bin/nano, /usr/bin/cat<br />
(root) NOPASSWD: /usr/local/bin/synergyc</nowiki>}}<br />
<br />
=== Permissive Umask ===<br />
<br />
Sudo will union the user's [[umask]] value with its own umask (which defaults to 0022). This prevents sudo from creating files with more open permissions than the user's umask allows. While this is a sane default if no custom umask is in use, this can lead to situations where a utility run by sudo may create files with different permissions than if run by root directly. If errors arise from this, sudo provides a means to fix the umask, even if the desired umask is more permissive than the umask that the user has specified. Adding this (using {{ic|visudo}}) will override sudo's default behavior:<br />
<br />
Defaults umask = 0022<br />
Defaults umask_override<br />
<br />
This sets sudo's umask to root's default umask (0022) and overrides the default behavior, always using the indicated umask regardless of what umask the user as set.<br />
<br />
<br />
=== Defaults Skeleton ===<br />
<br />
The authors site has a [http://www.gratisoft.us/sudo/sudoers.man.html#sudoers_options list of all the options] that can be used with the {{ic|Defaults}} command in the {{ic|/etc/sudoers}} file.<br />
<br />
The full list of options ''(parsed from the version 1.8.7 source code)'' is below in a format optimized for copying and pasting into your sudoers files for quick editing.<br />
<br />
{{bc|<nowiki>#Defaults always_set_home<br />
# If enabled, sudo will set the HOME environment variable to the home directory of the target user<br />
# (which is root unless the -u option is used). This effectively means that the -H option<br />
# always_set_home is only effective for configurations where either env_reset is disabled or HOME is present<br />
# in the env_keep list. Default: OFF<br />
<br />
#Defaults authenticate<br />
# If set, users must authenticate themselves via a password (or other means of authentication)<br />
# before they may run commands. This default may be overridden via the PASSWD and NOPASSWD<br />
<br />
#Defaults closefrom_override<br />
# If set, the user may use sudo's -C option which overrides the default starting<br />
# point at which sudo begins closing open file descriptors. Default: OFF<br />
<br />
#Defaults compress_io<br />
# If set, and sudo is configured to log a command's input or output, the I/O logs will be<br />
# compressed using zlib. This flag is on by default when sudo is compiled with zlib support.<br />
<br />
#Defaults env_editor<br />
# If set, visudo will use the value of the EDITOR or VISUAL environment variables before falling back on the default<br />
# editor list. Note that this may create a security hole as it allows th separated list of editors in the editor<br />
# variable. visudo will then only use the EDITOR or VISUAL if they match a value specified in editor. On by default.<br />
<br />
#Defaults env_reset<br />
# If set, sudo will run the command in a minimal environment containing the TERM, PATH, HOME, MAIL, SHELL, LOGNAME,<br />
# USER, USERNAME and SUDO_* variables. Any variables in the caller's env in the file specified by the env_file<br />
# option (if any). The default contents of the env_keep and env_check lists are displayed when sudo is run by<br />
# root with the -V option.<br />
<br />
#Defaults fast_glob<br />
# Normally, sudo uses the glob(3) function to do shell-style globbing when matching path names.<br />
# However, since it accesses the file system, glob(3) can take a long time to complete for som (automounted).<br />
# The fast_glob option causes sudo to use the fnmatch(3) function, which does not access the file system to do<br />
# its matching. The disadvantage of fast_glob is that it is unable to ma names that include globbing characters<br />
# are used with the negation operator, '!', as such rules can be trivially bypassed. As such, this option should<br />
# not be used when sudoers contains rules that<br />
<br />
#Defaults fqdn<br />
# Set this flag if you want to put fully qualified host names in the sudoers file. I.e., instead of myhost you<br />
# would use myhost.mydomain.edu. You may still use the short form if you wish (and sudo unusable if DNS stops<br />
# working (for example if the machine is not plugged into the network). Also note that you must use the<br />
# host's official name as DNS knows it. That is, you may not use a all aliases from DNS. If your machine's<br />
# host name (as returned by the hostname command) is already fully qualified you shouldn't need to set fqdn.<br />
# Default: OFF<br />
<br />
#Defaults ignore_dot<br />
# If set, sudo will ignore '.' or '' (current dir) in the PATH environment variable; the PATH<br />
# itself is not modified. Default: OFF<br />
<br />
#Defaults ignore_local_sudoers<br />
# If set via LDAP, parsing of /etc/sudoers will be skipped. This is intended for Enterprises that wish to prevent<br />
# the usage of local sudoers files so that only LDAP is used. /etc/sudoers does not even need to exist.<br />
# Since this option tells sudo how to behave when no specific LDAP entries have been matched, this sudo<br />
# Option is only meaningful for the cn=default<br />
<br />
#Defaults insults<br />
# If set, sudo will insult users when they enter an incorrect password. Default: OFF<br />
<br />
#Defaults log_host<br />
# If set, the host name will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults log_input<br />
# If set, sudo will run the command in a pseudo tty and log all user input. If the standard<br />
# input is not connected to the user's tty, due to I/O redirection or because the command is part Input is logged<br />
# to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that<br />
# is included in the normal sudo log line, prefixed with TSID=. Note that user input may contain sensitive<br />
# information such as passwords (even if they are not echoed to the screen), which will be stored in the log file<br />
# unencrypted.<br />
<br />
#Defaults log_output<br />
# If set, sudo will run the command in a pseudo tty and log all output that is sent to the<br />
# screen, similar to the script(1) command. If the standard output or standard error is not connec is also captured and<br />
# stored in separate log files. Output is logged to the directory specified by the iolog_dir option (/var/log/sudo-io<br />
# by default) using a unique session ID that is included in the normal sudo log line, prefixed with TSID=. The Output<br />
# logs may be viewed with the sudoreplay(8) utility, which can also be used to list or search the available logs.<br />
<br />
#Defaults log_year<br />
# If set, the four-digit year will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults long_otp_prompt<br />
# When validating with a One Time Password (OTP) scheme such as S/Key or OPIE, a two-line<br />
# prompt is used to make it easier to cut and paste the challenge to a local window<br />
<br />
#Defaults mail_always<br />
# Send mail to the mailto user every time a users runs sudo. Default: OFF<br />
<br />
#Defaults mail_badpass<br />
# Send mail to the mailto user if the user running sudo does not enter the correct password.<br />
# Default: OFF<br />
<br />
#Defaults mail_no_host<br />
# If set, mail will be sent to the mailto user if the invoking user exists in the sudoers<br />
# file, but is not allowed to run commands on the current host. Default: OFF<br />
<br />
#Defaults mail_no_perms<br />
# If set, mail will be sent to the mailto user if the invoking user is allowed to use sudo<br />
# but the command they are trying is not listed in their sudoers file entry or is explicitly denied<br />
<br />
#Defaults mail_no_user<br />
# If set, mail will be sent to the mailto user if the invoking user is not in the sudoers file.<br />
# Default: ON<br />
<br />
#Defaults noexec<br />
# If set, all commands run via sudo will behave as if the NOEXEC tag has been set, unless overridden<br />
# by a EXEC tag. See the description of NOEXEC and EXEC below as well as the "PREVENTING SHE<br />
<br />
#Defaults path_info<br />
# Normally, sudo will tell the user when a command could not be found in their PATH environment<br />
# variable. Some sites may wish to disable this as it could be used to gather information on t the executable is<br />
# simply not in the user's PATH, sudo will tell the user that they are not allowed to run it, which can be confusing.<br />
# Default: ON<br />
<br />
#Defaults passprompt_override<br />
# The password prompt specified by passprompt will normally only be used if the password prompt provided by<br />
# systems such as PAM matches the string "Password:"<br />
<br />
#Defaults preserve_groups<br />
# By default, sudo will initialize the group vector to the list of groups the target<br />
# user is in. When preserve_groups is set, the user's existing group vector is left unaltered.<br />
<br />
#Defaults pwfeedback<br />
# By default, sudo reads the password like most other Unix programs, by turning off echo<br />
# until the user hits the return (or enter) key. Some users become confused by this as it appears to the user<br />
# presses a key. Note that this does have a security impact as an onlooker may be able to determine the length of<br />
# the password being entered. Default: OFF<br />
<br />
#Defaults requiretty<br />
# If set, sudo will only run when the user is logged in to a real tty. When this flag is set,<br />
# sudo can only be run from a login session and not via other means such as cron(8) or cgi-bin<br />
<br />
#Defaults root_sudo<br />
# If set, root is allowed to run sudo too. Disabling this prevents users from "chaining" sudo<br />
# commands to get a root shell by doing something like "sudo sudo /bin/sh". Note, however, that real additional<br />
# security; it exists purely for historical reasons. Default: ON<br />
<br />
#Defaults rootpw<br />
# If set, sudo will prompt for the root password instead of the password of the invoking user.<br />
# Default: OFF<br />
<br />
#Defaults runaspw<br />
# If set, sudo will prompt for the password of the user defined by the runas_default option<br />
# (defaults to root) instead of the password of the invoking user. Default: OFF<br />
<br />
#Defaults set_home<br />
# If enabled and sudo is invoked with the -s option the HOME environment variable will be set<br />
# to the home directory of the target user (which is root unless the -u option is used). So set_home is only<br />
# effective for configs where either env_reset is disabled or HOME is present in the env_keep list. Default: OFF<br />
<br />
#Defaults set_logname<br />
# Normally, sudo will set the LOGNAME, USER and USERNAME environment variables to the name<br />
# of the target user (usually root unless the -u option is given). However, since some programs ( may be desirable<br />
# to change this behavior. This can be done by negating the set_logname option. Note that if the env_reset option<br />
# has not been disabled, entries in the env_keep list will override<br />
<br />
#Defaults set_utmp<br />
# When enabled, sudo will create an entry in the utmp (or utmpx) file when a pseudo-tty is<br />
# allocated. A pseudo-tty is allocated by sudo when the log_input, log_output or use_pty flags are e the tty, time,<br />
# type and pid fields updated. Default: ON<br />
<br />
#Defaults setenv<br />
# Allow the user to disable the env_reset option from the command line via the -E option.<br />
# Additionally, environment variables set via the command line are not subject to the restrictions impo variables<br />
# in this manner. Default: OFF<br />
<br />
#Defaults shell_noargs<br />
# If set and sudo is invoked with no arguments it acts as if the -s option had been given.<br />
# That is, it runs a shell as root (the shell is determined by the SHELL environment variable if is off by default.<br />
<br />
#Defaults stay_setuid<br />
# Normally, when sudo executes a command the real and effective UIDs are set to the target<br />
# user (root by default). This option changes that behaviour such that the real UID is left as the systems that<br />
# disable some potentially dangerous functionality when a program is run setuid. This option is only effective on<br />
# systems with either the setreuid() or setresuid() function. This flag<br />
<br />
#Defaults targetpw<br />
# If set, sudo will prompt for the password of the user specified by the -u option (defaults to root) instead<br />
# of the password of the invoking user. In addition, the timestamp file name will passwd database as an argument<br />
# to the -u option. Default: OFF<br />
<br />
#Defaults tty_tickets<br />
# If set, users must authenticate on a per-tty basis. With this flag enabled, sudo will<br />
# use a file named for the tty the user is logged in on in the user's time stamp directory.<br />
<br />
#Defaults umask_override<br />
# If set, sudo will set the umask as specified by sudoers without modification. This makes<br />
# it possible to specify a more permissive umask in sudoers than the user's own umask and match user's umask and what<br />
# is specified in sudoers. Default: OFF<br />
<br />
#Defaults use_pty<br />
# If set, sudo will run the command in a pseudo-pty even if no I/O logging is being gone.<br />
# A malicious program run under sudo could conceivably fork a background process that retains to the u that impossible.<br />
# Default: OFF<br />
<br />
#Defaults utmp_runas<br />
# If set, sudo will store the name of the runas user when updating the utmp (or utmpx) file.<br />
# By default, sudo stores the name of the invoking user. Default: OFF<br />
<br />
#Defaults visiblepw<br />
# By default, sudo will refuse to run if the user must enter a password but it is not possible to disable echo on the <br />
# terminal. If the visiblepw flag is set, sudo will prompt for a password even when it would be visible on the screen. <br />
# This makes it possible to run things like "rsh somehost sudo ls" since rsh(1) does not allocate a tty. Default: OFF<br />
<br />
#Defaults closefrom<br />
# Before it executes a command, sudo will close all open file descriptors other than standard<br />
# input, standard output and standard error (ie: file descriptors 0-2).<br />
<br />
#Defaults passwd_tries<br />
# The number of tries a user gets to enter his/her password before sudo logs the failure<br />
# and exits. The default is 3.<br />
<br />
#Defaults loglinelen<br />
# Number of characters per line for the file log. This value is used to decide when to wrap<br />
# lines for nicer log files. This has no effect on the syslog log file, only the file log.<br />
<br />
#Defaults passwd_timeout<br />
# Number of minutes before the sudo password prompt times out, or 0 for no timeout.<br />
# The timeout may include a fractional component if minute granularity is insufficient, for example 2<br />
<br />
#Defaults timestamp_timeout<br />
# Number of minutes that can elapse before sudo will ask for a passwd again. The timeout<br />
# may include a fractional component if minute granularity is insufficient, for example 2.5. timestamp will never expire.<br />
# This can be used to allow users to create or delete their own timestamps via sudo -v and sudo -k respectively.<br />
<br />
#Defaults umask<br />
# Umask to use when running the command. Negate this option or set it to 0777 to preserve<br />
# the user's umask. The actual umask that is used will be the union of the user's umask and the value o running<br />
# a command. Note on systems that use PAM, the default PAM configuration may specify its own umask which will<br />
# override the value set in sudoers.<br />
<br />
#Defaults badpass_message<br />
# Message that is displayed if a user enters an incorrect password. The default is Sorry,<br />
# try again. unless insults are enabled.<br />
<br />
#Defaults editor<br />
# A colon (':') separated list of editors allowed to be used with visudo. visudo will choose<br />
# the editor that matches the user's EDITOR environment variable if possible, or the first editor in<br />
<br />
#Defaults iolog_dir<br />
# The top-level directory to use when constructing the path name for the input/output log<br />
# directory. Only used if the log_input or log_output options are enabled or when the LOG_INPUT or L directory.<br />
# The default is "/var/log/sudo-io". The following percent (%) escape sequences are supported:<br />
# %{seq} - expanded to base-36 sequence number, such as 0100A5, to form a new directory, e.g. 01/00/A5<br />
# %{user} - expanded to the invoking user's login name<br />
# %{group} - expanded to the name of the invoking user's real group ID<br />
# %{runas_user} - expanded to the login name of the user the command will be run as (e.g. root)<br />
# %{runas_group} - expanded to the group name of the user the command will be run as (e.g. wheel)<br />
# %{hostname} - expanded to the local host name without the domain name<br />
# %{command} - expanded to the base name of the command being run In addition, any escape sequences supported by<br />
# strftime() function will be expanded. To include a literal % character, the string %% should be used.<br />
<br />
#Defaults iolog_file<br />
# The path name, relative to iolog_dir, in which to store input/output logs when the log_input or log_output options are<br />
# enabled or when the LOG_INPUT or LOG_OUTPUT tags are present for a See the iolog_dir option above for a list of<br />
# supported percent (%) escape sequences. In addition to the escape sequences, path names that end in six or more Xs will<br />
# have the Xs replaced with a unique combination of digits and letters, similar to the mktemp() function.<br />
<br />
#Defaults mailsub<br />
# Subject of the mail sent to the mailto user. The escape %h will expand to the host name of<br />
# the machine. Default is *** SECURITY information for %h ***.<br />
<br />
#Defaults noexec_file<br />
# This option is no longer supported. The path to the noexec file should now be set in the /etc/sudo.conf file.<br />
<br />
#Defaults passprompt<br />
# The default prompt to use when asking for a password; can be overridden via the -p option or the SUDO_PROMPT<br />
# environment variable. The following percent (%) escape sequences are supported:<br />
# %H - expanded to the local host name including the domain (only if the host name is fqdn or fqdn option is set)<br />
# %h - expanded to the local host name without the domain name<br />
# %p - expanded to the user whose password is being asked for (respects the rootpw, targetpw and runaspw flags)<br />
# %U - expanded to the login name of the user the command will be run as (defaults to root)<br />
# %u - expanded to the invoking user's login name<br />
# %% - two consecutive % characters are collapsed into a single % character<br />
# The default value is Password:.<br />
<br />
#Defaults runas_default<br />
# The default user to run commands as if the -u option is not specified on the command line. This defaults to root.<br />
<br />
#Defaults syslog_badpri<br />
# Syslog priority to use when user authenticates unsuccessfully. Defaults to alert.<br />
# alert, crit, debug, emerg, err, info, notice, and warning.<br />
<br />
#Defaults syslog_goodpri<br />
# Syslog priority to use when user authenticates successfully. Defaults to notice. See syslog_badpri for the priorities.<br />
<br />
#Defaults sudoers_locale<br />
# Locale to use when parsing the sudoers file, logging commands, and sending email.<br />
# Note that changing the locale may affect how sudoers is interpreted. Defaults to "C".<br />
<br />
#Defaults timestampdir<br />
# The directory in which sudo stores its timestamp files. The default is /var/db/sudo.<br />
<br />
#Defaults timestampowner<br />
# The owner of the timestamp directory and the timestamps stored therein. The default is root.<br />
<br />
#Defaults env_file<br />
# The env_file option specifies the fully qualified path to a file containing variables to<br />
# be set in the environment of the program being run. Entries in this file should either be of the f quotes.<br />
# Variables in this file are subject to other sudo environment settings such as env_keep and env_check.<br />
<br />
#Defaults exempt_group<br />
# Users in this group are exempt from password and PATH requirements. The group name specified should not include<br />
# a % prefix. This is not set by default.<br />
<br />
#Defaults group_plugin<br />
# A string containing a sudoers group plugin with optional arguments. This can be used to implement support for the<br />
# nonunix_group syntax described earlier. The string should consist of configuration arguments the plugin requires.<br />
# These arguments (if any) will be passed to the plugin's initialization function. If arguments are present, the<br />
# string must be enclosed in double quote For example, given /etc/sudo-group, a group file in Unix group format,<br />
# the sample group plugin can be used: Defaults group_plugin="sample_group.so /etc/sudo-group"<br />
# For more information see sudo_plugin(5).<br />
<br />
#Defaults lecture<br />
# This option controls when a short lecture will be printed along with the password prompt. The default value is once.<br />
# It has the following possible values:<br />
# always - Always lecture the user.<br />
# never - Never lecture the user.<br />
# once - Only lecture the user the first time they run sudo.<br />
# If no value is specified, a value of once is implied. Negating the option results in a value of never being used.<br />
<br />
#Defaults lecture_file<br />
# Path to a file containing an alternate sudo lecture that will be used in place of the standard lecture if the named<br />
# file exists. By default, sudo uses a built-in lecture.<br />
<br />
#Defaults listpw<br />
# This option controls when a password will be required when a user runs sudo with the -l option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD set to avoid entering a pass.<br />
# always - The user must always enter a password to use the -l option.<br />
# any - At least one of the user's sudoers entries for the current host must have the NOPASSWD set to avoid pass.<br />
# never - The user need never enter a password to use the -l option.<br />
# If no value is specified, a value of any is implied. The default value is any.<br />
<br />
#Defaults logfile<br />
# Path to the sudo log file (not the syslog log file). Setting a path turns on logging to a file;<br />
# negating this option turns it off. By default, sudo logs via syslog.<br />
<br />
#Defaults mailerflags<br />
# Flags to use when invoking mailer. Defaults to -t.<br />
<br />
#Defaults mailerpath<br />
# Path to mail program used to send warning mail. Defaults to the path to sendmail found at configure time.<br />
<br />
#Defaults mailfrom<br />
# Address to use for the "from" address when sending warning and error mail. The address should<br />
# be enclosed in double quotes (") to protect against sudo interpreting the @ sign.<br />
<br />
#Defaults mailto<br />
# Address to send warning and error mail to. The address should be enclosed in double quotes<br />
# (") to protect against sudo interpreting the @ sign. Defaults to root.<br />
<br />
#Defaults secure_path<br />
# Path used for every command run from sudo. If you don't trust the people running sudo to have a sane PATH environment<br />
# variable you may want to use this. Another use is if you want to option are not affected by secure_path.<br />
# This option is not set by default.<br />
<br />
#Defaults syslog<br />
# Syslog facility if syslog is being used for logging (negate to disable syslog logging). Defaults to auth.<br />
# authpriv (if OS supports it), auth, daemon, user, local0, local1, local2, local3, local4, local5, local6, and local7.<br />
<br />
#Defaults verifypw<br />
# This option controls when a password will be required when a user runs sudo with the -v option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD flag to avoid pw.<br />
# always - The user must always enter a password to use the -v option.<br />
# any - At least one of the user's sudoers entries for the current host must have NOPASSWD to avoid pw.<br />
# never - The user need never enter a password to use the -v option<br />
# If no value is specified, a value of all is implied. Negating the option results in a value of never being used.<br />
# The default value is all.<br />
<br />
#Defaults env_check<br />
# Environment variables to be removed from the user's environment if the variable's value contains % or / characters.<br />
# This can be used to guard against printf-style format vulnerabilities value without double-quotes. The list can be<br />
# replaced, added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively. Regardless of<br />
# whether the env_reset option is ena they pass the aforementioned check. The default list of environment variables<br />
# to check is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_delete<br />
# Environment variables to be removed from the user's environment when the env_reset option is not in effect. The<br />
# argument may be a double-quoted, space-separated list or a single value w +=, -=, and ! operators respectively.<br />
# The default list of environment variables to remove is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_keep<br />
# Environment variables to be preserved in the user's environment when the env_reset option is in effect. This<br />
# allows fine-grained control over the environment sudo-spawned processes will r quotes. The list can be replaced,<br />
# added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively.</nowiki>}}</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Sudo&diff=285340Sudo2013-11-30T05:06:01Z<p>Hunterthomson: /* Harden with Sudo Example */</p>
<hr />
<div>[[Category:Security]]<br />
[[cs:Sudo]]<br />
[[es:Sudo]]<br />
[[fr:Sudo]]<br />
[[it:Sudo]]<br />
[[ja:Sudo]]<br />
[[ru:Sudo]]<br />
[[sr:Sudo]]<br />
[[tr:Sudo]]<br />
[[uk:Sudo]]<br />
[[zh-CN:Sudo]]<br />
{{Related articles start}}<br />
{{Related|Users and Groups}}<br />
{{Related|su}}<br />
{{Related articles end}}<br />
<br />
[http://www.gratisoft.us/sudo/ sudo] ("substitute user do") allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments.<br />
<br />
== Rationale ==<br />
<br />
Sudo is an alternative to [[su]] for running commands as root. Unlike [[su]], which launches a root shell that allows all further commands root access, sudo instead grants temporary privilege escalation to a single command. By enabling root privileges only when needed, sudo usage reduces the likelyhood that a typo or a bug in an invoked command will ruin the system.<br />
Sudo can also be used to run commands as other users; additionally, sudo logs all commands and failed access attempts for security auditing.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|sudo}} package, available in the [[Official Repositories|official repositories]]:<br />
<br />
# pacman -S sudo<br />
<br />
To begin using {{ic|sudo}} as a non-privileged user, it must be properly configured. So make sure you read the configuration section.<br />
<br />
== Usage ==<br />
<br />
With sudo, users can prefix commands with {{ic|sudo}} to run them with superuser (or other) privileges.<br />
<br />
For example, to use pacman:<br />
<br />
$ sudo pacman -Syu<br />
<br />
See the [http://www.gratisoft.us/sudo/man/sudo.html sudo manual] for more information.<br />
<br />
== Configuration ==<br />
<br />
=== View current settings ===<br />
<br />
Run {{ic|sudo -ll}} to print out the current sudo configuration.<br />
<br />
=== Using visudo ===<br />
<br />
The configuration file for sudo is {{ic|/etc/sudoers}}. It should '''always''' be edited with the {{ic|visudo}} command. {{ic|visudo}} locks the {{ic|sudoers}} file, saves edits to a temporary file, and checks that file's grammar before copying it to {{ic|/etc/sudoers}}.<br />
<br />
{{Warning|It is imperative that {{ic|sudoers}} be free of syntax errors! Any error makes sudo unusable. '''Always''' edit it with {{ic|visudo}} to prevent errors.}}<br />
<br />
The default editor for visudo is {{ic|vi}}. It will be used if you do not specify another editor, by setting either VISUAL or EDITOR environment variables (used in that order) to the desired editor, e.g. {{ic|nano}}. The command is run as root:<br />
<br />
# EDITOR=nano visudo<br />
<br />
You can permanently change the setting for your user to e.g. {{ic|nano}} by appending:<br />
<br />
export EDITOR=nano<br />
<br />
to your {{ic|~/.bashrc}} file. Note that this won't take effect for already-running shells.<br />
<br />
To change the editor of choice permanently system-wide only for {{ic|visudo}}, add the following line to {{ic|/etc/sudoers}} where {{ic|nano}} is your prefered editor:<br />
<br />
# Reset environment by default<br />
Defaults env_reset<br />
# Set default EDITOR to nano, and do not allow visudo to use EDITOR/VISUAL.<br />
Defaults editor=/usr/bin/nano, !env_editor<br />
<br />
=== Example Entries ===<br />
<br />
To allow a user to gain full root privileges when he/she precedes a command with {{ic|sudo}}, add the following line:<br />
<br />
USER_NAME ALL=(ALL) ALL<br />
<br />
To allow a user to run all commands as any user but only the machine with hostname HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=(ALL) ALL<br />
<br />
To allow members of group {{ic|wheel}} sudo access:<br />
<br />
%wheel ALL=(ALL) ALL<br />
<br />
To disable asking for a password for user USER_NAME:<br />
<br />
Defaults:USER_NAME !authenticate<br />
<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=/usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
{{note| the most customized option should go at the end of the file, as the later lines overrides the previous ones. In particular such a line should be after the {{ic|%wheel}} line if your user is in this group.}}<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME without password:<br />
USER_NAME HOST_NAME= NOPASSWD: /usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
<br />
A detailed sudoers example can be found [http://www.gratisoft.us/sudo/sample.sudoers here]. Otherwise, see the [http://www.gratisoft.us/sudo/man/sudoers.html sudoers manual] for detailed information.<br />
<br />
=== Sudoers default file permissions ===<br />
<br />
The owner and group for the sudoers file must both be 0. The file permissions must be set to 0440. These permissions are set by default, but if you accidentally change them, they should be changed back immediately or sudo will fail.<br />
<br />
# chown -c root:root /etc/sudoers<br />
# chmod -c 0440 /etc/sudoers<br />
<br />
=== Password cache timeout ===<br />
<br />
Users may wish to change the default timeout before the cached password expires. This is accomplished with the timestamp_timeout option in {{ic|/etc/sudoers}} which is in minutes.<br />
Set timeout to 20 minutes.<br />
<br />
Defaults:USER_NAME timestamp_timeout=20<br />
<br />
{{Tip|To ensure sudo always asks for a password, set the timeout to 0. To ensure the password never times out, set to less than 0.}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== File example ===<br />
<br />
This example is especially helpful for those using terminal multiplexers like screen, tmux, or ratpoison, and those using sudo from scripts/cronjobs:<br />
<br />
{{hc|/etc/sudoers|<nowiki><br />
Cmnd_Alias WHEELER = /usr/bin/lsof, /bin/nice, /bin/ps, /usr/bin/top, /usr/local/bin/nano, /usr/bin/ss, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync<br />
Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/kill, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
Cmnd_Alias EDITS = /usr/bin/vim, /usr/bin/nano, /usr/bin/cat, /usr/bin/vi<br />
Cmnd_Alias ARCHLINUX = /usr/bin/gparted, /usr/bin/pacman<br />
<br />
root ALL = (ALL) ALL<br />
USER_NAME ALL = (ALL) ALL, NOPASSWD: WHEELER, NOPASSWD: PROCESSES, NOPASSWD: ARCHLINUX, NOPASSWD: EDITS<br />
<br />
Defaults !requiretty, !tty_tickets, !umask<br />
Defaults visiblepw, path_info, insults, lecture=always<br />
Defaults loglinelen = 0, logfile =/var/log/sudo.log, log_year, log_host, syslog=auth<br />
Defaults mailto=webmaster@foobar.com, mail_badpass, mail_no_user, mail_no_perms<br />
Defaults passwd_tries = 8, passwd_timeout = 1<br />
Defaults env_reset, always_set_home, set_home, set_logname<br />
Defaults !env_editor, editor="/usr/bin/vim:/usr/bin/vi:/usr/bin/nano"<br />
Defaults timestamp_timeout=360<br />
Defaults passprompt="Sudo invoked by [%u] on [%H] - Cmd run as %U - Password for user %p:"<br />
</nowiki>}}<br />
<br />
=== Enabling Tab-completion in Bash ===<br />
<br />
{{ic|Tab}}-completion, by default, will not work when a user is initially added to the sudoers file. For example, normally john only needs to type:<br />
<br />
$ fire<{{ic|Tab}}><br />
<br />
and the shell will complete the command for him as:<br />
<br />
$ firefox<br />
<br />
If, however, john is added to the sudoers file and he types:<br />
<br />
$ sudo fire<{{ic|Tab}}><br />
<br />
the shell will do nothing.<br />
<br />
To enable {{ic|Tab}}-completion with sudo, [[pacman|install]] the {{pkg|bash-completion}} package from the [[Official Repositories|official repositories]]. see [[bash#Tab_completion]] for more information.<br />
<br />
Alternatively, add the following to your {{ic|~/.bashrc}}:<br />
<br />
complete -cf sudo<br />
<br />
=== Run X11 apps using sudo ===<br />
<br />
To allow sudo to start graphical application in X11, you need to add:<br />
<br />
Defaults env_keep += "HOME"<br />
<br />
to visudo.<br />
<br />
=== Disable per-terminal sudo ===<br />
<br />
{{Warning|This will let any process use your sudo session.}}<br />
<br />
If you are annoyed by sudo's defaults that require you to enter your password every time you open a new terminal, disable '''tty_tickets''':<br />
<br />
Defaults !tty_tickets<br />
<br />
=== Environment variables ===<br />
<br />
If you have a lot of environment variables, or you export your proxy settings via {{ic|1=export http_proxy="..."}}, when using sudo these variables do not get passed to the root account unless you run sudo with the {{ic|-E}} option.<br />
<br />
$ sudo -E pacman -Syu<br />
<br />
The recommended way of preserving environment variables is to append them to {{ic|env_keep}}:<br />
{{hc|/etc/sudoers|<nowiki><br />
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"<br />
</nowiki>}}<br />
<br />
=== Passing aliases ===<br />
<br />
If you use a lot of aliases, you might have noticed that they do not carry over to the root account when using sudo. However, there is an easy way to make them work. Simply add the following to your {{ic|~/.bashrc}} or {{ic|/etc/bash.bashrc}}:<br />
<br />
alias sudo='sudo '<br />
<br />
=== Insults ===<br />
<br />
Users can configure sudo to display clever insults when an incorrect password is entered instead of printing the default "wrong password" message. Find the Defaults line in {{ic|/etc/sudoers}} and append "insults" after a comma to existing options. The final result might look like this:<br />
<br />
#Defaults specification<br />
Defaults insults<br />
<br />
To test, type {{ic|sudo -K}} to end the current session and let sudo ask for the password again.<br />
<br />
=== Root password ===<br />
<br />
Users can configure sudo to ask for the root password instead of the user password by adding "rootpw" to the Defaults line in {{ic|/etc/sudoers}}:<br />
<br />
Defaults timestamp_timeout=0,rootpw<br />
<br />
=== Disable root login ===<br />
<br />
{{Warning|Arch Linux is not fine-tuned to run with a disabled root account. Users may encounter problems with this method.}}<br />
<br />
With sudo installed and configured, users may wish to disable the root login. Without root, attackers must first guess a user name configured as a sudoer as well as the user password.<br />
<br />
{{Warning|Ensure a user is properly configured as a sudoer ''before'' disabling the root account!}}<br />
<br />
The account can be locked via {{ic|passwd}}:<br />
<br />
# passwd -l root<br />
<br />
A similar command unlocks root.<br />
<br />
$ sudo passwd -u root<br />
<br />
Alternatively, edit {{ic|/etc/shadow}} and replace the root's encrypted password with "!":<br />
<br />
root:!:12345::::::<br />
<br />
To enable root login again:<br />
<br />
$ sudo passwd root<br />
<br />
==== kdesu ====<br />
<br />
kdesu may be used under KDE to launch GUI applications with root privileges. It is possible that by default kdesu will try to use su even if the root account is disabled. Fortunately one can tell kdesu to use sudo instead of su. Create/edit the file {{ic|~/.kde4/share/config/kdesurc}}:<br />
<br />
[super-user-command]<br />
super-user-command=sudo<br />
<br />
==== PolicyKit ====<br />
<br />
When disabling the root account, it is necessary to change the [[PolicyKit]] configuration for local authorization to reflect that. The default is to ask for the root password, so that must be changed. With polkit-1, this can be achieved by editing {{ic|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf}} so that {{ic|1=AdminIdentities=unix-user:0}} is replaced with something else, depending on the system configuration. It can be a list of users and groups, for example:<br />
<br />
AdminIdentities=unix-group:wheel<br />
<br />
or<br />
<br />
AdminIdentities=unix-user:me;unixuser:mom;unix-group:wheel<br />
<br />
For more information, see {{ic|man pklocalauthority}}.<br />
<br />
==== NetworkManager ====<br />
<br />
Even with the above PolicyKit configuration you still need to configure a policy for NetworkManager. This is documented on the [[NetworkManager#Can.27t_edit_connections_as_normal_user|NetworkManager]] page of this wiki.<br />
<br />
=== Harden with Sudo Example ===<br />
<br />
Lets say you create 3 users: admin, devel, and Joe<br />
admin is used for journalctl, systemctl, mount, kill, and iptables.<br />
devel is used for installing packages, and editing config's<br />
Joe is the user you log in with. Let's let him reboot, shutdown, and use netctl<br />
<br />
Edit /etc/pam.d/su and /etc/pam.d/su-1<br />
Require user be in the wheel group, but don't put anyone in it.<br />
#%PAM-1.0<br />
auth sufficient pam_rootok.so<br />
# Uncomment the following line to implicitly trust users in the "wheel" group.<br />
#auth sufficient pam_wheel.so trust use_uid<br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
auth required pam_unix.so<br />
account required pam_unix.so<br />
session required pam_unix.so<br />
<br />
Limit SSH login to the 'ssh' group, Only put Joe in it<br />
groupadd -r ssh<br />
gpasswd -a Joe ssh<br />
echo 'AllowGroups ssh' >> /etc/ssh/sshd_config<br />
systemctl restart sshd.service<br />
<br />
Lets add users to other goups.<br />
for g in power network ;do ;gpasswd -a Joe $g ;done<br />
for g in network power storage ;do ;gpasswd -a admin $g ;done<br />
<br />
Set permissions on configs so devel can edit them.<br />
chown -R devel:root /etc/{http,openvpn,cups,zsh,vim,screenrc}<br />
<br />
Cmnd_Alias POWER = /usr/bin/shutdown -h now, /usr/bin/halt, /usr/bin/poweroff, /usr/bin/reboot<br />
Cmnd_Alias STORAGE = /usr/bin/mount, /usr/bin/umount<br />
Cmnd_Alias SYSTEMD = /usr/bin/journalctl, /usr/bin/systemctl<br />
Cmnd_Alias KILL = /usr/bin/kill, /usr/bin/killall<br />
Cmnd_Alias PKGMAN = /usr/bin/pacman<br />
Cmnd_Alias NETWORK = /usr/bin/netctl<br />
Cmnd_Alias FIREWALL = /usr/bin/iptables, /usr/bin/ip6tables<br />
Cmnd_Alias SHELL = /usr/bin/zsh, /usr/bin/bash<br />
%power ALL = (root) NOPASSWD: POWER<br />
%network ALL = (root) NETWORK<br />
%storage ALL = (root) STORAGE<br />
root ALL = (ALL) ALL<br />
admin ALL = (root) SYSTEMD, KILL, FIREWALL<br />
devel ALL = (root) PKGMAN<br />
Joe ALL = (devel) SHELL, (admin) SHELL <br />
<br />
With this setup, you will almost never need to login as the Root user.<br />
<br />
Joe can connect to his home WiFi<br />
sudo netctl start home<br />
sudo poweroff<br />
<br />
Joe can not use netctl as any other user like admin...<br />
sudo -u admin -- netctl start home<br />
<br />
When Joe needs to use journalctl or kill run away process he can switch to that user<br />
sudo -i -u devel<br />
sudo -i -u admin<br />
<br />
But not Root<br />
sudo -i -u root<br />
<br />
If joe want to start a gnu-screen session as admin he can do it like this<br />
sudo -i -u admin<br />
admin% chown admin:tty `echo $TTY`<br />
admin% screen<br />
<br />
== Troubleshooting ==<br />
<br />
=== SSH TTY Issues ===<br />
<br />
SSH does not allocate a tty by default when running a remote command. Without a tty, sudo cannot disable echo when prompting for a password. You can use ssh's {{ic|-tt}} option to force it to allocate a tty (or {{ic|-t}} twice).<br />
<br />
The {{ic|Defaults}} option {{ic|requiretty}} only allows the user to run sudo if they have a tty.<br />
<br />
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear text. You have to run "ssh -t hostname sudo <cmd>".<br />
#<br />
#Defaults requiretty<br />
<br />
=== Display User Privileges ===<br />
<br />
You can find out what privileges a particular user has with the following command:<br />
<br />
$ sudo -lU yourusename<br />
<br />
Or view your own with:<br />
<br />
{{hc|$ sudo -l|<nowiki><br />
Matching Defaults entries for yourusename on this host:<br />
loglinelen=0, logfile=/var/log/sudo.log, log_year, syslog=auth, mailto=webmaster@gmail.com, mail_badpass, mail_no_user,<br />
mail_no_perms,env_reset, always_set_home, tty_tickets, lecture=always, pwfeedback, rootpw, set_home<br />
<br />
User yourusename may run the following commands on this host:<br />
<br />
(ALL) ALL<br />
(ALL) NOPASSWD: /usr/bin/lsof, /bin/nice, /usr/bin/su, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync, /usr/bin/strace,<br />
(ALL) /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
(ALL) /usr/bin/gparted, /usr/bin/pacman<br />
(ALL) /usr/local/bin/synergyc, /usr/local/bin/synergys<br />
(ALL) /usr/bin/vim, /usr/bin/nano, /usr/bin/cat<br />
(root) NOPASSWD: /usr/local/bin/synergyc</nowiki>}}<br />
<br />
=== Permissive Umask ===<br />
<br />
Sudo will union the user's [[umask]] value with its own umask (which defaults to 0022). This prevents sudo from creating files with more open permissions than the user's umask allows. While this is a sane default if no custom umask is in use, this can lead to situations where a utility run by sudo may create files with different permissions than if run by root directly. If errors arise from this, sudo provides a means to fix the umask, even if the desired umask is more permissive than the umask that the user has specified. Adding this (using {{ic|visudo}}) will override sudo's default behavior:<br />
<br />
Defaults umask = 0022<br />
Defaults umask_override<br />
<br />
This sets sudo's umask to root's default umask (0022) and overrides the default behavior, always using the indicated umask regardless of what umask the user as set.<br />
<br />
<br />
=== Defaults Skeleton ===<br />
<br />
The authors site has a [http://www.gratisoft.us/sudo/sudoers.man.html#sudoers_options list of all the options] that can be used with the {{ic|Defaults}} command in the {{ic|/etc/sudoers}} file.<br />
<br />
The full list of options ''(parsed from the version 1.8.7 source code)'' is below in a format optimized for copying and pasting into your sudoers files for quick editing.<br />
<br />
{{bc|<nowiki>#Defaults always_set_home<br />
# If enabled, sudo will set the HOME environment variable to the home directory of the target user<br />
# (which is root unless the -u option is used). This effectively means that the -H option<br />
# always_set_home is only effective for configurations where either env_reset is disabled or HOME is present<br />
# in the env_keep list. Default: OFF<br />
<br />
#Defaults authenticate<br />
# If set, users must authenticate themselves via a password (or other means of authentication)<br />
# before they may run commands. This default may be overridden via the PASSWD and NOPASSWD<br />
<br />
#Defaults closefrom_override<br />
# If set, the user may use sudo's -C option which overrides the default starting<br />
# point at which sudo begins closing open file descriptors. Default: OFF<br />
<br />
#Defaults compress_io<br />
# If set, and sudo is configured to log a command's input or output, the I/O logs will be<br />
# compressed using zlib. This flag is on by default when sudo is compiled with zlib support.<br />
<br />
#Defaults env_editor<br />
# If set, visudo will use the value of the EDITOR or VISUAL environment variables before falling back on the default<br />
# editor list. Note that this may create a security hole as it allows th separated list of editors in the editor<br />
# variable. visudo will then only use the EDITOR or VISUAL if they match a value specified in editor. On by default.<br />
<br />
#Defaults env_reset<br />
# If set, sudo will run the command in a minimal environment containing the TERM, PATH, HOME, MAIL, SHELL, LOGNAME,<br />
# USER, USERNAME and SUDO_* variables. Any variables in the caller's env in the file specified by the env_file<br />
# option (if any). The default contents of the env_keep and env_check lists are displayed when sudo is run by<br />
# root with the -V option.<br />
<br />
#Defaults fast_glob<br />
# Normally, sudo uses the glob(3) function to do shell-style globbing when matching path names.<br />
# However, since it accesses the file system, glob(3) can take a long time to complete for som (automounted).<br />
# The fast_glob option causes sudo to use the fnmatch(3) function, which does not access the file system to do<br />
# its matching. The disadvantage of fast_glob is that it is unable to ma names that include globbing characters<br />
# are used with the negation operator, '!', as such rules can be trivially bypassed. As such, this option should<br />
# not be used when sudoers contains rules that<br />
<br />
#Defaults fqdn<br />
# Set this flag if you want to put fully qualified host names in the sudoers file. I.e., instead of myhost you<br />
# would use myhost.mydomain.edu. You may still use the short form if you wish (and sudo unusable if DNS stops<br />
# working (for example if the machine is not plugged into the network). Also note that you must use the<br />
# host's official name as DNS knows it. That is, you may not use a all aliases from DNS. If your machine's<br />
# host name (as returned by the hostname command) is already fully qualified you shouldn't need to set fqdn.<br />
# Default: OFF<br />
<br />
#Defaults ignore_dot<br />
# If set, sudo will ignore '.' or '' (current dir) in the PATH environment variable; the PATH<br />
# itself is not modified. Default: OFF<br />
<br />
#Defaults ignore_local_sudoers<br />
# If set via LDAP, parsing of /etc/sudoers will be skipped. This is intended for Enterprises that wish to prevent<br />
# the usage of local sudoers files so that only LDAP is used. /etc/sudoers does not even need to exist.<br />
# Since this option tells sudo how to behave when no specific LDAP entries have been matched, this sudo<br />
# Option is only meaningful for the cn=default<br />
<br />
#Defaults insults<br />
# If set, sudo will insult users when they enter an incorrect password. Default: OFF<br />
<br />
#Defaults log_host<br />
# If set, the host name will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults log_input<br />
# If set, sudo will run the command in a pseudo tty and log all user input. If the standard<br />
# input is not connected to the user's tty, due to I/O redirection or because the command is part Input is logged<br />
# to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that<br />
# is included in the normal sudo log line, prefixed with TSID=. Note that user input may contain sensitive<br />
# information such as passwords (even if they are not echoed to the screen), which will be stored in the log file<br />
# unencrypted.<br />
<br />
#Defaults log_output<br />
# If set, sudo will run the command in a pseudo tty and log all output that is sent to the<br />
# screen, similar to the script(1) command. If the standard output or standard error is not connec is also captured and<br />
# stored in separate log files. Output is logged to the directory specified by the iolog_dir option (/var/log/sudo-io<br />
# by default) using a unique session ID that is included in the normal sudo log line, prefixed with TSID=. The Output<br />
# logs may be viewed with the sudoreplay(8) utility, which can also be used to list or search the available logs.<br />
<br />
#Defaults log_year<br />
# If set, the four-digit year will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults long_otp_prompt<br />
# When validating with a One Time Password (OTP) scheme such as S/Key or OPIE, a two-line<br />
# prompt is used to make it easier to cut and paste the challenge to a local window<br />
<br />
#Defaults mail_always<br />
# Send mail to the mailto user every time a users runs sudo. Default: OFF<br />
<br />
#Defaults mail_badpass<br />
# Send mail to the mailto user if the user running sudo does not enter the correct password.<br />
# Default: OFF<br />
<br />
#Defaults mail_no_host<br />
# If set, mail will be sent to the mailto user if the invoking user exists in the sudoers<br />
# file, but is not allowed to run commands on the current host. Default: OFF<br />
<br />
#Defaults mail_no_perms<br />
# If set, mail will be sent to the mailto user if the invoking user is allowed to use sudo<br />
# but the command they are trying is not listed in their sudoers file entry or is explicitly denied<br />
<br />
#Defaults mail_no_user<br />
# If set, mail will be sent to the mailto user if the invoking user is not in the sudoers file.<br />
# Default: ON<br />
<br />
#Defaults noexec<br />
# If set, all commands run via sudo will behave as if the NOEXEC tag has been set, unless overridden<br />
# by a EXEC tag. See the description of NOEXEC and EXEC below as well as the "PREVENTING SHE<br />
<br />
#Defaults path_info<br />
# Normally, sudo will tell the user when a command could not be found in their PATH environment<br />
# variable. Some sites may wish to disable this as it could be used to gather information on t the executable is<br />
# simply not in the user's PATH, sudo will tell the user that they are not allowed to run it, which can be confusing.<br />
# Default: ON<br />
<br />
#Defaults passprompt_override<br />
# The password prompt specified by passprompt will normally only be used if the password prompt provided by<br />
# systems such as PAM matches the string "Password:"<br />
<br />
#Defaults preserve_groups<br />
# By default, sudo will initialize the group vector to the list of groups the target<br />
# user is in. When preserve_groups is set, the user's existing group vector is left unaltered.<br />
<br />
#Defaults pwfeedback<br />
# By default, sudo reads the password like most other Unix programs, by turning off echo<br />
# until the user hits the return (or enter) key. Some users become confused by this as it appears to the user<br />
# presses a key. Note that this does have a security impact as an onlooker may be able to determine the length of<br />
# the password being entered. Default: OFF<br />
<br />
#Defaults requiretty<br />
# If set, sudo will only run when the user is logged in to a real tty. When this flag is set,<br />
# sudo can only be run from a login session and not via other means such as cron(8) or cgi-bin<br />
<br />
#Defaults root_sudo<br />
# If set, root is allowed to run sudo too. Disabling this prevents users from "chaining" sudo<br />
# commands to get a root shell by doing something like "sudo sudo /bin/sh". Note, however, that real additional<br />
# security; it exists purely for historical reasons. Default: ON<br />
<br />
#Defaults rootpw<br />
# If set, sudo will prompt for the root password instead of the password of the invoking user.<br />
# Default: OFF<br />
<br />
#Defaults runaspw<br />
# If set, sudo will prompt for the password of the user defined by the runas_default option<br />
# (defaults to root) instead of the password of the invoking user. Default: OFF<br />
<br />
#Defaults set_home<br />
# If enabled and sudo is invoked with the -s option the HOME environment variable will be set<br />
# to the home directory of the target user (which is root unless the -u option is used). So set_home is only<br />
# effective for configs where either env_reset is disabled or HOME is present in the env_keep list. Default: OFF<br />
<br />
#Defaults set_logname<br />
# Normally, sudo will set the LOGNAME, USER and USERNAME environment variables to the name<br />
# of the target user (usually root unless the -u option is given). However, since some programs ( may be desirable<br />
# to change this behavior. This can be done by negating the set_logname option. Note that if the env_reset option<br />
# has not been disabled, entries in the env_keep list will override<br />
<br />
#Defaults set_utmp<br />
# When enabled, sudo will create an entry in the utmp (or utmpx) file when a pseudo-tty is<br />
# allocated. A pseudo-tty is allocated by sudo when the log_input, log_output or use_pty flags are e the tty, time,<br />
# type and pid fields updated. Default: ON<br />
<br />
#Defaults setenv<br />
# Allow the user to disable the env_reset option from the command line via the -E option.<br />
# Additionally, environment variables set via the command line are not subject to the restrictions impo variables<br />
# in this manner. Default: OFF<br />
<br />
#Defaults shell_noargs<br />
# If set and sudo is invoked with no arguments it acts as if the -s option had been given.<br />
# That is, it runs a shell as root (the shell is determined by the SHELL environment variable if is off by default.<br />
<br />
#Defaults stay_setuid<br />
# Normally, when sudo executes a command the real and effective UIDs are set to the target<br />
# user (root by default). This option changes that behaviour such that the real UID is left as the systems that<br />
# disable some potentially dangerous functionality when a program is run setuid. This option is only effective on<br />
# systems with either the setreuid() or setresuid() function. This flag<br />
<br />
#Defaults targetpw<br />
# If set, sudo will prompt for the password of the user specified by the -u option (defaults to root) instead<br />
# of the password of the invoking user. In addition, the timestamp file name will passwd database as an argument<br />
# to the -u option. Default: OFF<br />
<br />
#Defaults tty_tickets<br />
# If set, users must authenticate on a per-tty basis. With this flag enabled, sudo will<br />
# use a file named for the tty the user is logged in on in the user's time stamp directory.<br />
<br />
#Defaults umask_override<br />
# If set, sudo will set the umask as specified by sudoers without modification. This makes<br />
# it possible to specify a more permissive umask in sudoers than the user's own umask and match user's umask and what<br />
# is specified in sudoers. Default: OFF<br />
<br />
#Defaults use_pty<br />
# If set, sudo will run the command in a pseudo-pty even if no I/O logging is being gone.<br />
# A malicious program run under sudo could conceivably fork a background process that retains to the u that impossible.<br />
# Default: OFF<br />
<br />
#Defaults utmp_runas<br />
# If set, sudo will store the name of the runas user when updating the utmp (or utmpx) file.<br />
# By default, sudo stores the name of the invoking user. Default: OFF<br />
<br />
#Defaults visiblepw<br />
# By default, sudo will refuse to run if the user must enter a password but it is not possible to disable echo on the <br />
# terminal. If the visiblepw flag is set, sudo will prompt for a password even when it would be visible on the screen. <br />
# This makes it possible to run things like "rsh somehost sudo ls" since rsh(1) does not allocate a tty. Default: OFF<br />
<br />
#Defaults closefrom<br />
# Before it executes a command, sudo will close all open file descriptors other than standard<br />
# input, standard output and standard error (ie: file descriptors 0-2).<br />
<br />
#Defaults passwd_tries<br />
# The number of tries a user gets to enter his/her password before sudo logs the failure<br />
# and exits. The default is 3.<br />
<br />
#Defaults loglinelen<br />
# Number of characters per line for the file log. This value is used to decide when to wrap<br />
# lines for nicer log files. This has no effect on the syslog log file, only the file log.<br />
<br />
#Defaults passwd_timeout<br />
# Number of minutes before the sudo password prompt times out, or 0 for no timeout.<br />
# The timeout may include a fractional component if minute granularity is insufficient, for example 2<br />
<br />
#Defaults timestamp_timeout<br />
# Number of minutes that can elapse before sudo will ask for a passwd again. The timeout<br />
# may include a fractional component if minute granularity is insufficient, for example 2.5. timestamp will never expire.<br />
# This can be used to allow users to create or delete their own timestamps via sudo -v and sudo -k respectively.<br />
<br />
#Defaults umask<br />
# Umask to use when running the command. Negate this option or set it to 0777 to preserve<br />
# the user's umask. The actual umask that is used will be the union of the user's umask and the value o running<br />
# a command. Note on systems that use PAM, the default PAM configuration may specify its own umask which will<br />
# override the value set in sudoers.<br />
<br />
#Defaults badpass_message<br />
# Message that is displayed if a user enters an incorrect password. The default is Sorry,<br />
# try again. unless insults are enabled.<br />
<br />
#Defaults editor<br />
# A colon (':') separated list of editors allowed to be used with visudo. visudo will choose<br />
# the editor that matches the user's EDITOR environment variable if possible, or the first editor in<br />
<br />
#Defaults iolog_dir<br />
# The top-level directory to use when constructing the path name for the input/output log<br />
# directory. Only used if the log_input or log_output options are enabled or when the LOG_INPUT or L directory.<br />
# The default is "/var/log/sudo-io". The following percent (%) escape sequences are supported:<br />
# %{seq} - expanded to base-36 sequence number, such as 0100A5, to form a new directory, e.g. 01/00/A5<br />
# %{user} - expanded to the invoking user's login name<br />
# %{group} - expanded to the name of the invoking user's real group ID<br />
# %{runas_user} - expanded to the login name of the user the command will be run as (e.g. root)<br />
# %{runas_group} - expanded to the group name of the user the command will be run as (e.g. wheel)<br />
# %{hostname} - expanded to the local host name without the domain name<br />
# %{command} - expanded to the base name of the command being run In addition, any escape sequences supported by<br />
# strftime() function will be expanded. To include a literal % character, the string %% should be used.<br />
<br />
#Defaults iolog_file<br />
# The path name, relative to iolog_dir, in which to store input/output logs when the log_input or log_output options are<br />
# enabled or when the LOG_INPUT or LOG_OUTPUT tags are present for a See the iolog_dir option above for a list of<br />
# supported percent (%) escape sequences. In addition to the escape sequences, path names that end in six or more Xs will<br />
# have the Xs replaced with a unique combination of digits and letters, similar to the mktemp() function.<br />
<br />
#Defaults mailsub<br />
# Subject of the mail sent to the mailto user. The escape %h will expand to the host name of<br />
# the machine. Default is *** SECURITY information for %h ***.<br />
<br />
#Defaults noexec_file<br />
# This option is no longer supported. The path to the noexec file should now be set in the /etc/sudo.conf file.<br />
<br />
#Defaults passprompt<br />
# The default prompt to use when asking for a password; can be overridden via the -p option or the SUDO_PROMPT<br />
# environment variable. The following percent (%) escape sequences are supported:<br />
# %H - expanded to the local host name including the domain (only if the host name is fqdn or fqdn option is set)<br />
# %h - expanded to the local host name without the domain name<br />
# %p - expanded to the user whose password is being asked for (respects the rootpw, targetpw and runaspw flags)<br />
# %U - expanded to the login name of the user the command will be run as (defaults to root)<br />
# %u - expanded to the invoking user's login name<br />
# %% - two consecutive % characters are collapsed into a single % character<br />
# The default value is Password:.<br />
<br />
#Defaults runas_default<br />
# The default user to run commands as if the -u option is not specified on the command line. This defaults to root.<br />
<br />
#Defaults syslog_badpri<br />
# Syslog priority to use when user authenticates unsuccessfully. Defaults to alert.<br />
# alert, crit, debug, emerg, err, info, notice, and warning.<br />
<br />
#Defaults syslog_goodpri<br />
# Syslog priority to use when user authenticates successfully. Defaults to notice. See syslog_badpri for the priorities.<br />
<br />
#Defaults sudoers_locale<br />
# Locale to use when parsing the sudoers file, logging commands, and sending email.<br />
# Note that changing the locale may affect how sudoers is interpreted. Defaults to "C".<br />
<br />
#Defaults timestampdir<br />
# The directory in which sudo stores its timestamp files. The default is /var/db/sudo.<br />
<br />
#Defaults timestampowner<br />
# The owner of the timestamp directory and the timestamps stored therein. The default is root.<br />
<br />
#Defaults env_file<br />
# The env_file option specifies the fully qualified path to a file containing variables to<br />
# be set in the environment of the program being run. Entries in this file should either be of the f quotes.<br />
# Variables in this file are subject to other sudo environment settings such as env_keep and env_check.<br />
<br />
#Defaults exempt_group<br />
# Users in this group are exempt from password and PATH requirements. The group name specified should not include<br />
# a % prefix. This is not set by default.<br />
<br />
#Defaults group_plugin<br />
# A string containing a sudoers group plugin with optional arguments. This can be used to implement support for the<br />
# nonunix_group syntax described earlier. The string should consist of configuration arguments the plugin requires.<br />
# These arguments (if any) will be passed to the plugin's initialization function. If arguments are present, the<br />
# string must be enclosed in double quote For example, given /etc/sudo-group, a group file in Unix group format,<br />
# the sample group plugin can be used: Defaults group_plugin="sample_group.so /etc/sudo-group"<br />
# For more information see sudo_plugin(5).<br />
<br />
#Defaults lecture<br />
# This option controls when a short lecture will be printed along with the password prompt. The default value is once.<br />
# It has the following possible values:<br />
# always - Always lecture the user.<br />
# never - Never lecture the user.<br />
# once - Only lecture the user the first time they run sudo.<br />
# If no value is specified, a value of once is implied. Negating the option results in a value of never being used.<br />
<br />
#Defaults lecture_file<br />
# Path to a file containing an alternate sudo lecture that will be used in place of the standard lecture if the named<br />
# file exists. By default, sudo uses a built-in lecture.<br />
<br />
#Defaults listpw<br />
# This option controls when a password will be required when a user runs sudo with the -l option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD set to avoid entering a pass.<br />
# always - The user must always enter a password to use the -l option.<br />
# any - At least one of the user's sudoers entries for the current host must have the NOPASSWD set to avoid pass.<br />
# never - The user need never enter a password to use the -l option.<br />
# If no value is specified, a value of any is implied. The default value is any.<br />
<br />
#Defaults logfile<br />
# Path to the sudo log file (not the syslog log file). Setting a path turns on logging to a file;<br />
# negating this option turns it off. By default, sudo logs via syslog.<br />
<br />
#Defaults mailerflags<br />
# Flags to use when invoking mailer. Defaults to -t.<br />
<br />
#Defaults mailerpath<br />
# Path to mail program used to send warning mail. Defaults to the path to sendmail found at configure time.<br />
<br />
#Defaults mailfrom<br />
# Address to use for the "from" address when sending warning and error mail. The address should<br />
# be enclosed in double quotes (") to protect against sudo interpreting the @ sign.<br />
<br />
#Defaults mailto<br />
# Address to send warning and error mail to. The address should be enclosed in double quotes<br />
# (") to protect against sudo interpreting the @ sign. Defaults to root.<br />
<br />
#Defaults secure_path<br />
# Path used for every command run from sudo. If you don't trust the people running sudo to have a sane PATH environment<br />
# variable you may want to use this. Another use is if you want to option are not affected by secure_path.<br />
# This option is not set by default.<br />
<br />
#Defaults syslog<br />
# Syslog facility if syslog is being used for logging (negate to disable syslog logging). Defaults to auth.<br />
# authpriv (if OS supports it), auth, daemon, user, local0, local1, local2, local3, local4, local5, local6, and local7.<br />
<br />
#Defaults verifypw<br />
# This option controls when a password will be required when a user runs sudo with the -v option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD flag to avoid pw.<br />
# always - The user must always enter a password to use the -v option.<br />
# any - At least one of the user's sudoers entries for the current host must have NOPASSWD to avoid pw.<br />
# never - The user need never enter a password to use the -v option<br />
# If no value is specified, a value of all is implied. Negating the option results in a value of never being used.<br />
# The default value is all.<br />
<br />
#Defaults env_check<br />
# Environment variables to be removed from the user's environment if the variable's value contains % or / characters.<br />
# This can be used to guard against printf-style format vulnerabilities value without double-quotes. The list can be<br />
# replaced, added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively. Regardless of<br />
# whether the env_reset option is ena they pass the aforementioned check. The default list of environment variables<br />
# to check is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_delete<br />
# Environment variables to be removed from the user's environment when the env_reset option is not in effect. The<br />
# argument may be a double-quoted, space-separated list or a single value w +=, -=, and ! operators respectively.<br />
# The default list of environment variables to remove is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_keep<br />
# Environment variables to be preserved in the user's environment when the env_reset option is in effect. This<br />
# allows fine-grained control over the environment sudo-spawned processes will r quotes. The list can be replaced,<br />
# added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively.</nowiki>}}</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Sudo&diff=285339Sudo2013-11-30T05:04:07Z<p>Hunterthomson: /* Harden with Sudo Example */</p>
<hr />
<div>[[Category:Security]]<br />
[[cs:Sudo]]<br />
[[es:Sudo]]<br />
[[fr:Sudo]]<br />
[[it:Sudo]]<br />
[[ja:Sudo]]<br />
[[ru:Sudo]]<br />
[[sr:Sudo]]<br />
[[tr:Sudo]]<br />
[[uk:Sudo]]<br />
[[zh-CN:Sudo]]<br />
{{Related articles start}}<br />
{{Related|Users and Groups}}<br />
{{Related|su}}<br />
{{Related articles end}}<br />
<br />
[http://www.gratisoft.us/sudo/ sudo] ("substitute user do") allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments.<br />
<br />
== Rationale ==<br />
<br />
Sudo is an alternative to [[su]] for running commands as root. Unlike [[su]], which launches a root shell that allows all further commands root access, sudo instead grants temporary privilege escalation to a single command. By enabling root privileges only when needed, sudo usage reduces the likelyhood that a typo or a bug in an invoked command will ruin the system.<br />
Sudo can also be used to run commands as other users; additionally, sudo logs all commands and failed access attempts for security auditing.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|sudo}} package, available in the [[Official Repositories|official repositories]]:<br />
<br />
# pacman -S sudo<br />
<br />
To begin using {{ic|sudo}} as a non-privileged user, it must be properly configured. So make sure you read the configuration section.<br />
<br />
== Usage ==<br />
<br />
With sudo, users can prefix commands with {{ic|sudo}} to run them with superuser (or other) privileges.<br />
<br />
For example, to use pacman:<br />
<br />
$ sudo pacman -Syu<br />
<br />
See the [http://www.gratisoft.us/sudo/man/sudo.html sudo manual] for more information.<br />
<br />
== Configuration ==<br />
<br />
=== View current settings ===<br />
<br />
Run {{ic|sudo -ll}} to print out the current sudo configuration.<br />
<br />
=== Using visudo ===<br />
<br />
The configuration file for sudo is {{ic|/etc/sudoers}}. It should '''always''' be edited with the {{ic|visudo}} command. {{ic|visudo}} locks the {{ic|sudoers}} file, saves edits to a temporary file, and checks that file's grammar before copying it to {{ic|/etc/sudoers}}.<br />
<br />
{{Warning|It is imperative that {{ic|sudoers}} be free of syntax errors! Any error makes sudo unusable. '''Always''' edit it with {{ic|visudo}} to prevent errors.}}<br />
<br />
The default editor for visudo is {{ic|vi}}. It will be used if you do not specify another editor, by setting either VISUAL or EDITOR environment variables (used in that order) to the desired editor, e.g. {{ic|nano}}. The command is run as root:<br />
<br />
# EDITOR=nano visudo<br />
<br />
You can permanently change the setting for your user to e.g. {{ic|nano}} by appending:<br />
<br />
export EDITOR=nano<br />
<br />
to your {{ic|~/.bashrc}} file. Note that this won't take effect for already-running shells.<br />
<br />
To change the editor of choice permanently system-wide only for {{ic|visudo}}, add the following line to {{ic|/etc/sudoers}} where {{ic|nano}} is your prefered editor:<br />
<br />
# Reset environment by default<br />
Defaults env_reset<br />
# Set default EDITOR to nano, and do not allow visudo to use EDITOR/VISUAL.<br />
Defaults editor=/usr/bin/nano, !env_editor<br />
<br />
=== Example Entries ===<br />
<br />
To allow a user to gain full root privileges when he/she precedes a command with {{ic|sudo}}, add the following line:<br />
<br />
USER_NAME ALL=(ALL) ALL<br />
<br />
To allow a user to run all commands as any user but only the machine with hostname HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=(ALL) ALL<br />
<br />
To allow members of group {{ic|wheel}} sudo access:<br />
<br />
%wheel ALL=(ALL) ALL<br />
<br />
To disable asking for a password for user USER_NAME:<br />
<br />
Defaults:USER_NAME !authenticate<br />
<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=/usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
{{note| the most customized option should go at the end of the file, as the later lines overrides the previous ones. In particular such a line should be after the {{ic|%wheel}} line if your user is in this group.}}<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME without password:<br />
USER_NAME HOST_NAME= NOPASSWD: /usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
<br />
A detailed sudoers example can be found [http://www.gratisoft.us/sudo/sample.sudoers here]. Otherwise, see the [http://www.gratisoft.us/sudo/man/sudoers.html sudoers manual] for detailed information.<br />
<br />
=== Sudoers default file permissions ===<br />
<br />
The owner and group for the sudoers file must both be 0. The file permissions must be set to 0440. These permissions are set by default, but if you accidentally change them, they should be changed back immediately or sudo will fail.<br />
<br />
# chown -c root:root /etc/sudoers<br />
# chmod -c 0440 /etc/sudoers<br />
<br />
=== Password cache timeout ===<br />
<br />
Users may wish to change the default timeout before the cached password expires. This is accomplished with the timestamp_timeout option in {{ic|/etc/sudoers}} which is in minutes.<br />
Set timeout to 20 minutes.<br />
<br />
Defaults:USER_NAME timestamp_timeout=20<br />
<br />
{{Tip|To ensure sudo always asks for a password, set the timeout to 0. To ensure the password never times out, set to less than 0.}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== File example ===<br />
<br />
This example is especially helpful for those using terminal multiplexers like screen, tmux, or ratpoison, and those using sudo from scripts/cronjobs:<br />
<br />
{{hc|/etc/sudoers|<nowiki><br />
Cmnd_Alias WHEELER = /usr/bin/lsof, /bin/nice, /bin/ps, /usr/bin/top, /usr/local/bin/nano, /usr/bin/ss, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync<br />
Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/kill, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
Cmnd_Alias EDITS = /usr/bin/vim, /usr/bin/nano, /usr/bin/cat, /usr/bin/vi<br />
Cmnd_Alias ARCHLINUX = /usr/bin/gparted, /usr/bin/pacman<br />
<br />
root ALL = (ALL) ALL<br />
USER_NAME ALL = (ALL) ALL, NOPASSWD: WHEELER, NOPASSWD: PROCESSES, NOPASSWD: ARCHLINUX, NOPASSWD: EDITS<br />
<br />
Defaults !requiretty, !tty_tickets, !umask<br />
Defaults visiblepw, path_info, insults, lecture=always<br />
Defaults loglinelen = 0, logfile =/var/log/sudo.log, log_year, log_host, syslog=auth<br />
Defaults mailto=webmaster@foobar.com, mail_badpass, mail_no_user, mail_no_perms<br />
Defaults passwd_tries = 8, passwd_timeout = 1<br />
Defaults env_reset, always_set_home, set_home, set_logname<br />
Defaults !env_editor, editor="/usr/bin/vim:/usr/bin/vi:/usr/bin/nano"<br />
Defaults timestamp_timeout=360<br />
Defaults passprompt="Sudo invoked by [%u] on [%H] - Cmd run as %U - Password for user %p:"<br />
</nowiki>}}<br />
<br />
=== Enabling Tab-completion in Bash ===<br />
<br />
{{ic|Tab}}-completion, by default, will not work when a user is initially added to the sudoers file. For example, normally john only needs to type:<br />
<br />
$ fire<{{ic|Tab}}><br />
<br />
and the shell will complete the command for him as:<br />
<br />
$ firefox<br />
<br />
If, however, john is added to the sudoers file and he types:<br />
<br />
$ sudo fire<{{ic|Tab}}><br />
<br />
the shell will do nothing.<br />
<br />
To enable {{ic|Tab}}-completion with sudo, [[pacman|install]] the {{pkg|bash-completion}} package from the [[Official Repositories|official repositories]]. see [[bash#Tab_completion]] for more information.<br />
<br />
Alternatively, add the following to your {{ic|~/.bashrc}}:<br />
<br />
complete -cf sudo<br />
<br />
=== Run X11 apps using sudo ===<br />
<br />
To allow sudo to start graphical application in X11, you need to add:<br />
<br />
Defaults env_keep += "HOME"<br />
<br />
to visudo.<br />
<br />
=== Disable per-terminal sudo ===<br />
<br />
{{Warning|This will let any process use your sudo session.}}<br />
<br />
If you are annoyed by sudo's defaults that require you to enter your password every time you open a new terminal, disable '''tty_tickets''':<br />
<br />
Defaults !tty_tickets<br />
<br />
=== Environment variables ===<br />
<br />
If you have a lot of environment variables, or you export your proxy settings via {{ic|1=export http_proxy="..."}}, when using sudo these variables do not get passed to the root account unless you run sudo with the {{ic|-E}} option.<br />
<br />
$ sudo -E pacman -Syu<br />
<br />
The recommended way of preserving environment variables is to append them to {{ic|env_keep}}:<br />
{{hc|/etc/sudoers|<nowiki><br />
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"<br />
</nowiki>}}<br />
<br />
=== Passing aliases ===<br />
<br />
If you use a lot of aliases, you might have noticed that they do not carry over to the root account when using sudo. However, there is an easy way to make them work. Simply add the following to your {{ic|~/.bashrc}} or {{ic|/etc/bash.bashrc}}:<br />
<br />
alias sudo='sudo '<br />
<br />
=== Insults ===<br />
<br />
Users can configure sudo to display clever insults when an incorrect password is entered instead of printing the default "wrong password" message. Find the Defaults line in {{ic|/etc/sudoers}} and append "insults" after a comma to existing options. The final result might look like this:<br />
<br />
#Defaults specification<br />
Defaults insults<br />
<br />
To test, type {{ic|sudo -K}} to end the current session and let sudo ask for the password again.<br />
<br />
=== Root password ===<br />
<br />
Users can configure sudo to ask for the root password instead of the user password by adding "rootpw" to the Defaults line in {{ic|/etc/sudoers}}:<br />
<br />
Defaults timestamp_timeout=0,rootpw<br />
<br />
=== Disable root login ===<br />
<br />
{{Warning|Arch Linux is not fine-tuned to run with a disabled root account. Users may encounter problems with this method.}}<br />
<br />
With sudo installed and configured, users may wish to disable the root login. Without root, attackers must first guess a user name configured as a sudoer as well as the user password.<br />
<br />
{{Warning|Ensure a user is properly configured as a sudoer ''before'' disabling the root account!}}<br />
<br />
The account can be locked via {{ic|passwd}}:<br />
<br />
# passwd -l root<br />
<br />
A similar command unlocks root.<br />
<br />
$ sudo passwd -u root<br />
<br />
Alternatively, edit {{ic|/etc/shadow}} and replace the root's encrypted password with "!":<br />
<br />
root:!:12345::::::<br />
<br />
To enable root login again:<br />
<br />
$ sudo passwd root<br />
<br />
==== kdesu ====<br />
<br />
kdesu may be used under KDE to launch GUI applications with root privileges. It is possible that by default kdesu will try to use su even if the root account is disabled. Fortunately one can tell kdesu to use sudo instead of su. Create/edit the file {{ic|~/.kde4/share/config/kdesurc}}:<br />
<br />
[super-user-command]<br />
super-user-command=sudo<br />
<br />
==== PolicyKit ====<br />
<br />
When disabling the root account, it is necessary to change the [[PolicyKit]] configuration for local authorization to reflect that. The default is to ask for the root password, so that must be changed. With polkit-1, this can be achieved by editing {{ic|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf}} so that {{ic|1=AdminIdentities=unix-user:0}} is replaced with something else, depending on the system configuration. It can be a list of users and groups, for example:<br />
<br />
AdminIdentities=unix-group:wheel<br />
<br />
or<br />
<br />
AdminIdentities=unix-user:me;unixuser:mom;unix-group:wheel<br />
<br />
For more information, see {{ic|man pklocalauthority}}.<br />
<br />
==== NetworkManager ====<br />
<br />
Even with the above PolicyKit configuration you still need to configure a policy for NetworkManager. This is documented on the [[NetworkManager#Can.27t_edit_connections_as_normal_user|NetworkManager]] page of this wiki.<br />
<br />
=== Harden with Sudo Example ===<br />
<br />
Lets say you create 3 users: admin, devel, and Joe<br />
admin is used for journalctl, systemctl, mount, kill, and iptables.<br />
devel is used for installing packages, and editing config's<br />
Joe is the user you log in with. Let's let him reboot, shutdown, and use netctl<br />
<br />
Edit /etc/pam.d/su and /etc/pam.d/su-1<br />
Require user be in the wheel group, but don't put anyone in it.<br />
#%PAM-1.0<br />
auth sufficient pam_rootok.so<br />
# Uncomment the following line to implicitly trust users in the "wheel" group.<br />
#auth sufficient pam_wheel.so trust use_uid<br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
auth required pam_unix.so<br />
account required pam_unix.so<br />
session required pam_unix.so<br />
<br />
Limit SSH login to the 'ssh' group, Only put Joe in it<br />
groupadd -r ssh<br />
gpasswd -a Joe ssh<br />
echo 'AllowGroups ssh' >> /etc/ssh/sshd_config<br />
systemctl restart sshd.service<br />
<br />
Lets add users to other goups.<br />
for g in power network ;do ;gpasswd -a Joe $g ;done<br />
for g in network power storage ;do ;gpasswd -a admin $g ;done<br />
<br />
Set permissions on configs so devel can edit them.<br />
chown -R devel:root /etc/{http,openvpn,cups,zsh,vim,screenrc}<br />
<br />
Cmnd_Alias POWER = /usr/bin/shutdown -h now, /usr/bin/halt, /usr/bin/poweroff, /usr/bin/reboot<br />
Cmnd_Alias STORAGE = /usr/bin/mount, /usr/bin/umount<br />
Cmnd_Alias SYSTEMD = /usr/bin/journalctl, /usr/bin/systemctl<br />
Cmnd_Alias KILL = /usr/bin/kill, /usr/bin/killall<br />
Cmnd_Alias PKGMAN = /usr/bin/pacman<br />
Cmnd_Alias NETWORK = /usr/bin/netctl<br />
Cmnd_Alias FIREWALL = /usr/bin/iptables<br />
Cmnd_Alias SHELL = /usr/bin/zsh, /usr/bin/bash<br />
%power ALL = (root) NOPASSWD: POWER<br />
%network ALL = (root) NETWORK<br />
%storage ALL = (root) STORAGE<br />
root ALL = (ALL) ALL<br />
admin ALL = (root) SYSTEMD, KILL, FIREWALL<br />
devel ALL = (root) PKGMAN<br />
Joe ALL = (devel) SHELL, (admin) SHELL <br />
<br />
With this setup, you will almost never need to login as the Root user.<br />
<br />
Joe can connect to his home WiFi<br />
sudo netctl start home<br />
sudo poweroff<br />
<br />
Joe can not use netctl as any other user like admin...<br />
sudo -u admin -- netctl start home<br />
<br />
When Joe needs to use journalctl or kill run away process he can switch to that user<br />
sudo -i -u devel<br />
sudo -i -u admin<br />
<br />
But not Root<br />
sudo -i -u root<br />
<br />
If joe want to start a gnu-screen session as admin he can do it like this<br />
sudo -i -u admin<br />
admin% chown admin:tty `echo $TTY`<br />
admin% screen<br />
<br />
== Troubleshooting ==<br />
<br />
=== SSH TTY Issues ===<br />
<br />
SSH does not allocate a tty by default when running a remote command. Without a tty, sudo cannot disable echo when prompting for a password. You can use ssh's {{ic|-tt}} option to force it to allocate a tty (or {{ic|-t}} twice).<br />
<br />
The {{ic|Defaults}} option {{ic|requiretty}} only allows the user to run sudo if they have a tty.<br />
<br />
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear text. You have to run "ssh -t hostname sudo <cmd>".<br />
#<br />
#Defaults requiretty<br />
<br />
=== Display User Privileges ===<br />
<br />
You can find out what privileges a particular user has with the following command:<br />
<br />
$ sudo -lU yourusename<br />
<br />
Or view your own with:<br />
<br />
{{hc|$ sudo -l|<nowiki><br />
Matching Defaults entries for yourusename on this host:<br />
loglinelen=0, logfile=/var/log/sudo.log, log_year, syslog=auth, mailto=webmaster@gmail.com, mail_badpass, mail_no_user,<br />
mail_no_perms,env_reset, always_set_home, tty_tickets, lecture=always, pwfeedback, rootpw, set_home<br />
<br />
User yourusename may run the following commands on this host:<br />
<br />
(ALL) ALL<br />
(ALL) NOPASSWD: /usr/bin/lsof, /bin/nice, /usr/bin/su, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync, /usr/bin/strace,<br />
(ALL) /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
(ALL) /usr/bin/gparted, /usr/bin/pacman<br />
(ALL) /usr/local/bin/synergyc, /usr/local/bin/synergys<br />
(ALL) /usr/bin/vim, /usr/bin/nano, /usr/bin/cat<br />
(root) NOPASSWD: /usr/local/bin/synergyc</nowiki>}}<br />
<br />
=== Permissive Umask ===<br />
<br />
Sudo will union the user's [[umask]] value with its own umask (which defaults to 0022). This prevents sudo from creating files with more open permissions than the user's umask allows. While this is a sane default if no custom umask is in use, this can lead to situations where a utility run by sudo may create files with different permissions than if run by root directly. If errors arise from this, sudo provides a means to fix the umask, even if the desired umask is more permissive than the umask that the user has specified. Adding this (using {{ic|visudo}}) will override sudo's default behavior:<br />
<br />
Defaults umask = 0022<br />
Defaults umask_override<br />
<br />
This sets sudo's umask to root's default umask (0022) and overrides the default behavior, always using the indicated umask regardless of what umask the user as set.<br />
<br />
<br />
=== Defaults Skeleton ===<br />
<br />
The authors site has a [http://www.gratisoft.us/sudo/sudoers.man.html#sudoers_options list of all the options] that can be used with the {{ic|Defaults}} command in the {{ic|/etc/sudoers}} file.<br />
<br />
The full list of options ''(parsed from the version 1.8.7 source code)'' is below in a format optimized for copying and pasting into your sudoers files for quick editing.<br />
<br />
{{bc|<nowiki>#Defaults always_set_home<br />
# If enabled, sudo will set the HOME environment variable to the home directory of the target user<br />
# (which is root unless the -u option is used). This effectively means that the -H option<br />
# always_set_home is only effective for configurations where either env_reset is disabled or HOME is present<br />
# in the env_keep list. Default: OFF<br />
<br />
#Defaults authenticate<br />
# If set, users must authenticate themselves via a password (or other means of authentication)<br />
# before they may run commands. This default may be overridden via the PASSWD and NOPASSWD<br />
<br />
#Defaults closefrom_override<br />
# If set, the user may use sudo's -C option which overrides the default starting<br />
# point at which sudo begins closing open file descriptors. Default: OFF<br />
<br />
#Defaults compress_io<br />
# If set, and sudo is configured to log a command's input or output, the I/O logs will be<br />
# compressed using zlib. This flag is on by default when sudo is compiled with zlib support.<br />
<br />
#Defaults env_editor<br />
# If set, visudo will use the value of the EDITOR or VISUAL environment variables before falling back on the default<br />
# editor list. Note that this may create a security hole as it allows th separated list of editors in the editor<br />
# variable. visudo will then only use the EDITOR or VISUAL if they match a value specified in editor. On by default.<br />
<br />
#Defaults env_reset<br />
# If set, sudo will run the command in a minimal environment containing the TERM, PATH, HOME, MAIL, SHELL, LOGNAME,<br />
# USER, USERNAME and SUDO_* variables. Any variables in the caller's env in the file specified by the env_file<br />
# option (if any). The default contents of the env_keep and env_check lists are displayed when sudo is run by<br />
# root with the -V option.<br />
<br />
#Defaults fast_glob<br />
# Normally, sudo uses the glob(3) function to do shell-style globbing when matching path names.<br />
# However, since it accesses the file system, glob(3) can take a long time to complete for som (automounted).<br />
# The fast_glob option causes sudo to use the fnmatch(3) function, which does not access the file system to do<br />
# its matching. The disadvantage of fast_glob is that it is unable to ma names that include globbing characters<br />
# are used with the negation operator, '!', as such rules can be trivially bypassed. As such, this option should<br />
# not be used when sudoers contains rules that<br />
<br />
#Defaults fqdn<br />
# Set this flag if you want to put fully qualified host names in the sudoers file. I.e., instead of myhost you<br />
# would use myhost.mydomain.edu. You may still use the short form if you wish (and sudo unusable if DNS stops<br />
# working (for example if the machine is not plugged into the network). Also note that you must use the<br />
# host's official name as DNS knows it. That is, you may not use a all aliases from DNS. If your machine's<br />
# host name (as returned by the hostname command) is already fully qualified you shouldn't need to set fqdn.<br />
# Default: OFF<br />
<br />
#Defaults ignore_dot<br />
# If set, sudo will ignore '.' or '' (current dir) in the PATH environment variable; the PATH<br />
# itself is not modified. Default: OFF<br />
<br />
#Defaults ignore_local_sudoers<br />
# If set via LDAP, parsing of /etc/sudoers will be skipped. This is intended for Enterprises that wish to prevent<br />
# the usage of local sudoers files so that only LDAP is used. /etc/sudoers does not even need to exist.<br />
# Since this option tells sudo how to behave when no specific LDAP entries have been matched, this sudo<br />
# Option is only meaningful for the cn=default<br />
<br />
#Defaults insults<br />
# If set, sudo will insult users when they enter an incorrect password. Default: OFF<br />
<br />
#Defaults log_host<br />
# If set, the host name will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults log_input<br />
# If set, sudo will run the command in a pseudo tty and log all user input. If the standard<br />
# input is not connected to the user's tty, due to I/O redirection or because the command is part Input is logged<br />
# to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that<br />
# is included in the normal sudo log line, prefixed with TSID=. Note that user input may contain sensitive<br />
# information such as passwords (even if they are not echoed to the screen), which will be stored in the log file<br />
# unencrypted.<br />
<br />
#Defaults log_output<br />
# If set, sudo will run the command in a pseudo tty and log all output that is sent to the<br />
# screen, similar to the script(1) command. If the standard output or standard error is not connec is also captured and<br />
# stored in separate log files. Output is logged to the directory specified by the iolog_dir option (/var/log/sudo-io<br />
# by default) using a unique session ID that is included in the normal sudo log line, prefixed with TSID=. The Output<br />
# logs may be viewed with the sudoreplay(8) utility, which can also be used to list or search the available logs.<br />
<br />
#Defaults log_year<br />
# If set, the four-digit year will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults long_otp_prompt<br />
# When validating with a One Time Password (OTP) scheme such as S/Key or OPIE, a two-line<br />
# prompt is used to make it easier to cut and paste the challenge to a local window<br />
<br />
#Defaults mail_always<br />
# Send mail to the mailto user every time a users runs sudo. Default: OFF<br />
<br />
#Defaults mail_badpass<br />
# Send mail to the mailto user if the user running sudo does not enter the correct password.<br />
# Default: OFF<br />
<br />
#Defaults mail_no_host<br />
# If set, mail will be sent to the mailto user if the invoking user exists in the sudoers<br />
# file, but is not allowed to run commands on the current host. Default: OFF<br />
<br />
#Defaults mail_no_perms<br />
# If set, mail will be sent to the mailto user if the invoking user is allowed to use sudo<br />
# but the command they are trying is not listed in their sudoers file entry or is explicitly denied<br />
<br />
#Defaults mail_no_user<br />
# If set, mail will be sent to the mailto user if the invoking user is not in the sudoers file.<br />
# Default: ON<br />
<br />
#Defaults noexec<br />
# If set, all commands run via sudo will behave as if the NOEXEC tag has been set, unless overridden<br />
# by a EXEC tag. See the description of NOEXEC and EXEC below as well as the "PREVENTING SHE<br />
<br />
#Defaults path_info<br />
# Normally, sudo will tell the user when a command could not be found in their PATH environment<br />
# variable. Some sites may wish to disable this as it could be used to gather information on t the executable is<br />
# simply not in the user's PATH, sudo will tell the user that they are not allowed to run it, which can be confusing.<br />
# Default: ON<br />
<br />
#Defaults passprompt_override<br />
# The password prompt specified by passprompt will normally only be used if the password prompt provided by<br />
# systems such as PAM matches the string "Password:"<br />
<br />
#Defaults preserve_groups<br />
# By default, sudo will initialize the group vector to the list of groups the target<br />
# user is in. When preserve_groups is set, the user's existing group vector is left unaltered.<br />
<br />
#Defaults pwfeedback<br />
# By default, sudo reads the password like most other Unix programs, by turning off echo<br />
# until the user hits the return (or enter) key. Some users become confused by this as it appears to the user<br />
# presses a key. Note that this does have a security impact as an onlooker may be able to determine the length of<br />
# the password being entered. Default: OFF<br />
<br />
#Defaults requiretty<br />
# If set, sudo will only run when the user is logged in to a real tty. When this flag is set,<br />
# sudo can only be run from a login session and not via other means such as cron(8) or cgi-bin<br />
<br />
#Defaults root_sudo<br />
# If set, root is allowed to run sudo too. Disabling this prevents users from "chaining" sudo<br />
# commands to get a root shell by doing something like "sudo sudo /bin/sh". Note, however, that real additional<br />
# security; it exists purely for historical reasons. Default: ON<br />
<br />
#Defaults rootpw<br />
# If set, sudo will prompt for the root password instead of the password of the invoking user.<br />
# Default: OFF<br />
<br />
#Defaults runaspw<br />
# If set, sudo will prompt for the password of the user defined by the runas_default option<br />
# (defaults to root) instead of the password of the invoking user. Default: OFF<br />
<br />
#Defaults set_home<br />
# If enabled and sudo is invoked with the -s option the HOME environment variable will be set<br />
# to the home directory of the target user (which is root unless the -u option is used). So set_home is only<br />
# effective for configs where either env_reset is disabled or HOME is present in the env_keep list. Default: OFF<br />
<br />
#Defaults set_logname<br />
# Normally, sudo will set the LOGNAME, USER and USERNAME environment variables to the name<br />
# of the target user (usually root unless the -u option is given). However, since some programs ( may be desirable<br />
# to change this behavior. This can be done by negating the set_logname option. Note that if the env_reset option<br />
# has not been disabled, entries in the env_keep list will override<br />
<br />
#Defaults set_utmp<br />
# When enabled, sudo will create an entry in the utmp (or utmpx) file when a pseudo-tty is<br />
# allocated. A pseudo-tty is allocated by sudo when the log_input, log_output or use_pty flags are e the tty, time,<br />
# type and pid fields updated. Default: ON<br />
<br />
#Defaults setenv<br />
# Allow the user to disable the env_reset option from the command line via the -E option.<br />
# Additionally, environment variables set via the command line are not subject to the restrictions impo variables<br />
# in this manner. Default: OFF<br />
<br />
#Defaults shell_noargs<br />
# If set and sudo is invoked with no arguments it acts as if the -s option had been given.<br />
# That is, it runs a shell as root (the shell is determined by the SHELL environment variable if is off by default.<br />
<br />
#Defaults stay_setuid<br />
# Normally, when sudo executes a command the real and effective UIDs are set to the target<br />
# user (root by default). This option changes that behaviour such that the real UID is left as the systems that<br />
# disable some potentially dangerous functionality when a program is run setuid. This option is only effective on<br />
# systems with either the setreuid() or setresuid() function. This flag<br />
<br />
#Defaults targetpw<br />
# If set, sudo will prompt for the password of the user specified by the -u option (defaults to root) instead<br />
# of the password of the invoking user. In addition, the timestamp file name will passwd database as an argument<br />
# to the -u option. Default: OFF<br />
<br />
#Defaults tty_tickets<br />
# If set, users must authenticate on a per-tty basis. With this flag enabled, sudo will<br />
# use a file named for the tty the user is logged in on in the user's time stamp directory.<br />
<br />
#Defaults umask_override<br />
# If set, sudo will set the umask as specified by sudoers without modification. This makes<br />
# it possible to specify a more permissive umask in sudoers than the user's own umask and match user's umask and what<br />
# is specified in sudoers. Default: OFF<br />
<br />
#Defaults use_pty<br />
# If set, sudo will run the command in a pseudo-pty even if no I/O logging is being gone.<br />
# A malicious program run under sudo could conceivably fork a background process that retains to the u that impossible.<br />
# Default: OFF<br />
<br />
#Defaults utmp_runas<br />
# If set, sudo will store the name of the runas user when updating the utmp (or utmpx) file.<br />
# By default, sudo stores the name of the invoking user. Default: OFF<br />
<br />
#Defaults visiblepw<br />
# By default, sudo will refuse to run if the user must enter a password but it is not possible to disable echo on the <br />
# terminal. If the visiblepw flag is set, sudo will prompt for a password even when it would be visible on the screen. <br />
# This makes it possible to run things like "rsh somehost sudo ls" since rsh(1) does not allocate a tty. Default: OFF<br />
<br />
#Defaults closefrom<br />
# Before it executes a command, sudo will close all open file descriptors other than standard<br />
# input, standard output and standard error (ie: file descriptors 0-2).<br />
<br />
#Defaults passwd_tries<br />
# The number of tries a user gets to enter his/her password before sudo logs the failure<br />
# and exits. The default is 3.<br />
<br />
#Defaults loglinelen<br />
# Number of characters per line for the file log. This value is used to decide when to wrap<br />
# lines for nicer log files. This has no effect on the syslog log file, only the file log.<br />
<br />
#Defaults passwd_timeout<br />
# Number of minutes before the sudo password prompt times out, or 0 for no timeout.<br />
# The timeout may include a fractional component if minute granularity is insufficient, for example 2<br />
<br />
#Defaults timestamp_timeout<br />
# Number of minutes that can elapse before sudo will ask for a passwd again. The timeout<br />
# may include a fractional component if minute granularity is insufficient, for example 2.5. timestamp will never expire.<br />
# This can be used to allow users to create or delete their own timestamps via sudo -v and sudo -k respectively.<br />
<br />
#Defaults umask<br />
# Umask to use when running the command. Negate this option or set it to 0777 to preserve<br />
# the user's umask. The actual umask that is used will be the union of the user's umask and the value o running<br />
# a command. Note on systems that use PAM, the default PAM configuration may specify its own umask which will<br />
# override the value set in sudoers.<br />
<br />
#Defaults badpass_message<br />
# Message that is displayed if a user enters an incorrect password. The default is Sorry,<br />
# try again. unless insults are enabled.<br />
<br />
#Defaults editor<br />
# A colon (':') separated list of editors allowed to be used with visudo. visudo will choose<br />
# the editor that matches the user's EDITOR environment variable if possible, or the first editor in<br />
<br />
#Defaults iolog_dir<br />
# The top-level directory to use when constructing the path name for the input/output log<br />
# directory. Only used if the log_input or log_output options are enabled or when the LOG_INPUT or L directory.<br />
# The default is "/var/log/sudo-io". The following percent (%) escape sequences are supported:<br />
# %{seq} - expanded to base-36 sequence number, such as 0100A5, to form a new directory, e.g. 01/00/A5<br />
# %{user} - expanded to the invoking user's login name<br />
# %{group} - expanded to the name of the invoking user's real group ID<br />
# %{runas_user} - expanded to the login name of the user the command will be run as (e.g. root)<br />
# %{runas_group} - expanded to the group name of the user the command will be run as (e.g. wheel)<br />
# %{hostname} - expanded to the local host name without the domain name<br />
# %{command} - expanded to the base name of the command being run In addition, any escape sequences supported by<br />
# strftime() function will be expanded. To include a literal % character, the string %% should be used.<br />
<br />
#Defaults iolog_file<br />
# The path name, relative to iolog_dir, in which to store input/output logs when the log_input or log_output options are<br />
# enabled or when the LOG_INPUT or LOG_OUTPUT tags are present for a See the iolog_dir option above for a list of<br />
# supported percent (%) escape sequences. In addition to the escape sequences, path names that end in six or more Xs will<br />
# have the Xs replaced with a unique combination of digits and letters, similar to the mktemp() function.<br />
<br />
#Defaults mailsub<br />
# Subject of the mail sent to the mailto user. The escape %h will expand to the host name of<br />
# the machine. Default is *** SECURITY information for %h ***.<br />
<br />
#Defaults noexec_file<br />
# This option is no longer supported. The path to the noexec file should now be set in the /etc/sudo.conf file.<br />
<br />
#Defaults passprompt<br />
# The default prompt to use when asking for a password; can be overridden via the -p option or the SUDO_PROMPT<br />
# environment variable. The following percent (%) escape sequences are supported:<br />
# %H - expanded to the local host name including the domain (only if the host name is fqdn or fqdn option is set)<br />
# %h - expanded to the local host name without the domain name<br />
# %p - expanded to the user whose password is being asked for (respects the rootpw, targetpw and runaspw flags)<br />
# %U - expanded to the login name of the user the command will be run as (defaults to root)<br />
# %u - expanded to the invoking user's login name<br />
# %% - two consecutive % characters are collapsed into a single % character<br />
# The default value is Password:.<br />
<br />
#Defaults runas_default<br />
# The default user to run commands as if the -u option is not specified on the command line. This defaults to root.<br />
<br />
#Defaults syslog_badpri<br />
# Syslog priority to use when user authenticates unsuccessfully. Defaults to alert.<br />
# alert, crit, debug, emerg, err, info, notice, and warning.<br />
<br />
#Defaults syslog_goodpri<br />
# Syslog priority to use when user authenticates successfully. Defaults to notice. See syslog_badpri for the priorities.<br />
<br />
#Defaults sudoers_locale<br />
# Locale to use when parsing the sudoers file, logging commands, and sending email.<br />
# Note that changing the locale may affect how sudoers is interpreted. Defaults to "C".<br />
<br />
#Defaults timestampdir<br />
# The directory in which sudo stores its timestamp files. The default is /var/db/sudo.<br />
<br />
#Defaults timestampowner<br />
# The owner of the timestamp directory and the timestamps stored therein. The default is root.<br />
<br />
#Defaults env_file<br />
# The env_file option specifies the fully qualified path to a file containing variables to<br />
# be set in the environment of the program being run. Entries in this file should either be of the f quotes.<br />
# Variables in this file are subject to other sudo environment settings such as env_keep and env_check.<br />
<br />
#Defaults exempt_group<br />
# Users in this group are exempt from password and PATH requirements. The group name specified should not include<br />
# a % prefix. This is not set by default.<br />
<br />
#Defaults group_plugin<br />
# A string containing a sudoers group plugin with optional arguments. This can be used to implement support for the<br />
# nonunix_group syntax described earlier. The string should consist of configuration arguments the plugin requires.<br />
# These arguments (if any) will be passed to the plugin's initialization function. If arguments are present, the<br />
# string must be enclosed in double quote For example, given /etc/sudo-group, a group file in Unix group format,<br />
# the sample group plugin can be used: Defaults group_plugin="sample_group.so /etc/sudo-group"<br />
# For more information see sudo_plugin(5).<br />
<br />
#Defaults lecture<br />
# This option controls when a short lecture will be printed along with the password prompt. The default value is once.<br />
# It has the following possible values:<br />
# always - Always lecture the user.<br />
# never - Never lecture the user.<br />
# once - Only lecture the user the first time they run sudo.<br />
# If no value is specified, a value of once is implied. Negating the option results in a value of never being used.<br />
<br />
#Defaults lecture_file<br />
# Path to a file containing an alternate sudo lecture that will be used in place of the standard lecture if the named<br />
# file exists. By default, sudo uses a built-in lecture.<br />
<br />
#Defaults listpw<br />
# This option controls when a password will be required when a user runs sudo with the -l option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD set to avoid entering a pass.<br />
# always - The user must always enter a password to use the -l option.<br />
# any - At least one of the user's sudoers entries for the current host must have the NOPASSWD set to avoid pass.<br />
# never - The user need never enter a password to use the -l option.<br />
# If no value is specified, a value of any is implied. The default value is any.<br />
<br />
#Defaults logfile<br />
# Path to the sudo log file (not the syslog log file). Setting a path turns on logging to a file;<br />
# negating this option turns it off. By default, sudo logs via syslog.<br />
<br />
#Defaults mailerflags<br />
# Flags to use when invoking mailer. Defaults to -t.<br />
<br />
#Defaults mailerpath<br />
# Path to mail program used to send warning mail. Defaults to the path to sendmail found at configure time.<br />
<br />
#Defaults mailfrom<br />
# Address to use for the "from" address when sending warning and error mail. The address should<br />
# be enclosed in double quotes (") to protect against sudo interpreting the @ sign.<br />
<br />
#Defaults mailto<br />
# Address to send warning and error mail to. The address should be enclosed in double quotes<br />
# (") to protect against sudo interpreting the @ sign. Defaults to root.<br />
<br />
#Defaults secure_path<br />
# Path used for every command run from sudo. If you don't trust the people running sudo to have a sane PATH environment<br />
# variable you may want to use this. Another use is if you want to option are not affected by secure_path.<br />
# This option is not set by default.<br />
<br />
#Defaults syslog<br />
# Syslog facility if syslog is being used for logging (negate to disable syslog logging). Defaults to auth.<br />
# authpriv (if OS supports it), auth, daemon, user, local0, local1, local2, local3, local4, local5, local6, and local7.<br />
<br />
#Defaults verifypw<br />
# This option controls when a password will be required when a user runs sudo with the -v option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD flag to avoid pw.<br />
# always - The user must always enter a password to use the -v option.<br />
# any - At least one of the user's sudoers entries for the current host must have NOPASSWD to avoid pw.<br />
# never - The user need never enter a password to use the -v option<br />
# If no value is specified, a value of all is implied. Negating the option results in a value of never being used.<br />
# The default value is all.<br />
<br />
#Defaults env_check<br />
# Environment variables to be removed from the user's environment if the variable's value contains % or / characters.<br />
# This can be used to guard against printf-style format vulnerabilities value without double-quotes. The list can be<br />
# replaced, added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively. Regardless of<br />
# whether the env_reset option is ena they pass the aforementioned check. The default list of environment variables<br />
# to check is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_delete<br />
# Environment variables to be removed from the user's environment when the env_reset option is not in effect. The<br />
# argument may be a double-quoted, space-separated list or a single value w +=, -=, and ! operators respectively.<br />
# The default list of environment variables to remove is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_keep<br />
# Environment variables to be preserved in the user's environment when the env_reset option is in effect. This<br />
# allows fine-grained control over the environment sudo-spawned processes will r quotes. The list can be replaced,<br />
# added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively.</nowiki>}}</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Systemd&diff=285109Systemd2013-11-28T18:26:03Z<p>Hunterthomson: /* Filtering output */ journalctl -f with line wrapping</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Daemons and system services]]<br />
[[Category:Boot process]]<br />
[[ar:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[it:Systemd]]<br />
[[ja:Systemd]]<br />
[[pt:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN:Systemd]]<br />
[[zh-TW:Systemd]]<br />
{{Related articles start}}<br />
{{Related|systemd/User}}<br />
{{Related|systemd/Services}}<br />
{{Related|systemd/cron functionality}}<br />
{{Related|systemd FAQ}}<br />
{{Related|init Rosetta}}<br />
{{Related|Daemons List}}<br />
{{Related|udev}}<br />
{{Related|Improve Boot Performance}}<br />
{{Related articles end}}<br />
<br />
From the [http://freedesktop.org/wiki/Software/systemd project web page]:<br />
<br />
:'''''systemd''' is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and [[D-Bus]] activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux [[cgroups|control groups]], supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic.''<br />
<br />
{{Note|1=For a detailed explanation as to why Arch has moved to ''systemd'', see [https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 this forum post].}}<br />
<br />
== Migration from SysVinit/initscripts ==<br />
<br />
{{Note|<br />
* {{Pkg|systemd}} and {{Pkg|systemd-sysvcompat}} are both installed by default on installation media newer than [https://www.archlinux.org/news/systemd-is-now-the-default-on-new-installations/ 2012-10-13]. This section is aimed at Arch Linux installations that still rely on ''sysvinit'' and ''initscripts''.<br />
* If you are running Arch Linux inside a VPS, please see [[Virtual Private Server#Moving your VPS from initscripts to systemd]].<br />
}}<br />
<br />
=== Considerations before switching ===<br />
<br />
* Do [http://freedesktop.org/wiki/Software/systemd/ some reading] about ''systemd''.<br />
* Note the fact that systemd has a ''journal'' system that replaces ''syslog'', although the two can co-exist. See [[#Journal]].<br />
* While ''systemd'' can replace some of the functionality of ''cron'', ''acpid'', or ''xinetd'', there is no need to switch away from using the traditional daemons unless you want to.<br />
* Interactive ''initscripts'' are not working with ''systemd''. In particular, ''netcfg-menu'' cannot be used at system start-up ({{Bug|31377}}).<br />
<br />
=== Installation procedure ===<br />
<br />
# [[pacman|Install]] {{Pkg|systemd}} from the [[official repositories]].<br />
# Append the following to your [[kernel parameters]]: {{ic|1=init=/usr/lib/systemd/systemd}}.<br />
# Once completed you may enable any desired services via the use of {{ic|systemctl enable ''service_name''}} (this roughly equates to what you included in the {{ic|DAEMONS}} array. New names can be found in [[Daemons List]]).<br />
# Reboot your system and verify that ''systemd'' is currently active by issuing the following command: {{ic|cat /proc/1/comm}}. This should return the string {{ic|systemd}}.<br />
# Make sure your hostname is set correctly under ''systemd'': {{ic|hostnamectl set-hostname ''myhostname''}} or {{ic|/etc/hostname}}.<br />
# Proceed to remove ''initscripts'' and ''sysvinit'' from your system and install {{Pkg|systemd-sysvcompat}}.<br />
# Optionally, remove the {{ic|1=init=/usr/lib/systemd/systemd}} parameter. It is no longer needed since {{Pkg|systemd-sysvcompat}} provides a symlink to ''systemd'''s init where ''sysvinit'' used to be.<br />
<br />
=== Supplementary information ===<br />
<br />
* If you have {{ic|quiet}} in your kernel parameters, you might want to remove it for your first couple of systemd boots, to assist with identifying any issues during boot.<br />
<br />
* It is not necessary to add your user to [[Users and Groups|groups]] ({{ic|sys}}, {{ic|disk}}, {{ic|lp}}, {{ic|network}}, {{ic|video}}, {{ic|audio}}, {{ic|optical}}, {{ic|storage}}, {{ic|scanner}}, {{ic|power}}, etc.) for most use cases with systemd. The groups can even cause some functionality to break. For example, the {{ic|audio}} group will break fast user switching and allows applications to block software mixing. Every PAM login provides a logind session, which for a local session will give you permissions via [[Wikipedia:Access control list|POSIX ACLs]] on audio/video devices, and allow certain operations like mounting removable storage via [[udisks]].<br />
<br />
* See the [[Network Configuration]] article for how to set up networking targets.<br />
<br />
== Basic systemctl usage ==<br />
<br />
The main command used to introspect and control ''systemd'' is '''systemctl'''. Some of its uses are examining the system state and managing the system and services. See {{ic|man 1 systemctl}} for more details.<br />
<br />
{{Tip|You can use all of the following ''systemctl'' commands with the {{ic|-H ''user''@''host''}} switch to control a ''systemd'' instance on a remote machine. This will use [[SSH]] to connect to the remote ''systemd'' instance.}}<br />
<br />
{{Note|''systemadm'' is the official graphical frontend for ''systemctl''. It is provided by the {{AUR|systemd-ui-git}} package from the [[AUR]].}}<br />
<br />
=== Analyzing the system state ===<br />
<br />
List running units:<br />
<br />
$ systemctl<br />
<br />
or:<br />
<br />
$ systemctl list-units<br />
<br />
List failed units:<br />
<br />
$ systemctl --failed<br />
<br />
The available unit files can be seen in {{ic|/usr/lib/systemd/system/}} and {{ic|/etc/systemd/system/}} (the latter takes precedence). You can see a list of the installed unit files with:<br />
<br />
$ systemctl list-unit-files<br />
<br />
=== Using units ===<br />
<br />
Units can be, for example, services (''.service''), mount points (''.mount''), devices (''.device'') or sockets (''.socket'').<br />
<br />
When using ''systemctl'', you generally have to specify the complete name of the unit file, including its suffix, for example ''sshd.socket''. There are however a few short forms when specifying the unit in the following ''systemctl'' commands:<br />
<br />
* If you do not specify the suffix, systemctl will assume ''.service''. For example, {{ic|netcfg}} and {{ic|netcfg.service}} are equivalent.<br />
* Mount points will automatically be translated into the appropriate ''.mount'' unit. For example, specifying {{ic|/home}} is equivalent to {{ic|home.mount}}.<br />
* Similar to mount points, devices are automatically translated into the appropriate ''.device'' unit, therefore specifying {{ic|/dev/sda2}} is equivalent to {{ic|dev-sda2.device}}.<br />
<br />
See {{ic|man systemd.unit}} for details.<br />
<br />
Activate a unit immediately:<br />
<br />
# systemctl start ''unit''<br />
<br />
Deactivate a unit immediately:<br />
<br />
# systemctl stop ''unit''<br />
<br />
Restart a unit:<br />
<br />
# systemctl restart ''unit''<br />
<br />
Ask a unit to reload its configuration:<br />
<br />
# systemctl reload ''unit''<br />
<br />
Show the status of a unit, including whether it is running or not:<br />
<br />
$ systemctl status ''unit''<br />
<br />
Check whether a unit is already enabled or not:<br />
<br />
$ systemctl is-enabled ''unit''<br />
<br />
Enable a unit to be started on bootup:<br />
<br />
# systemctl enable ''unit''<br />
<br />
{{Note|Services without an {{ic|[Install]}} section are usually called automatically by other services. If you need to install them manually, use the following command, replacing ''foo'' with the name of the service.<br />
# ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/<br />
}}<br />
<br />
Disable a unit to not start during bootup:<br />
<br />
# systemctl disable ''unit''<br />
<br />
Show the manual page associated with a unit (this has to be supported by the unit file):<br />
<br />
$ systemctl help ''unit''<br />
<br />
Reload ''systemd'', scanning for new or changed units:<br />
<br />
# systemctl daemon-reload<br />
<br />
=== Power management ===<br />
<br />
[[polkit]] is necessary for power management. If you are in a local ''systemd-logind'' user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is logged into a tty), ''systemd'' will automatically ask you for the root password.<br />
<br />
Shut down and reboot the system:<br />
<br />
$ systemctl reboot<br />
<br />
Shut down and power-off the system:<br />
<br />
$ systemctl poweroff<br />
<br />
Suspend the system:<br />
<br />
$ systemctl suspend<br />
<br />
Put the system into hibernation:<br />
<br />
$ systemctl hibernate<br />
<br />
Put the system into hybrid-sleep state (or suspend-to-both):<br />
<br />
$ systemctl hybrid-sleep<br />
<br />
== Native configuration ==<br />
<br />
{{Note|You may need to create these files. All files should have {{ic|644}} permissions and {{ic|root:root}} ownership.}}<br />
<br />
=== Virtual console ===<br />
{{Deletion|Not strictly related, trying to remove the [[#Native configuration]] section entirely.|section=Duplication of content in Native configuration section}}<br />
<br />
The virtual console (keyboard mapping, console font and console map) is configured in {{ic|/etc/vconsole.conf}} or by using the ''localectl'' tool.<br />
<br />
For more information, see [[Fonts#Console fonts|console fonts]] and [[KEYMAP|keymaps]].<br />
<br />
=== Filesystem mounts ===<br />
{{Merge|File Systems|This section was added here before systemd became the default init system. Delete it after merging.|section=Duplication of content in Native configuration section}}<br />
<br />
The default setup will automatically fsck and mount filesystems before starting services that need them to be mounted. For example, systemd automatically makes sure that remote filesystem mounts like [[NFS]] or [[Samba]] are only started after the network has been set up. Therefore, local and remote filesystem mounts specified in {{ic|/etc/fstab}} should work out of the box.<br />
<br />
See {{ic|man 5 systemd.mount}} for details.<br />
<br />
==== Automount ====<br />
{{Merge|fstab|This section was added here before systemd became the default init system. Delete it after merging.|section=Duplication of content in Native configuration section}}<br />
<br />
If you have a large {{ic|/home}} partition, it might be better to allow services that do not depend on {{ic|/home}} to start while {{ic|/home}} is checked by ''fsck''. This can be achieved by adding the following options to the {{ic|/etc/fstab}} entry of your {{ic|/home}} partition:<br />
<br />
noauto,x-systemd.automount<br />
<br />
This will fsck and mount {{ic|/home}} when it is first accessed, and the kernel will buffer all file access to {{ic|/home}} until it is ready.<br />
<br />
{{Note|This will make your {{ic|/home}} filesystem type {{ic|autofs}}, which is ignored by [[mlocate]] by default. The speedup of automounting {{ic|/home}} may not be more than a second or two, depending on your system, so this trick may not be worth it.}}<br />
<br />
The same applies to remote filesystem mounts. If you want them to be mounted only upon access, you will need to use the {{ic|noauto,x-systemd.automount}} parameters. In addition, you can use the {{ic|1=x-systemd.device-timeout=#}} option to specify a timeout in case the network resource is not available.<br />
<br />
If you have encrypted filesystems with keyfiles, you can also add the {{ic|noauto}} parameter to the corresponding entries in {{ic|/etc/crypttab}}. ''systemd'' will then not open the encrypted device on boot, but instead wait until it is actually accessed and then automatically open it with the specified keyfile before mounting it. This might save a few seconds on boot if you are using an encrypted RAID device for example, because systemd does not have to wait for the device to become available. For example:<br />
<br />
{{hc|/etc/crypttab|<br />
data /dev/md0 /root/key noauto}}<br />
<br />
== Writing custom .service files ==<br />
<br />
The syntax of systemd's [[#Using units|unit files]] is inspired by XDG Desktop Entry Specification ''.desktop'' files, which are in turn inspired by Microsoft Windows ''.ini'' files.<br />
<br />
See [[systemd/Services]] for more examples.<br />
<br />
=== Handling dependencies ===<br />
<br />
With ''systemd'', dependencies can be resolved by designing the unit files correctly. The most typical case is that the unit ''A'' requires the unit ''B'' to be running before ''A'' is started. In that case add {{ic|1=Requires=''B''}} and {{ic|1=After=''B''}} to the {{ic|[Unit]}} section of ''A''. If the dependency is optional, add {{ic|1=Wants=''B''}} and {{ic|1=After=''B''}} instead. Note that {{ic|1=Wants=}} and {{ic|1=Requires=}} do not imply {{ic|1=After=}}, meaning that if {{ic|1=After=}} is not specified, the two units will be started in parallel.<br />
<br />
Dependencies are typically placed on services and not on targets. For example, ''network.target'' is pulled in by whatever service configures your network interfaces, therefore ordering your custom unit after it is sufficient since ''network.target'' is started anyway.<br />
<br />
=== Type ===<br />
<br />
There are several different start-up types to consider when writing a custom service file. This is set with the {{ic|1=Type=}} parameter in the {{ic|[Service]}} section. See {{ic|man systemd.service}} for a more detailed explanation.<br />
<br />
* {{ic|1=Type=simple}} (default): ''systemd'' considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.<br />
* {{ic|1=Type=forking}}: ''systemd'' considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify {{ic|1=PIDFile=}} as well so ''systemd'' can keep track of the main process.<br />
* {{ic|1=Type=oneshot}}: this is useful for scripts that do a single job and then exit. You may want to set {{ic|1=RemainAfterExit=yes}} as well so that ''systemd'' still considers the service as active after the process has exited.<br />
* {{ic|1=Type=notify}}: identical to {{ic|1=Type=simple}}, but with the stipulation that the daemon will send a signal to ''systemd'' when it is ready. The reference implementation for this notification is provided by ''libsystemd-daemon.so''.<br />
* {{ic|1=Type=dbus}}: the service is considered ready when the specified {{ic|BusName}} appears on DBus's system bus.<br />
<br />
=== Editing provided unit files ===<br />
<br />
To edit a unit file provided by a package, you can create a directory called {{ic|/etc/systemd/system/''unit''.d/}} for example {{ic|/etc/systemd/system/httpd.service.d/}} and place ''*.conf'' files in there to override or add new options. ''systemd'' will parse these ''*.conf'' files and apply them on top of the original unit. For example, if you simply want to add an additional dependency to a unit, you may create the following file:<br />
<br />
{{hc|/etc/systemd/system/''unit''.d/customdependency.conf|2=<br />
[Unit]<br />
Requires=''new dependency''<br />
After=''new dependency''<br />
}}<br />
<br />
As another example, in order to replace the {{ic|ExecStart}} directive for a unit that is not of type {{ic|oneshot}}, create the following file:<br />
<br />
{{hc|/etc/systemd/system/''unit''.d/customexec.conf|2=<br />
[Service]<br />
ExecStart=<br />
ExecStart=''new command''<br />
}}<br />
<br />
One more example to automatically restart a service:<br />
<br />
{{hc|/etc/systemd/system/''unit''.d/restart.conf|2=<br />
[Service]<br />
Restart=always<br />
RestartSec=30<br />
}}<br />
<br />
Then run the following for your changes to take effect:<br />
<br />
# systemctl daemon-reload<br />
# systemctl restart ''unit''<br />
<br />
Alternatively you can copy the old unit file from {{ic|/usr/lib/systemd/system/}} to {{ic|/etc/systemd/system/}} and make your changes there. A unit file in {{ic|/etc/systemd/system/}} always overrides the same unit in {{ic|/usr/lib/systemd/system/}}. Note that when the original unit in {{ic|/usr/lib/}} is changed due to a package upgrade, these changes will not automatically apply to your custom unit file in {{ic|/etc/}}. Additionally you will have to manually reenable the unit with {{ic|systemctl reenable ''unit''}}. It is therefore recommended to use the ''*.conf'' method described before instead.<br />
<br />
{{Tip|You can use '''systemd-delta''' to see which unit files have been overridden and what exactly has been changed.}}<br />
<br />
As the provided unit files will be updated from time to time, use ''systemd-delta'' for system maintenance.<br />
<br />
=== Syntax highlighting for units within Vim ===<br />
<br />
Syntax highlighting for ''systemd'' unit files within [[Vim]] can be enabled by installing {{Pkg|vim-systemd}} from the [[official repositories]].<br />
<br />
== Targets ==<br />
<br />
''systemd'' uses ''targets'' which serve a similar purpose as runlevels but act a little different. Each ''target'' is named instead of numbered and is intended to serve a specific purpose with the possibility of having multiple ones active at the same time. Some ''target''s are implemented by inheriting all of the services of another ''target'' and adding additional services to it. There are ''systemd'' ''target''s that mimic the common SystemVinit runlevels so you can still switch ''target''s using the familiar {{ic|telinit RUNLEVEL}} command.<br />
<br />
=== Get current targets ===<br />
<br />
The following should be used under ''systemd'' instead of running {{ic|runlevel}}:<br />
<br />
$ systemctl list-units --type=target<br />
<br />
=== Create custom target ===<br />
<br />
The runlevels that are assigned a specific purpose on vanilla Fedora installs; 0, 1, 3, 5, and 6; have a 1:1 mapping with a specific ''systemd'' ''target''. Unfortunately, there is no good way to do the same for the user-defined runlevels like 2 and 4. If you make use of those it is suggested that you make a new named ''systemd'' ''target'' as {{ic|/etc/systemd/system/''your target''}} that takes one of the existing runlevels as a base (you can look at {{ic|/usr/lib/systemd/system/graphical.target}} as an example), make a directory {{ic|/etc/systemd/system/''your target''.wants}}, and then symlink the additional services from {{ic|/usr/lib/systemd/system/}} that you wish to enable.<br />
<br />
=== Targets table ===<br />
<br />
{| border="1"<br />
! SysV Runlevel !! systemd Target !! Notes<br />
|-<br />
| 0 || runlevel0.target, poweroff.target || Halt the system.<br />
|-<br />
| 1, s, single || runlevel1.target, rescue.target || Single user mode.<br />
|-<br />
| 2, 4 || runlevel2.target, runlevel4.target, multi-user.target || User-defined/Site-specific runlevels. By default, identical to 3.<br />
|-<br />
| 3 || runlevel3.target, multi-user.target || Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.<br />
|-<br />
| 5 || runlevel5.target, graphical.target || Multi-user, graphical. Usually has all the services of runlevel 3 plus a graphical login.<br />
|-<br />
| 6 || runlevel6.target, reboot.target || Reboot<br />
|-<br />
| emergency || emergency.target || Emergency shell<br />
|-<br />
|}<br />
<br />
=== Change current target ===<br />
<br />
In ''systemd'' targets are exposed via ''target units''. You can change them like this:<br />
<br />
# systemctl isolate graphical.target<br />
<br />
This will only change the current target, and has no effect on the next boot. This is equivalent to commands such as {{ic|telinit 3}} or {{ic|telinit 5}} in Sysvinit.<br />
<br />
=== Change default target to boot into ===<br />
<br />
The standard target is ''default.target'', which is aliased by default to ''graphical.target'' (which roughly corresponds to the old runlevel 5). To change the default target at boot-time, append one of the following [[kernel parameters]] to your bootloader:<br />
<br />
{{Tip|The ''.target'' extension can be left out.}}<br />
<br />
* {{ic|1=systemd.unit=multi-user.target}} (which roughly corresponds to the old runlevel 3),<br />
* {{ic|1=systemd.unit=rescue.target}} (which roughly corresponds to the old runlevel 1).<br />
<br />
Alternatively, you may leave the bootloader alone and change ''default.target''. This can be done using ''systemctl'':<br />
<br />
# systemctl enable multi-user.target<br />
<br />
The effect of this command is output by ''systemctl''; a symlink to the new default target is made at {{ic|/etc/systemd/system/default.target}}. This works if, and only if:<br />
<br />
[Install]<br />
Alias=default.target<br />
<br />
is in the target's configuration file. Currently, ''multi-user.target'' and ''graphical.target'' both have it.<br />
<br />
== Temporary files ==<br />
<br />
"'''systemd-tmpfiles''' creates, deletes and cleans up volatile and temporary files and directories." It reads configuration files in {{ic|/etc/tmpfiles.d/}} and {{ic|/usr/lib/tmpfiles.d/}} to discover which actions to perform. Configuration files in the former directory take precedence over those in the latter directory.<br />
<br />
Configuration files are usually provided together with service files, and they are named in the style of {{ic|/usr/lib/tmpfiles.d/''program''.conf}}. For example, the [[Samba]] daemon expects the directory {{ic|/run/samba}} to exist and to have the correct permissions. Therefore, the {{Pkg|samba}} package ships with this configuration:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /run/samba 0755 root root}}<br />
<br />
Configuration files may also be used to write values into certain files on boot. For example, if you used {{ic|/etc/rc.local}} to disable wakeup from USB devices with {{ic|echo USBE > /proc/acpi/wakeup}}, you may use the following tmpfile instead:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
See the {{ic|systemd-tmpfiles}} and {{ic|tmpfiles.d(5)}} man pages for details.<br />
<br />
{{Note|This method may not work to set options in {{ic|/sys}} since the ''systemd-tmpfiles-setup'' service may run before the appropriate device modules is loaded. In this case you could check whether the module has a parameter for the option you want to set with {{ic|modinfo ''module''}} and set this option with a [[Modprobe.d#Configuration|config file in /etc/modprobe.d]]. Otherwise you will have to write a [[Udev#About_udev_rules|udev rule]] to set the appropriate attribute as soon as the device appears.}}<br />
<br />
== Timers ==<br />
<br />
Systemd can replace cron functionality to a great extent. For further information, please refer to [[systemd/cron functionality]].<br />
<br />
== Journal ==<br />
<br />
''systemd'' has its own logging system called the journal; therefore, running a syslog daemon is no longer required. To read the log, use:<br />
<br />
# journalctl<br />
<br />
As in Arch Linux the directory {{ic|/var/log/journal/}} is part of the ''systemd'' package, the journal (when {{ic|1=Storage=}} is set to {{ic|auto}} in {{ic|/etc/systemd/journald.conf}}) will write to {{ic|/var/log/journal/}}. If you or some program delete that directory, systemd will '''not''' recreate it automatically; however, it will be recreated during the next update of the systemd package. Until then, logs will be written to {{ic|/run/systemd/journal}}, and logs will be lost on reboot.<br />
<br />
{{Tip|If {{ic|/var/log/journal/}} resides in a [[btrfs]] filesystem you should consider disabling [[Btrfs#Copy-On-Write_.28CoW.29|Copy-on-Write]] for the directory:<br />
# chattr +C /var/log/journal<br />
}}<br />
<br />
=== Filtering output ===<br />
<br />
''journalctl'' allows you to filter the output by specific fields. Be aware that if there are many messages to display or filtering of large time span has to be done, the output of this command can be delayed for quite some time.<br />
<br />
Examples:<br />
<br />
Show all messages from this boot:<br />
<br />
# journalctl -b<br />
<br />
However, often one is interested in messages not from the current, but from the previous boot (e.g. if an unrecoverable system crash happened). This is possible through optional offset parameter of the {{ic|-b}} flag: {{ic|journalctl -b -0}} shows messages from the current boot, {{ic|journalctl -b -1}} from the previous boot, {{ic|journalctl -b -2}} from the second previous and so on. See {{ic|man 1 journalctl}} for full description, the semantics is much more powerful.<br />
<br />
Follow new messages:<br />
<br />
# journalctl -f<br />
<br />
Follow new messages with line wrapping and readable output<br />
# journalctl -f | sed "s/$(hostname)/$(hostname) - - - - - - - - - - - - - - - - - - - - - - - -\n/"<br />
<br />
Show all messages by a specific executable:<br />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Show all messages by a specific process:<br />
<br />
# journalctl _PID=1<br />
<br />
Show all messages by a specific unit:<br />
<br />
# journalctl -u netcfg<br />
<br />
Show kernel ring buffer:<br />
<br />
# journalctl _TRANSPORT=kernel<br />
<br />
See {{ic|man 1 journalctl}}, {{ic|man 7 systemd.journal-fields}}, or Lennert's [http://0pointer.de/blog/projects/journalctl.html blog post] for details.<br />
<br />
=== Journal size limit ===<br />
<br />
If the journal is persistent (non-volatile), its size limit is set to a default value of 10% of the size of the respective file system. For example, with {{ic|/var/log/journal}} located on a 50 GiB root partition this would lead to 5 GiB of journal data. The maximum size of the persistent journal can be controlled by {{ic|SystemMaxUse}} in {{ic|/etc/systemd/journald.conf}}, so to limit it for example to 50 MiB uncomment and edit the corresponding line to:<br />
<br />
SystemMaxUse=50M<br />
<br />
Refer to {{ic|man journald.conf}} for more info.<br />
<br />
=== Journald in conjunction with syslog ===<br />
<br />
Compatibility with classic syslog implementations is provided via a socket {{ic|/run/systemd/journal/syslog}}, to which all messages are forwarded. To make the syslog daemon work with the journal, it has to bind to this socket instead of {{ic|/dev/log}} ([http://lwn.net/Articles/474968/ official announcement]). The {{Pkg|syslog-ng}} package in the repositories automatically provides the necessary configuration.<br />
<br />
# systemctl enable syslog-ng<br />
<br />
A good ''journalctl'' tutorial is [http://0pointer.de/blog/projects/journalctl.html here].<br />
<br />
=== Forward journald to /dev/tty12 ===<br />
<br />
In {{ic|/etc/systemd/journald.conf}} enable the following:<br />
<br />
ForwardToConsole=yes<br />
TTYPath=/dev/tty12<br />
MaxLevelConsole=info<br />
<br />
Restart journald with {{ic|sudo systemctl restart systemd-journald}}.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Investigating systemd errors ===<br />
<br />
As an example, we will investigate an error with {{ic|systemd-modules-load}} service:<br />
<br />
'''1.''' Lets find the systemd services which fail to start:<br />
{{hc|1=$ systemctl --state=failed|2=<br />
systemd-modules-load.service loaded '''failed failed''' Load Kernel Modules<br />
}}<br />
<br />
'''2.''' Ok, we found a problem with {{ic|systemd-modules-load}} service. We want to know more:<br />
{{hc|$ systemctl status systemd-modules-load|2=<br />
systemd-modules-load.service - Load Kernel Modules<br />
Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)<br />
Active: '''failed''' (Result: exit-code) since So 2013-08-25 11:48:13 CEST; 32s ago<br />
Docs: man:systemd-modules-load.service(8).<br />
man:modules-load.d(5)<br />
Process: '''15630''' ExecStart=/usr/lib/systemd/systemd-modules-load ('''code=exited, status=1/FAILURE''')<br />
}}<br />
<br />
'''3.''' Now we have the process id (PID) to investigate this error in depth. Enter the following command with the current {{ic|Process ID}} (here: 15630):<br />
{{hc|1=$ journalctl -b _PID=15630|2=<br />
-- Logs begin at Sa 2013-05-25 10:31:12 CEST, end at So 2013-08-25 11:51:17 CEST. --<br />
Aug 25 11:48:13 mypc systemd-modules-load[15630]: '''Failed to find module 'blacklist usblp''''<br />
Aug 25 11:48:13 mypc systemd-modules-load[15630]: '''Failed to find module 'install usblp /bin/false'''' <br />
}}<br />
<br />
'''4.''' We see that some of the kernel module configs have wrong settings. Therefore we have a look at these settings in {{ic|/etc/modules-load.d/}}:<br />
{{hc|$ ls -Al /etc/modules-load.d/|<br />
...<br />
-rw-r--r-- 1 root root 79 1. Dez 2012 blacklist.conf<br />
-rw-r--r-- 1 root root 1 2. Mär 14:30 encrypt.conf<br />
-rw-r--r-- 1 root root 3 5. Dez 2012 printing.conf<br />
-rw-r--r-- 1 root root 6 14. Jul 11:01 realtek.conf<br />
-rw-r--r-- 1 root root 65 2. Jun 23:01 virtualbox.conf<br />
...<br />
}}<br />
<br />
'''5.''' The {{ic|Failed to find module 'blacklist usblp'}} error message might be related to a wrong setting inside of {{ic|blacklist.conf}}. Lets deactivate it with inserting a trailing '''#''' before each option we found via step 3:<br />
{{hc|/etc/modules-load.d/blacklist.conf|<br />
'''#''' blacklist usblp<br />
'''#''' install usblp /bin/false<br />
}}<br />
<br />
'''6.''' Now, try to start {{ic|systemd-modules-load}}:<br />
$ systemctl start systemd-modules-load.service<br />
If it was successful, this shouldn't prompt anything. If you see any error, go back to step 3. and use the new PID for solving the errors left.<br />
<br />
If everything is ok, you can verify that the service was started successfully with:<br />
{{hc|$ systemctl status systemd-modules-load|2=<br />
systemd-modules-load.service - Load Kernel Modules<br />
Loaded: '''loaded''' (/usr/lib/systemd/system/systemd-modules-load.service; static)<br />
Active: '''active (exited)''' since So 2013-08-25 12:22:31 CEST; 34s ago<br />
Docs: man:systemd-modules-load.service(8)<br />
man:modules-load.d(5)<br />
Process: 19005 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)<br />
Aug 25 12:22:31 mypc systemd[1]: '''Started Load Kernel Modules'''.<br />
}}<br />
<br />
Often you can solve these kind of problems like shown above. For further investigation look at [[#Diagnosing boot problems|Diagnosing boot problems]].<br />
<br />
=== Diagnosing boot problems ===<br />
<br />
Boot with these parameters on the kernel command line:<br />
{{ic|<nowiki>systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M</nowiki>}}<br />
<br />
[http://freedesktop.org/wiki/Software/systemd/Debugging More Debugging Information]<br />
<br />
=== Shutdown/reboot takes terribly long ===<br />
<br />
If the shutdown process takes a very long time (or seems to freeze) most likely a service not exiting is to blame. ''systemd'' waits some time for each service to exit before trying to kill it. To find out if you are affected, see [http://freedesktop.org/wiki/Software/systemd/Debugging/#shutdowncompleteseventually this article].<br />
<br />
=== Short lived processes do not seem to log any output ===<br />
<br />
If {{ic|journalctl -u foounit}} does not show any output for a short lived service, look at the PID instead. For example, if {{ic|systemd-modules-load.service}} fails, and {{ic|systemctl status systemd-modules-load}} shows that it ran as PID 123, then you might be able to see output in the journal for that PID, i.e. {{ic|journalctl -b _PID&#61;123}}. Metadata fields for the journal such as _SYSTEMD_UNIT and _COMM are collected asynchronously and rely on the {{ic|/proc}} directory for the process existing. Fixing this requires fixing the kernel to provide this data via a socket connection, similar to SCM_CREDENTIALS.<br />
<br />
=== Disabling application crash dumps journaling ===<br />
<br />
Run the following in order to overwrite the settings from {{ic|/lib/sysctl.d/}}:<br />
# ln -s /dev/null /etc/sysctl.d/50-coredump.conf<br />
# sysctl kernel.core_pattern=core<br />
<br />
This will disable logging of coredumps to the journal.<br />
<br />
Note that the default RLIMIT_CORE of 0 means that no core files are written, either.<br />
If you want them, you also need to "unlimit" the core file size in the shell:<br />
$ ulimit -c unlimited<br />
<br />
See [http://www.freedesktop.org/software/systemd/man/sysctl.d.html sysctl.d] and [https://www.kernel.org/doc/Documentation/sysctl/kernel.txt the documentation for /proc/sys/kernel] for more information.<br />
<br />
== See also ==<br />
<br />
*[http://www.freedesktop.org/wiki/Software/systemd Official web site]<br />
*[[Wikipedia:systemd|Wikipedia article]]<br />
*[http://0pointer.de/public/systemd-man/ Manual pages]<br />
*[http://freedesktop.org/wiki/Software/systemd/Optimizations systemd optimizations]<br />
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ]<br />
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Tips and tricks]<br />
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd for Administrators (PDF)]<br />
*[http://fedoraproject.org/wiki/Systemd About systemd on Fedora Project]<br />
*[http://fedoraproject.org/wiki/How_to_debug_Systemd_problems How to debug systemd problems]<br />
*[http://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html Two] [http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html part] introductory article in ''The H Open'' magazine.<br />
*[http://0pointer.de/blog/projects/systemd.html Lennart's blog story]<br />
*[http://0pointer.de/blog/projects/systemd-update.html Status update]<br />
*[http://0pointer.de/blog/projects/systemd-update-2.html Status update2]<br />
*[http://0pointer.de/blog/projects/systemd-update-3.html Status update3]<br />
*[http://0pointer.de/blog/projects/why.html Most recent summary]<br />
*[http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora's SysVinit to systemd cheatsheet]<br />
*[[Allow Users to Shutdown|Configuring systemd to allow normal users to shutdown]]</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Capabilities&diff=283661Capabilities2013-11-19T13:15:11Z<p>Hunterthomson: Added warning and link for further reading</p>
<hr />
<div>[[Category:Security]]<br />
The intention of this article is to remove the setuid attribute in the binaries that require certain root-privileges.<br />
In this way, it eliminates the need for "all or nothing", using a fine grained control with POSIX 1003.1e capabilities.<br />
<br />
{{Warning|Use with caution, some programs do not know about file capabilities. It apparently works correctly, but have some unexpected side effects (see for example [[#util-linux-ng|util-linux-ng]]).}}<br />
{{Warning|Many capabilities enable trivial privilege escalation. For examples and explanations see Brad Spengler's post [http://forums.grsecurity.net/viewtopic.php?f&#61;7&t&#61;2522&sid&#61;c6fbcf62fd5d3472562540a7e608ce4e#p10271 False Boundaries and Arbitrary Code Execution].}}<br />
<br />
== Prerequisites ==<br />
<br />
You need to [[pacman|install]] {{Pkg|libcap}}, for setting file capabalities that are extended attributes, with the utility ''setcap''.<br />
<br />
== Setuid-root files by package ==<br />
<br />
=== coreutils ===<br />
<br />
{{Warning|Do not use it, because su will return incorrect password.}}<br />
<br />
# chmod u-s /usr/bin/su<br />
# setcap cap_setgid,cap_setuid+ep /usr/bin/su<br />
<br />
=== dcron ===<br />
<br />
# chmod u-s /usr/bin/crontab<br />
# setcap cap_dac_override,cap_setgid+ep /usr/bin/crontab<br />
<br />
=== inetutils ===<br />
<br />
# chmod u-s /usr/bin/rsh<br />
# setcap cap_net_bind_service+ep /usr/bin/rsh<br />
<br />
# chmod u-s /usr/bin/rcp<br />
# setcap cap_net_bind_service+ep /usr/bin/rcp<br />
<br />
# chmod u-s /usr/bin/rlogin<br />
# setcap cap_net_bind_service+ep /usr/bin/rlogin<br />
<br />
=== iputils ===<br />
<br />
# chmod u-s /usr/bin/ping<br />
# setcap cap_net_raw+ep /usr/bin/ping<br />
<br />
# chmod u-s /usr/bin/ping6<br />
# setcap cap_net_raw+ep /usr/bin/ping6<br />
<br />
# chmod u-s /usr/bin/traceroute<br />
# setcap cap_net_raw+ep /usr/bin/traceroute<br />
<br />
# chmod u-s /usr/bin/traceroute6<br />
# setcap cap_net_raw+ep /usr/bin/traceroute6<br />
<br />
=== pam ===<br />
<br />
# chmod u-s /usr/bin/unix_chkpwd<br />
# setcap cap_dac_read_search+ep /usr/bin/unix_chkpwd<br />
<br />
=== pmount ===<br />
<br />
Does not work without setuid.<br />
<br />
=== pulseaudio ===<br />
<br />
# chmod u-s /usr/lib/pulse/proximity-helper<br />
# setcap cap_net_raw+ep /usr/lib/pulse/proximity-helper<br />
<br />
=== screen ===<br />
<br />
Needs setuid for multiuser sessions, but if you do not need that feature, you can safely turn off setuid.<br />
<br />
=== shadow ===<br />
<br />
# chmod u-s /usr/bin/chage<br />
# setcap cap_dac_read_search+ep /usr/bin/chage<br />
<br />
# chmod u-s /usr/bin/chfn<br />
# setcap cap_chown,cap_setuid+ep /usr/bin/chfn<br />
<br />
# chmod u-s /usr/bin/chsh<br />
# setcap cap_chown,cap_setuid+ep /usr/bin/chsh<br />
<br />
# chmod u-s /usr/bin/expiry<br />
# setcap cap_dac_override,cap_setgid+ep /usr/bin/expiry<br />
<br />
# chmod u-s /usr/bin/gpasswd<br />
# setcap cap_chown,cap_dac_override,cap_setuid+ep /usr/bin/gpasswd<br />
<br />
# chmod u-s /usr/bin/newgrp<br />
# setcap cap_dac_override,cap_setgid+ep /usr/bin/newgrp<br />
<br />
# chmod u-s /usr/bin/passwd<br />
# setcap cap_chown,cap_dac_override,cap_fowner+ep /usr/bin/passwd<br />
<br />
=== sudo ===<br />
<br />
Sudo does not work without setuid.<br />
<br />
=== util-linux-ng ===<br />
<br />
{{Warning|Do not use it, because mount and umount can not do some checks, then users can mount/umount filesystems that do not have permission.}}<br />
<br />
# chmod u-s /usr/bin/mount<br />
# setcap cap_dac_override,cap_sys_admin+ep /usr/bin/mount<br />
<br />
# chmod u-s /usr/bin/umount<br />
# setcap cap_dac_override,cap_sys_admin+ep /usr/bin/umount<br />
<br />
=== xorg-xserver ===<br />
<br />
# chmod u-s /usr/bin/Xorg<br />
# setcap cap_chown,cap_dac_override,cap_sys_rawio,cap_sys_admin+ep /usr/bin/Xorg<br />
<br />
== Other programs that benefit from capabilities ==<br />
<br />
The following packages do not have files with the setuid attribute but require root privileges to work. By enabling some capabilities, regular users can use the program without privilege elevation.<br />
<br />
=== beep ===<br />
<br />
# setcap cap_dac_override,cap_sys_tty_config+ep /usr/bin/beep<br />
<br />
=== chvt ===<br />
<br />
# setcap cap_dac_read_search,cap_sys_tty_config+ep /usr/bin/chvt<br />
<br />
=== iftop ===<br />
<br />
# setcap cap_net_raw+ep /usr/bin/iftop<br />
<br />
=== mii-tool ===<br />
<br />
# setcap cap_net_admin+ep /usr/bin/mii-tool<br />
<br />
== Useful commands ==<br />
<br />
Find setuid-root files:<br />
$ find /usr/bin /usr/lib -perm /4000 -user root<br />
<br />
Find setgid-root files:<br />
$ find /usr/bin /usr/lib -perm /2000 -group root<br />
<br />
== See also ==<br />
<br />
* Man Page capabilities(7) setcap(8) getcap(8)</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Very_Secure_FTP_Daemon&diff=282274Very Secure FTP Daemon2013-11-10T23:10:55Z<p>Hunterthomson: /* vsftpd: refusing to run with writable root inside chroot() */</p>
<hr />
<div>[[Category:File Transfer Protocol]]<br />
[[cs:Very Secure FTP Daemon]]<br />
[[es:Very Secure FTP Daemon]]<br />
[[it:Very Secure FTP Daemon]]<br />
[[ru:Very Secure FTP Daemon]]<br />
[[zh-CN:Very Secure FTP Daemon]]<br />
'''vsftpd''' (Very Secure FTP Daemon) is a lightweight, stable and secure FTP server for UNIX-like systems.<br />
<br />
== Installation ==<br />
Simply install {{pkg|vsftpd}} from the [[Official Repositories]].<br />
<br />
To start the server:<br />
# systemctl start vsftpd.service<br />
<br />
If you want it to be started automatically at boot:<br />
# systemctl enable vsftpd.service<br />
<br />
See the xinetd section below for procedures to use vsftpd with xinetd.<br />
<br />
== Configuration ==<br />
Most of the settings in vsftpd are done by editing the file {{ic|/etc/vsftpd.conf}}. The file itself is well-documented, so this section only highlights some important changes you may want to modify. For all available options and documentation, one can man vsftpd.conf (5). Files are served by default from {{ic|/srv/ftp}}.<br />
<br />
=== Enabling uploading ===<br />
The {{Ic|WRITE_ENABLE}} flag must be set to YES in {{ic|/etc/vsftpd.conf}} in order to allow changes to the filesystem, such as uploading:<br />
write_enable=YES<br />
<br />
=== Local user login ===<br />
One must set the line to {{ic|/etc/vsftpd.conf}} to allow users in {{ic|/etc/passwd}} to login:<br />
local_enable=YES<br />
<br />
=== Anonymous login ===<br />
The line in {{ic|/etc/vsftpd.conf}} controls whether anonymous users can login:<br />
# Allow anonymous login<br />
anonymous_enable=YES<br />
# No password is required for an anonymous login <br />
no_anon_password=YES<br />
# Maximum transfer rate for an anonymous client in Bytes/second <br />
anon_max_rate=30000 <br />
# Directory to be used for an anonymous login <br />
anon_root=/example/directory/<br />
<br />
=== Chroot jail ===<br />
One can set up a chroot environment which prevents the user from leaving its home directory. To enable this, add the following lines to {{ic|/etc/vsftpd.conf}}:<br />
chroot_list_enable=YES<br />
chroot_list_file=/etc/vsftpd.chroot_list<br />
The {{Ic|chroot_list_file}} variable specifies the file which contains users that are jailed.<br />
<br />
For a more restricted environment, one can specify the line:<br />
chroot_local_user=YES<br />
This will make local users jailed by default. In this case, the file specified by {{Ic|chroot_list_file}} lists users that are '''not''' in a chroot jail.<br />
<br />
=== Limiting user login ===<br />
It's possible to prevent users from logging into the FTP server by adding two lines to {{ic|/etc/vsftpd.conf}}:<br />
userlist_enable=YES<br />
userlist_file=/etc/vsftpd.user_list<br />
{{Ic|userlist_file}} now specifies the file which lists users that are not able to login.<br />
<br />
If you only want to allow certain users to login, add the line:<br />
userlist_deny=NO<br />
The file specified by {{Ic|userlist_file}} will now contain users that are able to login.<br />
<br />
=== Limiting connections ===<br />
One can limit the data transfer rate, number of clients and connections per IP for local users by adding the information in {{ic|/etc/vsftpd.conf}}:<br />
local_max_rate=1000000 # Maximum data transfer rate in bytes per second<br />
max_clients=50 # Maximum number of clients that may be connected<br />
max_per_ip=2 # Maximum connections per IP<br />
<br />
=== Using xinetd ===<br />
{{Out of date|Contains reference to rc.conf, which does not exist anymore.}}<br />
If you want to use vsftpd with xinetd, add the following lines to {{ic|/etc/xinetd.d/vsftpd}}:<br />
<pre><br />
service ftp<br />
{<br />
socket_type = stream<br />
wait = no<br />
user = root<br />
server = /usr/bin/vsftpd<br />
log_on_success += HOST DURATION<br />
log_on_failure += HOST<br />
disable = no<br />
}<br />
</pre><br />
<br />
The option below should be set in {{ic|/etc/vsftpd.conf}}:<br />
pam_service_name=ftp<br />
<br />
Finally, add xinetd to your daemons line in {{ic|/etc/rc.conf}}. You do not need to add vsftpd, as it will be called by xinetd whenever necessary.<br />
<br />
If you get errors like this while connecting to the server:<br />
500 OOPS: cap_set_proc<br />
You need to add ''capability'' in MODULES= line in {{ic|/etc/rc.conf}}.<br />
<br />
While upgrading to version 2.1.0 you might get an error like this when connecting to the server from a client:<br />
500 OOPS: could not bind listening IPv4 socket<br />
In earlier versions it has been enough to leave the following lines commented:<br />
# Use this to use vsftpd in standalone mode, otherwise it runs through (x)inetd<br />
# listen=YES<br />
In this newer version, and maybe future releases, it is necessary however to explicitly configure it to '''not''' run in a standalone mode, like this:<br />
# Use this to use vsftpd in standalone mode, otherwise it runs through (x)inetd<br />
listen=NO<br />
<br />
=== Using SSL to Secure FTP ===<br />
<br />
Generate an SSL Cert, e.g. like that: <br />
# cd /etc/ssl/certs<br />
# openssl req -x509 -nodes -days 7300 -newkey rsa:2048 -keyout /etc/ssl/certs/vsftpd.pem -out /etc/ssl/certs/vsftpd.pem<br />
# chmod 600 /etc/ssl/certs/vsftpd.pem<br />
You will be asked a lot of Questions about your Company etc., as your Certificate is not a trusted one it doesn't really matter what you fill in. You will use this for encryption! If you plan to use this in a matter of trust get one from a CA like thawte, verisign etc. <br />
<br />
edit your configuration {{ic|/etc/vsftpd.conf}}<br />
<pre><br />
#this is important<br />
ssl_enable=YES<br />
<br />
#choose what you like, if you accept anon-connections<br />
# you may want to enable this<br />
# allow_anon_ssl=NO<br />
<br />
#choose what you like,<br />
# it's a matter of performance i guess<br />
# force_local_data_ssl=NO<br />
<br />
#choose what you like<br />
force_local_logins_ssl=YES<br />
<br />
#you should at least enable this if you enable ssl...<br />
ssl_tlsv1=YES<br />
#choose what you like<br />
ssl_sslv2=YES<br />
#choose what you like<br />
ssl_sslv3=YES<br />
#give the correct path to your currently generated *.pem file<br />
rsa_cert_file=/etc/ssl/certs/vsftpd.pem<br />
#the *.pem file contains both the key and cert<br />
rsa_private_key_file=/etc/ssl/certs/vsftpd.pem<br />
</pre><br />
<br />
=== Dynamic DNS ===<br />
Make sure you put the following two lines in {{ic|/etc/vsftpd.conf}}:<br />
pasv_addr_resolve=YES<br />
pasv_address=yourdomain.noip.info<br />
It is '''not''' necessary to use a script that updates pasv_address periodically and restarts the server, as it can be found elsewhere!<br />
{{Note|You won't be able to connect in passive mode via LAN anymore. Try the active mode on your LAN PC's FTP client.}}<br />
<br />
<br />
=== Port configurations ===<br />
Especially for private FTP servers that are exposed to the web it's recommended to change the listening port to something other that the standard port 21. This can be done using the following lines in {{ic|/etc/vsftpd.conf}}:<br />
listen_port=2211<br />
Furthermore a custom passive port range can be given by:<br />
pasv_min_port=49152<br />
pasv_max_port=65534<br />
<br />
=== Configuring iptables ===<br />
Often the server running the FTP daemon is protected by an [[iptables]] firewall. To allow access to the FTP server the corresponding port needs to be opened using something like<br />
# iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 2211 -j ACCEPT<br />
This article won't provide any instruction on how to set up iptables but here is an example: [[Simple stateful firewall]].<br />
<br />
There are some kernel modules needed for proper FTP connection handling by iptables that should be referenced here. Among those especially ''ip_conntrack_ftp''. It is needed as FTP uses the given ''listen_port'' (21 by default) for commands only; all the data transfer is done over different ports. These ports are chosen by the FTP daemon at random and for each session (also depending on whether active or passive mode is used). To tell iptables that packets on ports should be accepted, ''ip_conntrack_ftp'' is required. To load it automatically on boot create a new file in {{ic|/etc/modules-load.d}} e.g.:<br />
# echo ip_conntrack_ftp > /etc/modules-load.d/ip_conntrack_ftp.conf<br />
<br />
If you changed the ''listen_port'' you also need to configure the conntrack module accordingly:<br />
{{hc|/etc/modprobe.d/ip_conntrack_ftp.conf|<nowiki><br />
options nf_conntrack_ftp ports=2211<br />
options ip_conntrack_ftp ports=2211</nowiki>}}<br />
<br />
== Tips and tricks ==<br />
=== PAM with virtual users ===<br />
Using virtual users has the advantage of not requiring a real login account on the system. Keeping the environment in a container is of course a more secure option.<br />
<br />
A virtual users database has to be created by first making a simple text file like this:<br />
user1<br />
password1<br />
user2<br />
password2<br />
Include as many virtual users as you wish according to the structure in the example. Save it as logins.txt; the file name does not have any significance. Next step depends on Berkeley database system, which is included in the core system of Arch. As root create the actual database with the help of the logins.txt file, or what you chose to call it:<br />
# db_load -T -t hash -f logins.txt /etc/vsftpd_login.db<br />
It is recommended to restrict permissions for the now created {{ic|vsftpd_login.db}} file:<br />
# chmod 600 /etc/vsftpd_login.db<br />
{{Warning|Be aware that stocking passwords in plain text is not safe. Don't forget to remove your temporary file with {{Ic|rm logins.txt}}.}}<br />
PAM should now be set to make use of vsftpd_login.db. To make PAM check for user authentication create a file named ftp in the {{ic|/etc/pam.d/}} directory with the following information:<br />
auth required pam_userdb.so db=/etc/vsftpd_login crypt=hash <br />
account required pam_userdb.so db=/etc/vsftpd_login crypt=hash<br />
{{Note|We use /etc/vsftpd_login without .db extension in PAM-config!}}<br />
Now it is time to create a home for the virtual users. In the example {{ic|/srv/ftp}} is decided to host data for virtual users, which also reflects the default directory structure of Arch. First create the general user virtual and make {{ic|/srv/ftp}} its home:<br />
# useradd -d /srv/ftp virtual<br />
Make virtual the owner:<br />
# chown virtual:virtual /srv/ftp<br />
Configure vsftpd to use the created environment by editing {{ic|/etc/vsftpd.conf}}. These are the necessary settings to make vsftpd restrict access to virtual users, by user-name and password, and restrict their access to the specified area {{ic|/srv/ftp}}:<br />
anonymous_enable=NO<br />
local_enable=YES<br />
chroot_local_user=YES<br />
guest_enable=YES<br />
guest_username=virtual<br />
virtual_use_local_privs=YES<br />
If the xinetd method is used start the service. You should now only be allowed to login by user-name and password according to the made database.<br />
<br />
==== Adding private folders for the virtual users ====<br />
First create directories for users:<br />
# mkdir /srv/ftp/user1<br />
# mkdir /srv/ftp/user2<br />
# chown virtual:virtual /srv/ftp/user?/<br />
<br />
Then, add the following lines to {{ic|/etc/vsftpd.conf}}:<br />
local_root=/srv/ftp/$USER<br />
user_sub_token=$USER<br />
<br />
== Troubleshooting ==<br />
<br />
=== vsftpd: no connection (Error 500) with recent kernels (3.5 and newer) and .service ===<br />
add this to your /etc/vsftpd.conf<br />
seccomp_sandbox=NO<br />
<br />
=== vsftpd: refusing to run with writable root inside chroot() ===<br />
As of vsftpd 2.3.5, the chroot directory that users are locked to must not be writable. This is in order to prevent a security vulnerabilty.<br />
<br />
The safe way to allow upload is to keep chroot enabled, and configure your FTP directories.<br />
<br />
local_root=/srv/ftp/user<br />
<br />
# mkdir -p /srv/ftp/user/upload<br />
#<br />
# chmod 550 /srv/ftp/user<br />
# chmod 750 /srv/ftp/user/upload<br />
<br />
<br />
If you must:<br />
<br />
You can put this into your {{ic|/etc/vsftpd.conf}} to workaround this security enhancement (since vsftpd 3.0.0; from [http://www.benscobie.com/fixing-500-oops-vsftpd-refusing-to-run-with-writable-root-inside-chroot/ Fixing 500 OOPS: vsftpd: refusing to run with writable root inside chroot ()]):<br />
allow_writeable_chroot=YES<br />
or alternative:<br />
<br />
Install vsftpd-ext from AUR and set in the conf file allow_writable_root=YES<br />
<br />
=== FileZilla Client: GnuTLS error -8 when connecting via SSL ===<br />
vsftpd tries to display plain-text error messages in the SSL session. In order to debug this, temporarily disable encryption and you will see the correct error message.[http://ramblings.linkerror.com/?p=45]<br />
<br />
=== vsftpd.service fails to run on boot ===<br />
If you have enabled the vsftpd service and it fails to run on boot, make sure it is set to load after network.target in the service file:<br />
<br />
{{hc|/usr/lib/systemd/system/vsftpd.service|2=<br />
[Unit]<br />
Description=vsftpd daemon<br />
After=network.target<br />
}}<br />
<br />
== See also ==<br />
* [http://vsftpd.beasts.org/ vsftpd official homepage]<br />
* [http://vsftpd.beasts.org/vsftpd_conf.html vsftpd.conf man page]</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Sudo&diff=281642Sudo2013-11-06T03:14:55Z<p>Hunterthomson: /* Harden with Sudo Example */ Typo</p>
<hr />
<div>[[Category:Security]]<br />
[[cs:Sudo]]<br />
[[es:Sudo]]<br />
[[fr:Sudo]]<br />
[[it:Sudo]]<br />
[[ja:Sudo]]<br />
[[ru:Sudo]]<br />
[[sr:Sudo]]<br />
[[tr:Sudo]]<br />
[[uk:Sudo]]<br />
[[zh-CN:Sudo]]<br />
{{Article summary start}}<br />
{{Article summary text|An overview of the popular privilege escalation utility.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Access control overview}}}}<br />
{{Article summary end}}<br />
<br />
[http://www.gratisoft.us/sudo/ sudo] ("substitute user do") allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments.<br />
<br />
== Rationale ==<br />
<br />
Sudo is an alternative to [[su]] for running commands as root. Unlike [[su]], which launches a root shell that allows all further commands root access, sudo instead grants temporary privilege escalation to a single command. By enabling root privileges only when needed, sudo usage reduces the likelyhood that a typo or a bug in an invoked command will ruin the system.<br />
Sudo can also be used to run commands as other users; additionally, sudo logs all commands and failed access attempts for security auditing.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|sudo}} package, available in the [[Official Repositories|official repositories]]:<br />
<br />
# pacman -S sudo<br />
<br />
To begin using {{ic|sudo}} as a non-privileged user, it must be properly configured. So make sure you read the configuration section.<br />
<br />
== Usage ==<br />
<br />
With sudo, users can prefix commands with {{ic|sudo}} to run them with superuser (or other) privileges.<br />
<br />
For example, to use pacman:<br />
<br />
$ sudo pacman -Syu<br />
<br />
See the [http://www.gratisoft.us/sudo/man/sudo.html sudo manual] for more information.<br />
<br />
== Configuration ==<br />
<br />
=== View current settings ===<br />
<br />
Run {{ic|sudo -ll}} to print out the current sudo configuration.<br />
<br />
=== Using visudo ===<br />
<br />
The configuration file for sudo is {{ic|/etc/sudoers}}. It should '''always''' be edited with the {{ic|visudo}} command. {{ic|visudo}} locks the {{ic|sudoers}} file, saves edits to a temporary file, and checks that file's grammar before copying it to {{ic|/etc/sudoers}}.<br />
<br />
{{Warning|It is imperative that {{ic|sudoers}} be free of syntax errors! Any error makes sudo unusable. '''Always''' edit it with {{ic|visudo}} to prevent errors.}}<br />
<br />
The default editor for visudo is {{ic|vi}}. It will be used if you do not specify another editor, by setting either VISUAL or EDITOR environment variables (used in that order) to the desired editor, e.g. {{ic|nano}}. The command is run as root:<br />
<br />
# EDITOR=nano visudo<br />
<br />
You can permanently change the setting for your user to e.g. {{ic|nano}} by appending:<br />
<br />
export EDITOR=nano<br />
<br />
to your {{ic|~/.bashrc}} file. Note that this won't take effect for already-running shells.<br />
<br />
To change the editor of choice permanently system-wide only for {{ic|visudo}}, add the following line to {{ic|/etc/sudoers}} where {{ic|nano}} is your prefered editor:<br />
<br />
# Reset environment by default<br />
Defaults env_reset<br />
# Set default EDITOR to nano, and do not allow visudo to use EDITOR/VISUAL.<br />
Defaults editor=/usr/bin/nano, !env_editor<br />
<br />
=== Example Entries ===<br />
<br />
To allow a user to gain full root privileges when he/she precedes a command with {{ic|sudo}}, add the following line:<br />
<br />
USER_NAME ALL=(ALL) ALL<br />
<br />
To allow a user to run all commands as any user but only the machine with hostname HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=(ALL) ALL<br />
<br />
To allow members of group {{ic|wheel}} sudo access:<br />
<br />
%wheel ALL=(ALL) ALL<br />
<br />
To disable asking for a password for user USER_NAME:<br />
<br />
Defaults:USER_NAME !authenticate<br />
<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=/usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
{{note| the most customized option should go at the end of the file, as the later lines overrides the previous ones. In particular such a line should be after the {{ic|%wheel}} line if your user is in this group.}}<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME without password:<br />
USER_NAME HOST_NAME= NOPASSWD: /usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
<br />
A detailed sudoers example can be found [http://www.gratisoft.us/sudo/sample.sudoers here]. Otherwise, see the [http://www.gratisoft.us/sudo/man/sudoers.html sudoers manual] for detailed information.<br />
<br />
=== Sudoers default file permissions ===<br />
<br />
The owner and group for the sudoers file must both be 0. The file permissions must be set to 0440. These permissions are set by default, but if you accidentally change them, they should be changed back immediately or sudo will fail.<br />
<br />
# chown -c root:root /etc/sudoers<br />
# chmod -c 0440 /etc/sudoers<br />
<br />
=== Password cache timeout ===<br />
<br />
Users may wish to change the default timeout before the cached password expires. This is accomplished with the timestamp_timeout option in {{ic|/etc/sudoers}} which is in minutes.<br />
Set timeout to 20 minutes.<br />
<br />
Defaults:USER_NAME timestamp_timeout=20<br />
<br />
{{Tip|To ensure sudo always asks for a password, set the timeout to 0. To ensure the password never times out, set to less than 0.}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== File example ===<br />
<br />
This example is especially helpful for those using terminal multiplexers like screen, tmux, or ratpoison, and those using sudo from scripts/cronjobs:<br />
<br />
{{hc|/etc/sudoers|<nowiki><br />
Cmnd_Alias WHEELER = /usr/bin/lsof, /bin/nice, /bin/ps, /usr/bin/top, /usr/local/bin/nano, /usr/bin/ss, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync<br />
Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/kill, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
Cmnd_Alias EDITS = /usr/bin/vim, /usr/bin/nano, /usr/bin/cat, /usr/bin/vi<br />
Cmnd_Alias ARCHLINUX = /usr/bin/gparted, /usr/bin/pacman<br />
<br />
root ALL = (ALL) ALL<br />
USER_NAME ALL = (ALL) ALL, NOPASSWD: WHEELER, NOPASSWD: PROCESSES, NOPASSWD: ARCHLINUX, NOPASSWD: EDITS<br />
<br />
Defaults !requiretty, !tty_tickets, !umask<br />
Defaults visiblepw, path_info, insults, lecture=always<br />
Defaults loglinelen = 0, logfile =/var/log/sudo.log, log_year, log_host, syslog=auth<br />
Defaults mailto=webmaster@foobar.com, mail_badpass, mail_no_user, mail_no_perms<br />
Defaults passwd_tries = 8, passwd_timeout = 1<br />
Defaults env_reset, always_set_home, set_home, set_logname<br />
Defaults !env_editor, editor="/usr/bin/vim:/usr/bin/vi:/usr/bin/nano"<br />
Defaults timestamp_timeout=360<br />
Defaults passprompt="Sudo invoked by [%u] on [%H] - Cmd run as %U - Password for user %p:"<br />
</nowiki>}}<br />
<br />
=== Enabling Tab-completion in Bash ===<br />
<br />
{{ic|Tab}}-completion, by default, will not work when a user is initially added to the sudoers file. For example, normally john only needs to type:<br />
<br />
$ fire<{{ic|Tab}}><br />
<br />
and the shell will complete the command for him as:<br />
<br />
$ firefox<br />
<br />
If, however, john is added to the sudoers file and he types:<br />
<br />
$ sudo fire<{{ic|Tab}}><br />
<br />
the shell will do nothing.<br />
<br />
To enable {{ic|Tab}}-completion with sudo, [[pacman|install]] the {{pkg|bash-completion}} package from the [[Official Repositories|official repositories]]. see [[bash#Tab_completion]] for more information.<br />
<br />
Alternatively, add the following to your {{ic|~/.bashrc}}:<br />
<br />
complete -cf sudo<br />
<br />
=== Run X11 apps using sudo ===<br />
<br />
To allow sudo to start graphical application in X11, you need to add:<br />
<br />
Defaults env_keep += "HOME"<br />
<br />
to visudo.<br />
<br />
=== Disable per-terminal sudo ===<br />
<br />
{{Warning|This will let any process use your sudo session.}}<br />
<br />
If you are annoyed by sudo's defaults that require you to enter your password every time you open a new terminal, disable '''tty_tickets''':<br />
<br />
Defaults !tty_tickets<br />
<br />
=== Environment variables ===<br />
<br />
If you have a lot of environment variables, or you export your proxy settings via {{ic|1=export http_proxy="..."}}, when using sudo these variables do not get passed to the root account unless you run sudo with the {{ic|-E}} option.<br />
<br />
$ sudo -E pacman -Syu<br />
<br />
The recommended way of preserving environment variables is to append them to {{ic|env_keep}}:<br />
{{hc|/etc/sudoers|<nowiki><br />
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"<br />
</nowiki>}}<br />
<br />
=== Passing aliases ===<br />
<br />
If you use a lot of aliases, you might have noticed that they do not carry over to the root account when using sudo. However, there is an easy way to make them work. Simply add the following to your {{ic|~/.bashrc}} or {{ic|/etc/bash.bashrc}}:<br />
<br />
alias sudo='sudo '<br />
<br />
=== Insults ===<br />
<br />
Users can configure sudo to display clever insults when an incorrect password is entered instead of printing the default "wrong password" message. Find the Defaults line in {{ic|/etc/sudoers}} and append "insults" after a comma to existing options. The final result might look like this:<br />
<br />
#Defaults specification<br />
Defaults insults<br />
<br />
To test, type {{ic|sudo -K}} to end the current session and let sudo ask for the password again.<br />
<br />
=== Root password ===<br />
<br />
Users can configure sudo to ask for the root password instead of the user password by adding "rootpw" to the Defaults line in {{ic|/etc/sudoers}}:<br />
<br />
Defaults timestamp_timeout=0,rootpw<br />
<br />
=== Disable root login ===<br />
<br />
{{Warning|Arch Linux is not fine-tuned to run with a disabled root account. Users may encounter problems with this method.}}<br />
<br />
With sudo installed and configured, users may wish to disable the root login. Without root, attackers must first guess a user name configured as a sudoer as well as the user password.<br />
<br />
{{Warning|Ensure a user is properly configured as a sudoer ''before'' disabling the root account!}}<br />
<br />
The account can be locked via {{ic|passwd}}:<br />
<br />
# passwd -l root<br />
<br />
A similar command unlocks root.<br />
<br />
$ sudo passwd -u root<br />
<br />
Alternatively, edit {{ic|/etc/shadow}} and replace the root's encrypted password with "!":<br />
<br />
root:!:12345::::::<br />
<br />
To enable root login again:<br />
<br />
$ sudo passwd root<br />
<br />
==== kdesu ====<br />
<br />
kdesu may be used under KDE to launch GUI applications with root privileges. It is possible that by default kdesu will try to use su even if the root account is disabled. Fortunately one can tell kdesu to use sudo instead of su. Create/edit the file {{ic|~/.kde4/share/config/kdesurc}}:<br />
<br />
[super-user-command]<br />
super-user-command=sudo<br />
<br />
==== PolicyKit ====<br />
<br />
When disabling the root account, it is necessary to change the [[PolicyKit]] configuration for local authorization to reflect that. The default is to ask for the root password, so that must be changed. With polkit-1, this can be achieved by editing {{ic|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf}} so that {{ic|1=AdminIdentities=unix-user:0}} is replaced with something else, depending on the system configuration. It can be a list of users and groups, for example:<br />
<br />
AdminIdentities=unix-group:wheel<br />
<br />
or<br />
<br />
AdminIdentities=unix-user:me;unixuser:mom;unix-group:wheel<br />
<br />
For more information, see {{ic|man pklocalauthority}}.<br />
<br />
==== NetworkManager ====<br />
<br />
Even with the above PolicyKit configuration you still need to configure a policy for NetworkManager. This is documented on the [[NetworkManager#Can.27t_edit_connections_as_normal_user|NetworkManager]] page of this wiki.<br />
<br />
=== Harden with Sudo Example ===<br />
<br />
Lets say you create 3 users: admin, devel, and Joe<br />
admin is used for journalctl, systemctl, mount, kill, and iptables.<br />
devel is used for installing packages, and editing config's<br />
Joe is the user you log in with. Let's let him reboot, shutdown, and use netctl<br />
<br />
Edit /etc/pam.d/su and /etc/pam.d/su-1<br />
Require user be in the wheel group, but don't put anyone in it.<br />
#%PAM-1.0<br />
auth sufficient pam_rootok.so<br />
# Uncomment the following line to implicitly trust users in the "wheel" group.<br />
#auth sufficient pam_wheel.so trust use_uid<br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
auth required pam_unix.so<br />
account required pam_unix.so<br />
session required pam_unix.so<br />
<br />
Limit SSH login to the 'ssh' group, Only put Joe in it<br />
groupadd -r ssh<br />
gpasswd -a Joe ssh<br />
echo 'AllowGroups ssh' >> /etc/ssh/sshd_config<br />
systemctl restart sshd.service<br />
<br />
Lets add users to other goups.<br />
for g in network power ;do ;gpasswd -a Joe $g ;done<br />
for g in network power disk ;do ;gpasswd -a Joe $g ;done<br />
<br />
Set permissions on configs so devel can edit them.<br />
chown -R devel:root /etc/{http,openvpn,cups,zsh,vim,screenrc}<br />
<br />
Cmnd_Alias POWER = /usr/bin/shutdown -h now, /usr/bin/halt, /usr/bin/poweroff, /usr/bin/reboot<br />
Cmnd_Alias DISK = /usr/bin/mount, /usr/bin/umount<br />
Cmnd_Alias SYSTEMD = /usr/bin/journalctl, /usr/bin/systemctl<br />
Cmnd_Alias KILL = /usr/bin/kill, /usr/bin/killall<br />
Cmnd_Alias PKGMAN = /usr/bin/pacman<br />
Cmnd_Alias NETWORK = /usr/bin/netctl<br />
Cmnd_Alias FIREWALL = /usr/bin/iptables<br />
Cmnd_Alias SHELL = /usr/bin/zsh, /usr/bin/bash<br />
%power ALL = (root) NOPASSWD: POWER<br />
%network ALL = (root) NETWORK<br />
%disk ALL = (root) DISK<br />
root ALL = (ALL) ALL<br />
admin ALL = (root) SYSTEMD, KILL, FIREWALL<br />
devel ALL = (root) PKGMAN<br />
Joe ALL = (devel) SHELL, (admin) SHELL <br />
<br />
With this setup, you will almost never need to login as the Root user.<br />
<br />
Joe can connect to his home WiFi<br />
sudo netctl start home<br />
sudo poweroff<br />
<br />
Joe can not use netctl as any other user like admin...<br />
sudo -u admin -- netctl start home<br />
<br />
When Joe needs to use journalctl or kill run away process he can switch to that user<br />
sudo -i -u devel<br />
sudo -i -u admin<br />
<br />
But not Root<br />
sudo -i -u root<br />
<br />
If joe want to start a gnu-screen session as admin he can do it like this<br />
sudo -i -u admin<br />
admin% chown admin:tty `echo $TTY`<br />
admin% screen<br />
<br />
== Troubleshooting ==<br />
<br />
=== SSH TTY Issues ===<br />
<br />
SSH does not allocate a tty by default when running a remote command. Without a tty, sudo cannot disable echo when prompting for a password. You can use ssh's {{ic|-tt}} option to force it to allocate a tty (or {{ic|-t}} twice).<br />
<br />
The {{ic|Defaults}} option {{ic|requiretty}} only allows the user to run sudo if they have a tty.<br />
<br />
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear text. You have to run "ssh -t hostname sudo <cmd>".<br />
#<br />
#Defaults requiretty<br />
<br />
=== Display User Privileges ===<br />
<br />
You can find out what privileges a particular user has with the following command:<br />
<br />
$ sudo -lU yourusename<br />
<br />
Or view your own with:<br />
<br />
{{hc|$ sudo -l|<nowiki><br />
Matching Defaults entries for yourusename on this host:<br />
loglinelen=0, logfile=/var/log/sudo.log, log_year, syslog=auth, mailto=webmaster@gmail.com, mail_badpass, mail_no_user,<br />
mail_no_perms,env_reset, always_set_home, tty_tickets, lecture=always, pwfeedback, rootpw, set_home<br />
<br />
User yourusename may run the following commands on this host:<br />
<br />
(ALL) ALL<br />
(ALL) NOPASSWD: /usr/bin/lsof, /bin/nice, /usr/bin/su, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync, /usr/bin/strace,<br />
(ALL) /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
(ALL) /usr/bin/gparted, /usr/bin/pacman<br />
(ALL) /usr/local/bin/synergyc, /usr/local/bin/synergys<br />
(ALL) /usr/bin/vim, /usr/bin/nano, /usr/bin/cat<br />
(root) NOPASSWD: /usr/local/bin/synergyc</nowiki>}}<br />
<br />
=== Permissive Umask ===<br />
<br />
Sudo will union the user's [[umask]] value with its own umask (which defaults to 0022). This prevents sudo from creating files with more open permissions than the user's umask allows. While this is a sane default if no custom umask is in use, this can lead to situations where a utility run by sudo may create files with different permissions than if run by root directly. If errors arise from this, sudo provides a means to fix the umask, even if the desired umask is more permissive than the umask that the user has specified. Adding this (using {{ic|visudo}}) will override sudo's default behavior:<br />
<br />
Defaults umask = 0022<br />
Defaults umask_override<br />
<br />
This sets sudo's umask to root's default umask (0022) and overrides the default behavior, always using the indicated umask regardless of what umask the user as set.<br />
<br />
<br />
=== Defaults Skeleton ===<br />
<br />
The authors site has a [http://www.gratisoft.us/sudo/sudoers.man.html#sudoers_options list of all the options] that can be used with the {{ic|Defaults}} command in the {{ic|/etc/sudoers}} file.<br />
<br />
The full list of options ''(parsed from the version 1.8.7 source code)'' is below in a format optimized for copying and pasting into your sudoers files for quick editing.<br />
<br />
{{bc|<nowiki>#Defaults always_set_home<br />
# If enabled, sudo will set the HOME environment variable to the home directory of the target user<br />
# (which is root unless the -u option is used). This effectively means that the -H option<br />
# always_set_home is only effective for configurations where either env_reset is disabled or HOME is present<br />
# in the env_keep list. Default: OFF<br />
<br />
#Defaults authenticate<br />
# If set, users must authenticate themselves via a password (or other means of authentication)<br />
# before they may run commands. This default may be overridden via the PASSWD and NOPASSWD<br />
<br />
#Defaults closefrom_override<br />
# If set, the user may use sudo's -C option which overrides the default starting<br />
# point at which sudo begins closing open file descriptors. Default: OFF<br />
<br />
#Defaults compress_io<br />
# If set, and sudo is configured to log a command's input or output, the I/O logs will be<br />
# compressed using zlib. This flag is on by default when sudo is compiled with zlib support.<br />
<br />
#Defaults env_editor<br />
# If set, visudo will use the value of the EDITOR or VISUAL environment variables before falling back on the default<br />
# editor list. Note that this may create a security hole as it allows th separated list of editors in the editor<br />
# variable. visudo will then only use the EDITOR or VISUAL if they match a value specified in editor. On by default.<br />
<br />
#Defaults env_reset<br />
# If set, sudo will run the command in a minimal environment containing the TERM, PATH, HOME, MAIL, SHELL, LOGNAME,<br />
# USER, USERNAME and SUDO_* variables. Any variables in the caller's env in the file specified by the env_file<br />
# option (if any). The default contents of the env_keep and env_check lists are displayed when sudo is run by<br />
# root with the -V option.<br />
<br />
#Defaults fast_glob<br />
# Normally, sudo uses the glob(3) function to do shell-style globbing when matching path names.<br />
# However, since it accesses the file system, glob(3) can take a long time to complete for som (automounted).<br />
# The fast_glob option causes sudo to use the fnmatch(3) function, which does not access the file system to do<br />
# its matching. The disadvantage of fast_glob is that it is unable to ma names that include globbing characters<br />
# are used with the negation operator, '!', as such rules can be trivially bypassed. As such, this option should<br />
# not be used when sudoers contains rules that<br />
<br />
#Defaults fqdn<br />
# Set this flag if you want to put fully qualified host names in the sudoers file. I.e., instead of myhost you<br />
# would use myhost.mydomain.edu. You may still use the short form if you wish (and sudo unusable if DNS stops<br />
# working (for example if the machine is not plugged into the network). Also note that you must use the<br />
# host's official name as DNS knows it. That is, you may not use a all aliases from DNS. If your machine's<br />
# host name (as returned by the hostname command) is already fully qualified you shouldn't need to set fqdn.<br />
# Default: OFF<br />
<br />
#Defaults ignore_dot<br />
# If set, sudo will ignore '.' or '' (current dir) in the PATH environment variable; the PATH<br />
# itself is not modified. Default: OFF<br />
<br />
#Defaults ignore_local_sudoers<br />
# If set via LDAP, parsing of /etc/sudoers will be skipped. This is intended for Enterprises that wish to prevent<br />
# the usage of local sudoers files so that only LDAP is used. /etc/sudoers does not even need to exist.<br />
# Since this option tells sudo how to behave when no specific LDAP entries have been matched, this sudo<br />
# Option is only meaningful for the cn=default<br />
<br />
#Defaults insults<br />
# If set, sudo will insult users when they enter an incorrect password. Default: OFF<br />
<br />
#Defaults log_host<br />
# If set, the host name will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults log_input<br />
# If set, sudo will run the command in a pseudo tty and log all user input. If the standard<br />
# input is not connected to the user's tty, due to I/O redirection or because the command is part Input is logged<br />
# to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that<br />
# is included in the normal sudo log line, prefixed with TSID=. Note that user input may contain sensitive<br />
# information such as passwords (even if they are not echoed to the screen), which will be stored in the log file<br />
# unencrypted.<br />
<br />
#Defaults log_output<br />
# If set, sudo will run the command in a pseudo tty and log all output that is sent to the<br />
# screen, similar to the script(1) command. If the standard output or standard error is not connec is also captured and<br />
# stored in separate log files. Output is logged to the directory specified by the iolog_dir option (/var/log/sudo-io<br />
# by default) using a unique session ID that is included in the normal sudo log line, prefixed with TSID=. The Output<br />
# logs may be viewed with the sudoreplay(8) utility, which can also be used to list or search the available logs.<br />
<br />
#Defaults log_year<br />
# If set, the four-digit year will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults long_otp_prompt<br />
# When validating with a One Time Password (OTP) scheme such as S/Key or OPIE, a two-line<br />
# prompt is used to make it easier to cut and paste the challenge to a local window<br />
<br />
#Defaults mail_always<br />
# Send mail to the mailto user every time a users runs sudo. Default: OFF<br />
<br />
#Defaults mail_badpass<br />
# Send mail to the mailto user if the user running sudo does not enter the correct password.<br />
# Default: OFF<br />
<br />
#Defaults mail_no_host<br />
# If set, mail will be sent to the mailto user if the invoking user exists in the sudoers<br />
# file, but is not allowed to run commands on the current host. Default: OFF<br />
<br />
#Defaults mail_no_perms<br />
# If set, mail will be sent to the mailto user if the invoking user is allowed to use sudo<br />
# but the command they are trying is not listed in their sudoers file entry or is explicitly denied<br />
<br />
#Defaults mail_no_user<br />
# If set, mail will be sent to the mailto user if the invoking user is not in the sudoers file.<br />
# Default: ON<br />
<br />
#Defaults noexec<br />
# If set, all commands run via sudo will behave as if the NOEXEC tag has been set, unless overridden<br />
# by a EXEC tag. See the description of NOEXEC and EXEC below as well as the "PREVENTING SHE<br />
<br />
#Defaults path_info<br />
# Normally, sudo will tell the user when a command could not be found in their PATH environment<br />
# variable. Some sites may wish to disable this as it could be used to gather information on t the executable is<br />
# simply not in the user's PATH, sudo will tell the user that they are not allowed to run it, which can be confusing.<br />
# Default: ON<br />
<br />
#Defaults passprompt_override<br />
# The password prompt specified by passprompt will normally only be used if the password prompt provided by<br />
# systems such as PAM matches the string "Password:"<br />
<br />
#Defaults preserve_groups<br />
# By default, sudo will initialize the group vector to the list of groups the target<br />
# user is in. When preserve_groups is set, the user's existing group vector is left unaltered.<br />
<br />
#Defaults pwfeedback<br />
# By default, sudo reads the password like most other Unix programs, by turning off echo<br />
# until the user hits the return (or enter) key. Some users become confused by this as it appears to the user<br />
# presses a key. Note that this does have a security impact as an onlooker may be able to determine the length of<br />
# the password being entered. Default: OFF<br />
<br />
#Defaults requiretty<br />
# If set, sudo will only run when the user is logged in to a real tty. When this flag is set,<br />
# sudo can only be run from a login session and not via other means such as cron(8) or cgi-bin<br />
<br />
#Defaults root_sudo<br />
# If set, root is allowed to run sudo too. Disabling this prevents users from "chaining" sudo<br />
# commands to get a root shell by doing something like "sudo sudo /bin/sh". Note, however, that real additional<br />
# security; it exists purely for historical reasons. Default: ON<br />
<br />
#Defaults rootpw<br />
# If set, sudo will prompt for the root password instead of the password of the invoking user.<br />
# Default: OFF<br />
<br />
#Defaults runaspw<br />
# If set, sudo will prompt for the password of the user defined by the runas_default option<br />
# (defaults to root) instead of the password of the invoking user. Default: OFF<br />
<br />
#Defaults set_home<br />
# If enabled and sudo is invoked with the -s option the HOME environment variable will be set<br />
# to the home directory of the target user (which is root unless the -u option is used). So set_home is only<br />
# effective for configs where either env_reset is disabled or HOME is present in the env_keep list. Default: OFF<br />
<br />
#Defaults set_logname<br />
# Normally, sudo will set the LOGNAME, USER and USERNAME environment variables to the name<br />
# of the target user (usually root unless the -u option is given). However, since some programs ( may be desirable<br />
# to change this behavior. This can be done by negating the set_logname option. Note that if the env_reset option<br />
# has not been disabled, entries in the env_keep list will override<br />
<br />
#Defaults set_utmp<br />
# When enabled, sudo will create an entry in the utmp (or utmpx) file when a pseudo-tty is<br />
# allocated. A pseudo-tty is allocated by sudo when the log_input, log_output or use_pty flags are e the tty, time,<br />
# type and pid fields updated. Default: ON<br />
<br />
#Defaults setenv<br />
# Allow the user to disable the env_reset option from the command line via the -E option.<br />
# Additionally, environment variables set via the command line are not subject to the restrictions impo variables<br />
# in this manner. Default: OFF<br />
<br />
#Defaults shell_noargs<br />
# If set and sudo is invoked with no arguments it acts as if the -s option had been given.<br />
# That is, it runs a shell as root (the shell is determined by the SHELL environment variable if is off by default.<br />
<br />
#Defaults stay_setuid<br />
# Normally, when sudo executes a command the real and effective UIDs are set to the target<br />
# user (root by default). This option changes that behaviour such that the real UID is left as the systems that<br />
# disable some potentially dangerous functionality when a program is run setuid. This option is only effective on<br />
# systems with either the setreuid() or setresuid() function. This flag<br />
<br />
#Defaults targetpw<br />
# If set, sudo will prompt for the password of the user specified by the -u option (defaults to root) instead<br />
# of the password of the invoking user. In addition, the timestamp file name will passwd database as an argument<br />
# to the -u option. Default: OFF<br />
<br />
#Defaults tty_tickets<br />
# If set, users must authenticate on a per-tty basis. With this flag enabled, sudo will<br />
# use a file named for the tty the user is logged in on in the user's time stamp directory.<br />
<br />
#Defaults umask_override<br />
# If set, sudo will set the umask as specified by sudoers without modification. This makes<br />
# it possible to specify a more permissive umask in sudoers than the user's own umask and match user's umask and what<br />
# is specified in sudoers. Default: OFF<br />
<br />
#Defaults use_pty<br />
# If set, sudo will run the command in a pseudo-pty even if no I/O logging is being gone.<br />
# A malicious program run under sudo could conceivably fork a background process that retains to the u that impossible.<br />
# Default: OFF<br />
<br />
#Defaults utmp_runas<br />
# If set, sudo will store the name of the runas user when updating the utmp (or utmpx) file.<br />
# By default, sudo stores the name of the invoking user. Default: OFF<br />
<br />
#Defaults visiblepw<br />
# By default, sudo will refuse to run if the user must enter a password but it is not possible to disable echo on the <br />
# terminal. If the visiblepw flag is set, sudo will prompt for a password even when it would be visible on the screen. <br />
# This makes it possible to run things like "rsh somehost sudo ls" since rsh(1) does not allocate a tty. Default: OFF<br />
<br />
#Defaults closefrom<br />
# Before it executes a command, sudo will close all open file descriptors other than standard<br />
# input, standard output and standard error (ie: file descriptors 0-2).<br />
<br />
#Defaults passwd_tries<br />
# The number of tries a user gets to enter his/her password before sudo logs the failure<br />
# and exits. The default is 3.<br />
<br />
#Defaults loglinelen<br />
# Number of characters per line for the file log. This value is used to decide when to wrap<br />
# lines for nicer log files. This has no effect on the syslog log file, only the file log.<br />
<br />
#Defaults passwd_timeout<br />
# Number of minutes before the sudo password prompt times out, or 0 for no timeout.<br />
# The timeout may include a fractional component if minute granularity is insufficient, for example 2<br />
<br />
#Defaults timestamp_timeout<br />
# Number of minutes that can elapse before sudo will ask for a passwd again. The timeout<br />
# may include a fractional component if minute granularity is insufficient, for example 2.5. timestamp will never expire.<br />
# This can be used to allow users to create or delete their own timestamps via sudo -v and sudo -k respectively.<br />
<br />
#Defaults umask<br />
# Umask to use when running the command. Negate this option or set it to 0777 to preserve<br />
# the user's umask. The actual umask that is used will be the union of the user's umask and the value o running<br />
# a command. Note on systems that use PAM, the default PAM configuration may specify its own umask which will<br />
# override the value set in sudoers.<br />
<br />
#Defaults badpass_message<br />
# Message that is displayed if a user enters an incorrect password. The default is Sorry,<br />
# try again. unless insults are enabled.<br />
<br />
#Defaults editor<br />
# A colon (':') separated list of editors allowed to be used with visudo. visudo will choose<br />
# the editor that matches the user's EDITOR environment variable if possible, or the first editor in<br />
<br />
#Defaults iolog_dir<br />
# The top-level directory to use when constructing the path name for the input/output log<br />
# directory. Only used if the log_input or log_output options are enabled or when the LOG_INPUT or L directory.<br />
# The default is "/var/log/sudo-io". The following percent (%) escape sequences are supported:<br />
# %{seq} - expanded to base-36 sequence number, such as 0100A5, to form a new directory, e.g. 01/00/A5<br />
# %{user} - expanded to the invoking user's login name<br />
# %{group} - expanded to the name of the invoking user's real group ID<br />
# %{runas_user} - expanded to the login name of the user the command will be run as (e.g. root)<br />
# %{runas_group} - expanded to the group name of the user the command will be run as (e.g. wheel)<br />
# %{hostname} - expanded to the local host name without the domain name<br />
# %{command} - expanded to the base name of the command being run In addition, any escape sequences supported by<br />
# strftime() function will be expanded. To include a literal % character, the string %% should be used.<br />
<br />
#Defaults iolog_file<br />
# The path name, relative to iolog_dir, in which to store input/output logs when the log_input or log_output options are<br />
# enabled or when the LOG_INPUT or LOG_OUTPUT tags are present for a See the iolog_dir option above for a list of<br />
# supported percent (%) escape sequences. In addition to the escape sequences, path names that end in six or more Xs will<br />
# have the Xs replaced with a unique combination of digits and letters, similar to the mktemp() function.<br />
<br />
#Defaults mailsub<br />
# Subject of the mail sent to the mailto user. The escape %h will expand to the host name of<br />
# the machine. Default is *** SECURITY information for %h ***.<br />
<br />
#Defaults noexec_file<br />
# This option is no longer supported. The path to the noexec file should now be set in the /etc/sudo.conf file.<br />
<br />
#Defaults passprompt<br />
# The default prompt to use when asking for a password; can be overridden via the -p option or the SUDO_PROMPT<br />
# environment variable. The following percent (%) escape sequences are supported:<br />
# %H - expanded to the local host name including the domain (only if the host name is fqdn or fqdn option is set)<br />
# %h - expanded to the local host name without the domain name<br />
# %p - expanded to the user whose password is being asked for (respects the rootpw, targetpw and runaspw flags)<br />
# %U - expanded to the login name of the user the command will be run as (defaults to root)<br />
# %u - expanded to the invoking user's login name<br />
# %% - two consecutive % characters are collapsed into a single % character<br />
# The default value is Password:.<br />
<br />
#Defaults runas_default<br />
# The default user to run commands as if the -u option is not specified on the command line. This defaults to root.<br />
<br />
#Defaults syslog_badpri<br />
# Syslog priority to use when user authenticates unsuccessfully. Defaults to alert.<br />
# alert, crit, debug, emerg, err, info, notice, and warning.<br />
<br />
#Defaults syslog_goodpri<br />
# Syslog priority to use when user authenticates successfully. Defaults to notice. See syslog_badpri for the priorities.<br />
<br />
#Defaults sudoers_locale<br />
# Locale to use when parsing the sudoers file, logging commands, and sending email.<br />
# Note that changing the locale may affect how sudoers is interpreted. Defaults to "C".<br />
<br />
#Defaults timestampdir<br />
# The directory in which sudo stores its timestamp files. The default is /var/db/sudo.<br />
<br />
#Defaults timestampowner<br />
# The owner of the timestamp directory and the timestamps stored therein. The default is root.<br />
<br />
#Defaults env_file<br />
# The env_file option specifies the fully qualified path to a file containing variables to<br />
# be set in the environment of the program being run. Entries in this file should either be of the f quotes.<br />
# Variables in this file are subject to other sudo environment settings such as env_keep and env_check.<br />
<br />
#Defaults exempt_group<br />
# Users in this group are exempt from password and PATH requirements. The group name specified should not include<br />
# a % prefix. This is not set by default.<br />
<br />
#Defaults group_plugin<br />
# A string containing a sudoers group plugin with optional arguments. This can be used to implement support for the<br />
# nonunix_group syntax described earlier. The string should consist of configuration arguments the plugin requires.<br />
# These arguments (if any) will be passed to the plugin's initialization function. If arguments are present, the<br />
# string must be enclosed in double quote For example, given /etc/sudo-group, a group file in Unix group format,<br />
# the sample group plugin can be used: Defaults group_plugin="sample_group.so /etc/sudo-group"<br />
# For more information see sudo_plugin(5).<br />
<br />
#Defaults lecture<br />
# This option controls when a short lecture will be printed along with the password prompt. The default value is once.<br />
# It has the following possible values:<br />
# always - Always lecture the user.<br />
# never - Never lecture the user.<br />
# once - Only lecture the user the first time they run sudo.<br />
# If no value is specified, a value of once is implied. Negating the option results in a value of never being used.<br />
<br />
#Defaults lecture_file<br />
# Path to a file containing an alternate sudo lecture that will be used in place of the standard lecture if the named<br />
# file exists. By default, sudo uses a built-in lecture.<br />
<br />
#Defaults listpw<br />
# This option controls when a password will be required when a user runs sudo with the -l option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD set to avoid entering a pass.<br />
# always - The user must always enter a password to use the -l option.<br />
# any - At least one of the user's sudoers entries for the current host must have the NOPASSWD set to avoid pass.<br />
# never - The user need never enter a password to use the -l option.<br />
# If no value is specified, a value of any is implied. The default value is any.<br />
<br />
#Defaults logfile<br />
# Path to the sudo log file (not the syslog log file). Setting a path turns on logging to a file;<br />
# negating this option turns it off. By default, sudo logs via syslog.<br />
<br />
#Defaults mailerflags<br />
# Flags to use when invoking mailer. Defaults to -t.<br />
<br />
#Defaults mailerpath<br />
# Path to mail program used to send warning mail. Defaults to the path to sendmail found at configure time.<br />
<br />
#Defaults mailfrom<br />
# Address to use for the "from" address when sending warning and error mail. The address should<br />
# be enclosed in double quotes (") to protect against sudo interpreting the @ sign.<br />
<br />
#Defaults mailto<br />
# Address to send warning and error mail to. The address should be enclosed in double quotes<br />
# (") to protect against sudo interpreting the @ sign. Defaults to root.<br />
<br />
#Defaults secure_path<br />
# Path used for every command run from sudo. If you don't trust the people running sudo to have a sane PATH environment<br />
# variable you may want to use this. Another use is if you want to option are not affected by secure_path.<br />
# This option is not set by default.<br />
<br />
#Defaults syslog<br />
# Syslog facility if syslog is being used for logging (negate to disable syslog logging). Defaults to auth.<br />
# authpriv (if OS supports it), auth, daemon, user, local0, local1, local2, local3, local4, local5, local6, and local7.<br />
<br />
#Defaults verifypw<br />
# This option controls when a password will be required when a user runs sudo with the -v option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD flag to avoid pw.<br />
# always - The user must always enter a password to use the -v option.<br />
# any - At least one of the user's sudoers entries for the current host must have NOPASSWD to avoid pw.<br />
# never - The user need never enter a password to use the -v option<br />
# If no value is specified, a value of all is implied. Negating the option results in a value of never being used.<br />
# The default value is all.<br />
<br />
#Defaults env_check<br />
# Environment variables to be removed from the user's environment if the variable's value contains % or / characters.<br />
# This can be used to guard against printf-style format vulnerabilities value without double-quotes. The list can be<br />
# replaced, added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively. Regardless of<br />
# whether the env_reset option is ena they pass the aforementioned check. The default list of environment variables<br />
# to check is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_delete<br />
# Environment variables to be removed from the user's environment when the env_reset option is not in effect. The<br />
# argument may be a double-quoted, space-separated list or a single value w +=, -=, and ! operators respectively.<br />
# The default list of environment variables to remove is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_keep<br />
# Environment variables to be preserved in the user's environment when the env_reset option is in effect. This<br />
# allows fine-grained control over the environment sudo-spawned processes will r quotes. The list can be replaced,<br />
# added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively.</nowiki>}}</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Sudo&diff=281641Sudo2013-11-06T03:13:48Z<p>Hunterthomson: /* Harden with Sudo Example */ mached rules with stated objectives</p>
<hr />
<div>[[Category:Security]]<br />
[[cs:Sudo]]<br />
[[es:Sudo]]<br />
[[fr:Sudo]]<br />
[[it:Sudo]]<br />
[[ja:Sudo]]<br />
[[ru:Sudo]]<br />
[[sr:Sudo]]<br />
[[tr:Sudo]]<br />
[[uk:Sudo]]<br />
[[zh-CN:Sudo]]<br />
{{Article summary start}}<br />
{{Article summary text|An overview of the popular privilege escalation utility.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Access control overview}}}}<br />
{{Article summary end}}<br />
<br />
[http://www.gratisoft.us/sudo/ sudo] ("substitute user do") allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments.<br />
<br />
== Rationale ==<br />
<br />
Sudo is an alternative to [[su]] for running commands as root. Unlike [[su]], which launches a root shell that allows all further commands root access, sudo instead grants temporary privilege escalation to a single command. By enabling root privileges only when needed, sudo usage reduces the likelyhood that a typo or a bug in an invoked command will ruin the system.<br />
Sudo can also be used to run commands as other users; additionally, sudo logs all commands and failed access attempts for security auditing.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|sudo}} package, available in the [[Official Repositories|official repositories]]:<br />
<br />
# pacman -S sudo<br />
<br />
To begin using {{ic|sudo}} as a non-privileged user, it must be properly configured. So make sure you read the configuration section.<br />
<br />
== Usage ==<br />
<br />
With sudo, users can prefix commands with {{ic|sudo}} to run them with superuser (or other) privileges.<br />
<br />
For example, to use pacman:<br />
<br />
$ sudo pacman -Syu<br />
<br />
See the [http://www.gratisoft.us/sudo/man/sudo.html sudo manual] for more information.<br />
<br />
== Configuration ==<br />
<br />
=== View current settings ===<br />
<br />
Run {{ic|sudo -ll}} to print out the current sudo configuration.<br />
<br />
=== Using visudo ===<br />
<br />
The configuration file for sudo is {{ic|/etc/sudoers}}. It should '''always''' be edited with the {{ic|visudo}} command. {{ic|visudo}} locks the {{ic|sudoers}} file, saves edits to a temporary file, and checks that file's grammar before copying it to {{ic|/etc/sudoers}}.<br />
<br />
{{Warning|It is imperative that {{ic|sudoers}} be free of syntax errors! Any error makes sudo unusable. '''Always''' edit it with {{ic|visudo}} to prevent errors.}}<br />
<br />
The default editor for visudo is {{ic|vi}}. It will be used if you do not specify another editor, by setting either VISUAL or EDITOR environment variables (used in that order) to the desired editor, e.g. {{ic|nano}}. The command is run as root:<br />
<br />
# EDITOR=nano visudo<br />
<br />
You can permanently change the setting for your user to e.g. {{ic|nano}} by appending:<br />
<br />
export EDITOR=nano<br />
<br />
to your {{ic|~/.bashrc}} file. Note that this won't take effect for already-running shells.<br />
<br />
To change the editor of choice permanently system-wide only for {{ic|visudo}}, add the following line to {{ic|/etc/sudoers}} where {{ic|nano}} is your prefered editor:<br />
<br />
# Reset environment by default<br />
Defaults env_reset<br />
# Set default EDITOR to nano, and do not allow visudo to use EDITOR/VISUAL.<br />
Defaults editor=/usr/bin/nano, !env_editor<br />
<br />
=== Example Entries ===<br />
<br />
To allow a user to gain full root privileges when he/she precedes a command with {{ic|sudo}}, add the following line:<br />
<br />
USER_NAME ALL=(ALL) ALL<br />
<br />
To allow a user to run all commands as any user but only the machine with hostname HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=(ALL) ALL<br />
<br />
To allow members of group {{ic|wheel}} sudo access:<br />
<br />
%wheel ALL=(ALL) ALL<br />
<br />
To disable asking for a password for user USER_NAME:<br />
<br />
Defaults:USER_NAME !authenticate<br />
<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=/usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
{{note| the most customized option should go at the end of the file, as the later lines overrides the previous ones. In particular such a line should be after the {{ic|%wheel}} line if your user is in this group.}}<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME without password:<br />
USER_NAME HOST_NAME= NOPASSWD: /usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
<br />
A detailed sudoers example can be found [http://www.gratisoft.us/sudo/sample.sudoers here]. Otherwise, see the [http://www.gratisoft.us/sudo/man/sudoers.html sudoers manual] for detailed information.<br />
<br />
=== Sudoers default file permissions ===<br />
<br />
The owner and group for the sudoers file must both be 0. The file permissions must be set to 0440. These permissions are set by default, but if you accidentally change them, they should be changed back immediately or sudo will fail.<br />
<br />
# chown -c root:root /etc/sudoers<br />
# chmod -c 0440 /etc/sudoers<br />
<br />
=== Password cache timeout ===<br />
<br />
Users may wish to change the default timeout before the cached password expires. This is accomplished with the timestamp_timeout option in {{ic|/etc/sudoers}} which is in minutes.<br />
Set timeout to 20 minutes.<br />
<br />
Defaults:USER_NAME timestamp_timeout=20<br />
<br />
{{Tip|To ensure sudo always asks for a password, set the timeout to 0. To ensure the password never times out, set to less than 0.}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== File example ===<br />
<br />
This example is especially helpful for those using terminal multiplexers like screen, tmux, or ratpoison, and those using sudo from scripts/cronjobs:<br />
<br />
{{hc|/etc/sudoers|<nowiki><br />
Cmnd_Alias WHEELER = /usr/bin/lsof, /bin/nice, /bin/ps, /usr/bin/top, /usr/local/bin/nano, /usr/bin/ss, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync<br />
Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/kill, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
Cmnd_Alias EDITS = /usr/bin/vim, /usr/bin/nano, /usr/bin/cat, /usr/bin/vi<br />
Cmnd_Alias ARCHLINUX = /usr/bin/gparted, /usr/bin/pacman<br />
<br />
root ALL = (ALL) ALL<br />
USER_NAME ALL = (ALL) ALL, NOPASSWD: WHEELER, NOPASSWD: PROCESSES, NOPASSWD: ARCHLINUX, NOPASSWD: EDITS<br />
<br />
Defaults !requiretty, !tty_tickets, !umask<br />
Defaults visiblepw, path_info, insults, lecture=always<br />
Defaults loglinelen = 0, logfile =/var/log/sudo.log, log_year, log_host, syslog=auth<br />
Defaults mailto=webmaster@foobar.com, mail_badpass, mail_no_user, mail_no_perms<br />
Defaults passwd_tries = 8, passwd_timeout = 1<br />
Defaults env_reset, always_set_home, set_home, set_logname<br />
Defaults !env_editor, editor="/usr/bin/vim:/usr/bin/vi:/usr/bin/nano"<br />
Defaults timestamp_timeout=360<br />
Defaults passprompt="Sudo invoked by [%u] on [%H] - Cmd run as %U - Password for user %p:"<br />
</nowiki>}}<br />
<br />
=== Enabling Tab-completion in Bash ===<br />
<br />
{{ic|Tab}}-completion, by default, will not work when a user is initially added to the sudoers file. For example, normally john only needs to type:<br />
<br />
$ fire<{{ic|Tab}}><br />
<br />
and the shell will complete the command for him as:<br />
<br />
$ firefox<br />
<br />
If, however, john is added to the sudoers file and he types:<br />
<br />
$ sudo fire<{{ic|Tab}}><br />
<br />
the shell will do nothing.<br />
<br />
To enable {{ic|Tab}}-completion with sudo, [[pacman|install]] the {{pkg|bash-completion}} package from the [[Official Repositories|official repositories]]. see [[bash#Tab_completion]] for more information.<br />
<br />
Alternatively, add the following to your {{ic|~/.bashrc}}:<br />
<br />
complete -cf sudo<br />
<br />
=== Run X11 apps using sudo ===<br />
<br />
To allow sudo to start graphical application in X11, you need to add:<br />
<br />
Defaults env_keep += "HOME"<br />
<br />
to visudo.<br />
<br />
=== Disable per-terminal sudo ===<br />
<br />
{{Warning|This will let any process use your sudo session.}}<br />
<br />
If you are annoyed by sudo's defaults that require you to enter your password every time you open a new terminal, disable '''tty_tickets''':<br />
<br />
Defaults !tty_tickets<br />
<br />
=== Environment variables ===<br />
<br />
If you have a lot of environment variables, or you export your proxy settings via {{ic|1=export http_proxy="..."}}, when using sudo these variables do not get passed to the root account unless you run sudo with the {{ic|-E}} option.<br />
<br />
$ sudo -E pacman -Syu<br />
<br />
The recommended way of preserving environment variables is to append them to {{ic|env_keep}}:<br />
{{hc|/etc/sudoers|<nowiki><br />
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"<br />
</nowiki>}}<br />
<br />
=== Passing aliases ===<br />
<br />
If you use a lot of aliases, you might have noticed that they do not carry over to the root account when using sudo. However, there is an easy way to make them work. Simply add the following to your {{ic|~/.bashrc}} or {{ic|/etc/bash.bashrc}}:<br />
<br />
alias sudo='sudo '<br />
<br />
=== Insults ===<br />
<br />
Users can configure sudo to display clever insults when an incorrect password is entered instead of printing the default "wrong password" message. Find the Defaults line in {{ic|/etc/sudoers}} and append "insults" after a comma to existing options. The final result might look like this:<br />
<br />
#Defaults specification<br />
Defaults insults<br />
<br />
To test, type {{ic|sudo -K}} to end the current session and let sudo ask for the password again.<br />
<br />
=== Root password ===<br />
<br />
Users can configure sudo to ask for the root password instead of the user password by adding "rootpw" to the Defaults line in {{ic|/etc/sudoers}}:<br />
<br />
Defaults timestamp_timeout=0,rootpw<br />
<br />
=== Disable root login ===<br />
<br />
{{Warning|Arch Linux is not fine-tuned to run with a disabled root account. Users may encounter problems with this method.}}<br />
<br />
With sudo installed and configured, users may wish to disable the root login. Without root, attackers must first guess a user name configured as a sudoer as well as the user password.<br />
<br />
{{Warning|Ensure a user is properly configured as a sudoer ''before'' disabling the root account!}}<br />
<br />
The account can be locked via {{ic|passwd}}:<br />
<br />
# passwd -l root<br />
<br />
A similar command unlocks root.<br />
<br />
$ sudo passwd -u root<br />
<br />
Alternatively, edit {{ic|/etc/shadow}} and replace the root's encrypted password with "!":<br />
<br />
root:!:12345::::::<br />
<br />
To enable root login again:<br />
<br />
$ sudo passwd root<br />
<br />
==== kdesu ====<br />
<br />
kdesu may be used under KDE to launch GUI applications with root privileges. It is possible that by default kdesu will try to use su even if the root account is disabled. Fortunately one can tell kdesu to use sudo instead of su. Create/edit the file {{ic|~/.kde4/share/config/kdesurc}}:<br />
<br />
[super-user-command]<br />
super-user-command=sudo<br />
<br />
==== PolicyKit ====<br />
<br />
When disabling the root account, it is necessary to change the [[PolicyKit]] configuration for local authorization to reflect that. The default is to ask for the root password, so that must be changed. With polkit-1, this can be achieved by editing {{ic|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf}} so that {{ic|1=AdminIdentities=unix-user:0}} is replaced with something else, depending on the system configuration. It can be a list of users and groups, for example:<br />
<br />
AdminIdentities=unix-group:wheel<br />
<br />
or<br />
<br />
AdminIdentities=unix-user:me;unixuser:mom;unix-group:wheel<br />
<br />
For more information, see {{ic|man pklocalauthority}}.<br />
<br />
==== NetworkManager ====<br />
<br />
Even with the above PolicyKit configuration you still need to configure a policy for NetworkManager. This is documented on the [[NetworkManager#Can.27t_edit_connections_as_normal_user|NetworkManager]] page of this wiki.<br />
<br />
=== Harden with Sudo Example ===<br />
<br />
Lets say you create 3 users: admin, devel, and Joe<br />
admin is used for journalctl, systemctl, mount, kill, and iptables.<br />
devel is used for installing packages, and editing config's<br />
Joe is the user you log in with. Let's let him reboot, shutdown, and use netctl<br />
<br />
Edit /etc/pam.d/su and /etc/pam.d/su-1<br />
Require user be in the wheel group, but don't put anyone in it.<br />
#%PAM-1.0<br />
auth sufficient pam_rootok.so<br />
# Uncomment the following line to implicitly trust users in the "wheel" group.<br />
#auth sufficient pam_wheel.so trust use_uid<br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
auth required pam_unix.so<br />
account required pam_unix.so<br />
session required pam_unix.so<br />
<br />
Limit SSH login to the 'ssh' group, Only put Joe in it<br />
groupadd -r ssh<br />
gpasswd -a Joe ssh<br />
echo 'AllowGroups ssh' >> /etc/ssh/sshd_config<br />
systemctl restart sshd.service<br />
<br />
Lets add users to other goups.<br />
for g in network power ;do ;gpasswd -a Joe $g ;done<br />
for g in network power disk ;do ;gpasswd -a Joe $g ;done<br />
<br />
Set permissions on configs so devel can edit them.<br />
chown -R devel:root /etc/{http,openvpn,cups,zsh,vim,screenrc}<br />
<br />
Cmnd_Alias POWER = /usr/bin/shutdown -h now, /usr/bin/halt, /usr/bin/poweroff, /usr/bin/reboot<br />
Cmnd_Alias DISK = /usr/bin/mount, /usr/bin/umount<br />
Cmnd_Alias SYSTEMD = /usr/bin/journalctl, /usr/bin/systemctl<br />
Cmnd_Alias KILL = /usr/bin/kill, /usr/bin/killall<br />
Cmnd_Alias PKGMAN = /usr/bin/pacman<br />
Cmnd_Alias NETWORK = /usr/bin/netctl<br />
Cmnd_Alias FIREWALL = /usr/bin/iptables<br />
Cmnd_Alias SHELL = /usr/bin/zsh, /usr/bin/bash<br />
%power ALL = (root) NOPASSWD: POWER<br />
%network ALL = (root) NETWORK<br />
%disk ALL = (root) DISK<br />
root ALL = (ALL) ALL<br />
admin ALL = (root) SYSTEMD, KILL, FIREWALL<br />
devel ALL = (root) PKGMAN<br />
Joe ALL = (devel) SHELL, (admin) SU_DEVEL <br />
<br />
With this setup, you will almost never need to login as the Root user.<br />
<br />
Joe can connect to his home WiFi<br />
sudo netctl start home<br />
sudo poweroff<br />
<br />
Joe can not use netctl as any other user like admin...<br />
sudo -u admin -- netctl start home<br />
<br />
When Joe needs to use journalctl or kill run away process he can switch to that user<br />
sudo -i -u devel<br />
sudo -i -u admin<br />
<br />
But not Root<br />
sudo -i -u root<br />
<br />
If joe want to start a gnu-screen session as admin he can do it like this<br />
sudo -i -u admin<br />
admin% chown admin:tty `echo $TTY`<br />
admin% screen<br />
<br />
== Troubleshooting ==<br />
<br />
=== SSH TTY Issues ===<br />
<br />
SSH does not allocate a tty by default when running a remote command. Without a tty, sudo cannot disable echo when prompting for a password. You can use ssh's {{ic|-tt}} option to force it to allocate a tty (or {{ic|-t}} twice).<br />
<br />
The {{ic|Defaults}} option {{ic|requiretty}} only allows the user to run sudo if they have a tty.<br />
<br />
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear text. You have to run "ssh -t hostname sudo <cmd>".<br />
#<br />
#Defaults requiretty<br />
<br />
=== Display User Privileges ===<br />
<br />
You can find out what privileges a particular user has with the following command:<br />
<br />
$ sudo -lU yourusename<br />
<br />
Or view your own with:<br />
<br />
{{hc|$ sudo -l|<nowiki><br />
Matching Defaults entries for yourusename on this host:<br />
loglinelen=0, logfile=/var/log/sudo.log, log_year, syslog=auth, mailto=webmaster@gmail.com, mail_badpass, mail_no_user,<br />
mail_no_perms,env_reset, always_set_home, tty_tickets, lecture=always, pwfeedback, rootpw, set_home<br />
<br />
User yourusename may run the following commands on this host:<br />
<br />
(ALL) ALL<br />
(ALL) NOPASSWD: /usr/bin/lsof, /bin/nice, /usr/bin/su, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync, /usr/bin/strace,<br />
(ALL) /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
(ALL) /usr/bin/gparted, /usr/bin/pacman<br />
(ALL) /usr/local/bin/synergyc, /usr/local/bin/synergys<br />
(ALL) /usr/bin/vim, /usr/bin/nano, /usr/bin/cat<br />
(root) NOPASSWD: /usr/local/bin/synergyc</nowiki>}}<br />
<br />
=== Permissive Umask ===<br />
<br />
Sudo will union the user's [[umask]] value with its own umask (which defaults to 0022). This prevents sudo from creating files with more open permissions than the user's umask allows. While this is a sane default if no custom umask is in use, this can lead to situations where a utility run by sudo may create files with different permissions than if run by root directly. If errors arise from this, sudo provides a means to fix the umask, even if the desired umask is more permissive than the umask that the user has specified. Adding this (using {{ic|visudo}}) will override sudo's default behavior:<br />
<br />
Defaults umask = 0022<br />
Defaults umask_override<br />
<br />
This sets sudo's umask to root's default umask (0022) and overrides the default behavior, always using the indicated umask regardless of what umask the user as set.<br />
<br />
<br />
=== Defaults Skeleton ===<br />
<br />
The authors site has a [http://www.gratisoft.us/sudo/sudoers.man.html#sudoers_options list of all the options] that can be used with the {{ic|Defaults}} command in the {{ic|/etc/sudoers}} file.<br />
<br />
The full list of options ''(parsed from the version 1.8.7 source code)'' is below in a format optimized for copying and pasting into your sudoers files for quick editing.<br />
<br />
{{bc|<nowiki>#Defaults always_set_home<br />
# If enabled, sudo will set the HOME environment variable to the home directory of the target user<br />
# (which is root unless the -u option is used). This effectively means that the -H option<br />
# always_set_home is only effective for configurations where either env_reset is disabled or HOME is present<br />
# in the env_keep list. Default: OFF<br />
<br />
#Defaults authenticate<br />
# If set, users must authenticate themselves via a password (or other means of authentication)<br />
# before they may run commands. This default may be overridden via the PASSWD and NOPASSWD<br />
<br />
#Defaults closefrom_override<br />
# If set, the user may use sudo's -C option which overrides the default starting<br />
# point at which sudo begins closing open file descriptors. Default: OFF<br />
<br />
#Defaults compress_io<br />
# If set, and sudo is configured to log a command's input or output, the I/O logs will be<br />
# compressed using zlib. This flag is on by default when sudo is compiled with zlib support.<br />
<br />
#Defaults env_editor<br />
# If set, visudo will use the value of the EDITOR or VISUAL environment variables before falling back on the default<br />
# editor list. Note that this may create a security hole as it allows th separated list of editors in the editor<br />
# variable. visudo will then only use the EDITOR or VISUAL if they match a value specified in editor. On by default.<br />
<br />
#Defaults env_reset<br />
# If set, sudo will run the command in a minimal environment containing the TERM, PATH, HOME, MAIL, SHELL, LOGNAME,<br />
# USER, USERNAME and SUDO_* variables. Any variables in the caller's env in the file specified by the env_file<br />
# option (if any). The default contents of the env_keep and env_check lists are displayed when sudo is run by<br />
# root with the -V option.<br />
<br />
#Defaults fast_glob<br />
# Normally, sudo uses the glob(3) function to do shell-style globbing when matching path names.<br />
# However, since it accesses the file system, glob(3) can take a long time to complete for som (automounted).<br />
# The fast_glob option causes sudo to use the fnmatch(3) function, which does not access the file system to do<br />
# its matching. The disadvantage of fast_glob is that it is unable to ma names that include globbing characters<br />
# are used with the negation operator, '!', as such rules can be trivially bypassed. As such, this option should<br />
# not be used when sudoers contains rules that<br />
<br />
#Defaults fqdn<br />
# Set this flag if you want to put fully qualified host names in the sudoers file. I.e., instead of myhost you<br />
# would use myhost.mydomain.edu. You may still use the short form if you wish (and sudo unusable if DNS stops<br />
# working (for example if the machine is not plugged into the network). Also note that you must use the<br />
# host's official name as DNS knows it. That is, you may not use a all aliases from DNS. If your machine's<br />
# host name (as returned by the hostname command) is already fully qualified you shouldn't need to set fqdn.<br />
# Default: OFF<br />
<br />
#Defaults ignore_dot<br />
# If set, sudo will ignore '.' or '' (current dir) in the PATH environment variable; the PATH<br />
# itself is not modified. Default: OFF<br />
<br />
#Defaults ignore_local_sudoers<br />
# If set via LDAP, parsing of /etc/sudoers will be skipped. This is intended for Enterprises that wish to prevent<br />
# the usage of local sudoers files so that only LDAP is used. /etc/sudoers does not even need to exist.<br />
# Since this option tells sudo how to behave when no specific LDAP entries have been matched, this sudo<br />
# Option is only meaningful for the cn=default<br />
<br />
#Defaults insults<br />
# If set, sudo will insult users when they enter an incorrect password. Default: OFF<br />
<br />
#Defaults log_host<br />
# If set, the host name will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults log_input<br />
# If set, sudo will run the command in a pseudo tty and log all user input. If the standard<br />
# input is not connected to the user's tty, due to I/O redirection or because the command is part Input is logged<br />
# to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that<br />
# is included in the normal sudo log line, prefixed with TSID=. Note that user input may contain sensitive<br />
# information such as passwords (even if they are not echoed to the screen), which will be stored in the log file<br />
# unencrypted.<br />
<br />
#Defaults log_output<br />
# If set, sudo will run the command in a pseudo tty and log all output that is sent to the<br />
# screen, similar to the script(1) command. If the standard output or standard error is not connec is also captured and<br />
# stored in separate log files. Output is logged to the directory specified by the iolog_dir option (/var/log/sudo-io<br />
# by default) using a unique session ID that is included in the normal sudo log line, prefixed with TSID=. The Output<br />
# logs may be viewed with the sudoreplay(8) utility, which can also be used to list or search the available logs.<br />
<br />
#Defaults log_year<br />
# If set, the four-digit year will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults long_otp_prompt<br />
# When validating with a One Time Password (OTP) scheme such as S/Key or OPIE, a two-line<br />
# prompt is used to make it easier to cut and paste the challenge to a local window<br />
<br />
#Defaults mail_always<br />
# Send mail to the mailto user every time a users runs sudo. Default: OFF<br />
<br />
#Defaults mail_badpass<br />
# Send mail to the mailto user if the user running sudo does not enter the correct password.<br />
# Default: OFF<br />
<br />
#Defaults mail_no_host<br />
# If set, mail will be sent to the mailto user if the invoking user exists in the sudoers<br />
# file, but is not allowed to run commands on the current host. Default: OFF<br />
<br />
#Defaults mail_no_perms<br />
# If set, mail will be sent to the mailto user if the invoking user is allowed to use sudo<br />
# but the command they are trying is not listed in their sudoers file entry or is explicitly denied<br />
<br />
#Defaults mail_no_user<br />
# If set, mail will be sent to the mailto user if the invoking user is not in the sudoers file.<br />
# Default: ON<br />
<br />
#Defaults noexec<br />
# If set, all commands run via sudo will behave as if the NOEXEC tag has been set, unless overridden<br />
# by a EXEC tag. See the description of NOEXEC and EXEC below as well as the "PREVENTING SHE<br />
<br />
#Defaults path_info<br />
# Normally, sudo will tell the user when a command could not be found in their PATH environment<br />
# variable. Some sites may wish to disable this as it could be used to gather information on t the executable is<br />
# simply not in the user's PATH, sudo will tell the user that they are not allowed to run it, which can be confusing.<br />
# Default: ON<br />
<br />
#Defaults passprompt_override<br />
# The password prompt specified by passprompt will normally only be used if the password prompt provided by<br />
# systems such as PAM matches the string "Password:"<br />
<br />
#Defaults preserve_groups<br />
# By default, sudo will initialize the group vector to the list of groups the target<br />
# user is in. When preserve_groups is set, the user's existing group vector is left unaltered.<br />
<br />
#Defaults pwfeedback<br />
# By default, sudo reads the password like most other Unix programs, by turning off echo<br />
# until the user hits the return (or enter) key. Some users become confused by this as it appears to the user<br />
# presses a key. Note that this does have a security impact as an onlooker may be able to determine the length of<br />
# the password being entered. Default: OFF<br />
<br />
#Defaults requiretty<br />
# If set, sudo will only run when the user is logged in to a real tty. When this flag is set,<br />
# sudo can only be run from a login session and not via other means such as cron(8) or cgi-bin<br />
<br />
#Defaults root_sudo<br />
# If set, root is allowed to run sudo too. Disabling this prevents users from "chaining" sudo<br />
# commands to get a root shell by doing something like "sudo sudo /bin/sh". Note, however, that real additional<br />
# security; it exists purely for historical reasons. Default: ON<br />
<br />
#Defaults rootpw<br />
# If set, sudo will prompt for the root password instead of the password of the invoking user.<br />
# Default: OFF<br />
<br />
#Defaults runaspw<br />
# If set, sudo will prompt for the password of the user defined by the runas_default option<br />
# (defaults to root) instead of the password of the invoking user. Default: OFF<br />
<br />
#Defaults set_home<br />
# If enabled and sudo is invoked with the -s option the HOME environment variable will be set<br />
# to the home directory of the target user (which is root unless the -u option is used). So set_home is only<br />
# effective for configs where either env_reset is disabled or HOME is present in the env_keep list. Default: OFF<br />
<br />
#Defaults set_logname<br />
# Normally, sudo will set the LOGNAME, USER and USERNAME environment variables to the name<br />
# of the target user (usually root unless the -u option is given). However, since some programs ( may be desirable<br />
# to change this behavior. This can be done by negating the set_logname option. Note that if the env_reset option<br />
# has not been disabled, entries in the env_keep list will override<br />
<br />
#Defaults set_utmp<br />
# When enabled, sudo will create an entry in the utmp (or utmpx) file when a pseudo-tty is<br />
# allocated. A pseudo-tty is allocated by sudo when the log_input, log_output or use_pty flags are e the tty, time,<br />
# type and pid fields updated. Default: ON<br />
<br />
#Defaults setenv<br />
# Allow the user to disable the env_reset option from the command line via the -E option.<br />
# Additionally, environment variables set via the command line are not subject to the restrictions impo variables<br />
# in this manner. Default: OFF<br />
<br />
#Defaults shell_noargs<br />
# If set and sudo is invoked with no arguments it acts as if the -s option had been given.<br />
# That is, it runs a shell as root (the shell is determined by the SHELL environment variable if is off by default.<br />
<br />
#Defaults stay_setuid<br />
# Normally, when sudo executes a command the real and effective UIDs are set to the target<br />
# user (root by default). This option changes that behaviour such that the real UID is left as the systems that<br />
# disable some potentially dangerous functionality when a program is run setuid. This option is only effective on<br />
# systems with either the setreuid() or setresuid() function. This flag<br />
<br />
#Defaults targetpw<br />
# If set, sudo will prompt for the password of the user specified by the -u option (defaults to root) instead<br />
# of the password of the invoking user. In addition, the timestamp file name will passwd database as an argument<br />
# to the -u option. Default: OFF<br />
<br />
#Defaults tty_tickets<br />
# If set, users must authenticate on a per-tty basis. With this flag enabled, sudo will<br />
# use a file named for the tty the user is logged in on in the user's time stamp directory.<br />
<br />
#Defaults umask_override<br />
# If set, sudo will set the umask as specified by sudoers without modification. This makes<br />
# it possible to specify a more permissive umask in sudoers than the user's own umask and match user's umask and what<br />
# is specified in sudoers. Default: OFF<br />
<br />
#Defaults use_pty<br />
# If set, sudo will run the command in a pseudo-pty even if no I/O logging is being gone.<br />
# A malicious program run under sudo could conceivably fork a background process that retains to the u that impossible.<br />
# Default: OFF<br />
<br />
#Defaults utmp_runas<br />
# If set, sudo will store the name of the runas user when updating the utmp (or utmpx) file.<br />
# By default, sudo stores the name of the invoking user. Default: OFF<br />
<br />
#Defaults visiblepw<br />
# By default, sudo will refuse to run if the user must enter a password but it is not possible to disable echo on the <br />
# terminal. If the visiblepw flag is set, sudo will prompt for a password even when it would be visible on the screen. <br />
# This makes it possible to run things like "rsh somehost sudo ls" since rsh(1) does not allocate a tty. Default: OFF<br />
<br />
#Defaults closefrom<br />
# Before it executes a command, sudo will close all open file descriptors other than standard<br />
# input, standard output and standard error (ie: file descriptors 0-2).<br />
<br />
#Defaults passwd_tries<br />
# The number of tries a user gets to enter his/her password before sudo logs the failure<br />
# and exits. The default is 3.<br />
<br />
#Defaults loglinelen<br />
# Number of characters per line for the file log. This value is used to decide when to wrap<br />
# lines for nicer log files. This has no effect on the syslog log file, only the file log.<br />
<br />
#Defaults passwd_timeout<br />
# Number of minutes before the sudo password prompt times out, or 0 for no timeout.<br />
# The timeout may include a fractional component if minute granularity is insufficient, for example 2<br />
<br />
#Defaults timestamp_timeout<br />
# Number of minutes that can elapse before sudo will ask for a passwd again. The timeout<br />
# may include a fractional component if minute granularity is insufficient, for example 2.5. timestamp will never expire.<br />
# This can be used to allow users to create or delete their own timestamps via sudo -v and sudo -k respectively.<br />
<br />
#Defaults umask<br />
# Umask to use when running the command. Negate this option or set it to 0777 to preserve<br />
# the user's umask. The actual umask that is used will be the union of the user's umask and the value o running<br />
# a command. Note on systems that use PAM, the default PAM configuration may specify its own umask which will<br />
# override the value set in sudoers.<br />
<br />
#Defaults badpass_message<br />
# Message that is displayed if a user enters an incorrect password. The default is Sorry,<br />
# try again. unless insults are enabled.<br />
<br />
#Defaults editor<br />
# A colon (':') separated list of editors allowed to be used with visudo. visudo will choose<br />
# the editor that matches the user's EDITOR environment variable if possible, or the first editor in<br />
<br />
#Defaults iolog_dir<br />
# The top-level directory to use when constructing the path name for the input/output log<br />
# directory. Only used if the log_input or log_output options are enabled or when the LOG_INPUT or L directory.<br />
# The default is "/var/log/sudo-io". The following percent (%) escape sequences are supported:<br />
# %{seq} - expanded to base-36 sequence number, such as 0100A5, to form a new directory, e.g. 01/00/A5<br />
# %{user} - expanded to the invoking user's login name<br />
# %{group} - expanded to the name of the invoking user's real group ID<br />
# %{runas_user} - expanded to the login name of the user the command will be run as (e.g. root)<br />
# %{runas_group} - expanded to the group name of the user the command will be run as (e.g. wheel)<br />
# %{hostname} - expanded to the local host name without the domain name<br />
# %{command} - expanded to the base name of the command being run In addition, any escape sequences supported by<br />
# strftime() function will be expanded. To include a literal % character, the string %% should be used.<br />
<br />
#Defaults iolog_file<br />
# The path name, relative to iolog_dir, in which to store input/output logs when the log_input or log_output options are<br />
# enabled or when the LOG_INPUT or LOG_OUTPUT tags are present for a See the iolog_dir option above for a list of<br />
# supported percent (%) escape sequences. In addition to the escape sequences, path names that end in six or more Xs will<br />
# have the Xs replaced with a unique combination of digits and letters, similar to the mktemp() function.<br />
<br />
#Defaults mailsub<br />
# Subject of the mail sent to the mailto user. The escape %h will expand to the host name of<br />
# the machine. Default is *** SECURITY information for %h ***.<br />
<br />
#Defaults noexec_file<br />
# This option is no longer supported. The path to the noexec file should now be set in the /etc/sudo.conf file.<br />
<br />
#Defaults passprompt<br />
# The default prompt to use when asking for a password; can be overridden via the -p option or the SUDO_PROMPT<br />
# environment variable. The following percent (%) escape sequences are supported:<br />
# %H - expanded to the local host name including the domain (only if the host name is fqdn or fqdn option is set)<br />
# %h - expanded to the local host name without the domain name<br />
# %p - expanded to the user whose password is being asked for (respects the rootpw, targetpw and runaspw flags)<br />
# %U - expanded to the login name of the user the command will be run as (defaults to root)<br />
# %u - expanded to the invoking user's login name<br />
# %% - two consecutive % characters are collapsed into a single % character<br />
# The default value is Password:.<br />
<br />
#Defaults runas_default<br />
# The default user to run commands as if the -u option is not specified on the command line. This defaults to root.<br />
<br />
#Defaults syslog_badpri<br />
# Syslog priority to use when user authenticates unsuccessfully. Defaults to alert.<br />
# alert, crit, debug, emerg, err, info, notice, and warning.<br />
<br />
#Defaults syslog_goodpri<br />
# Syslog priority to use when user authenticates successfully. Defaults to notice. See syslog_badpri for the priorities.<br />
<br />
#Defaults sudoers_locale<br />
# Locale to use when parsing the sudoers file, logging commands, and sending email.<br />
# Note that changing the locale may affect how sudoers is interpreted. Defaults to "C".<br />
<br />
#Defaults timestampdir<br />
# The directory in which sudo stores its timestamp files. The default is /var/db/sudo.<br />
<br />
#Defaults timestampowner<br />
# The owner of the timestamp directory and the timestamps stored therein. The default is root.<br />
<br />
#Defaults env_file<br />
# The env_file option specifies the fully qualified path to a file containing variables to<br />
# be set in the environment of the program being run. Entries in this file should either be of the f quotes.<br />
# Variables in this file are subject to other sudo environment settings such as env_keep and env_check.<br />
<br />
#Defaults exempt_group<br />
# Users in this group are exempt from password and PATH requirements. The group name specified should not include<br />
# a % prefix. This is not set by default.<br />
<br />
#Defaults group_plugin<br />
# A string containing a sudoers group plugin with optional arguments. This can be used to implement support for the<br />
# nonunix_group syntax described earlier. The string should consist of configuration arguments the plugin requires.<br />
# These arguments (if any) will be passed to the plugin's initialization function. If arguments are present, the<br />
# string must be enclosed in double quote For example, given /etc/sudo-group, a group file in Unix group format,<br />
# the sample group plugin can be used: Defaults group_plugin="sample_group.so /etc/sudo-group"<br />
# For more information see sudo_plugin(5).<br />
<br />
#Defaults lecture<br />
# This option controls when a short lecture will be printed along with the password prompt. The default value is once.<br />
# It has the following possible values:<br />
# always - Always lecture the user.<br />
# never - Never lecture the user.<br />
# once - Only lecture the user the first time they run sudo.<br />
# If no value is specified, a value of once is implied. Negating the option results in a value of never being used.<br />
<br />
#Defaults lecture_file<br />
# Path to a file containing an alternate sudo lecture that will be used in place of the standard lecture if the named<br />
# file exists. By default, sudo uses a built-in lecture.<br />
<br />
#Defaults listpw<br />
# This option controls when a password will be required when a user runs sudo with the -l option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD set to avoid entering a pass.<br />
# always - The user must always enter a password to use the -l option.<br />
# any - At least one of the user's sudoers entries for the current host must have the NOPASSWD set to avoid pass.<br />
# never - The user need never enter a password to use the -l option.<br />
# If no value is specified, a value of any is implied. The default value is any.<br />
<br />
#Defaults logfile<br />
# Path to the sudo log file (not the syslog log file). Setting a path turns on logging to a file;<br />
# negating this option turns it off. By default, sudo logs via syslog.<br />
<br />
#Defaults mailerflags<br />
# Flags to use when invoking mailer. Defaults to -t.<br />
<br />
#Defaults mailerpath<br />
# Path to mail program used to send warning mail. Defaults to the path to sendmail found at configure time.<br />
<br />
#Defaults mailfrom<br />
# Address to use for the "from" address when sending warning and error mail. The address should<br />
# be enclosed in double quotes (") to protect against sudo interpreting the @ sign.<br />
<br />
#Defaults mailto<br />
# Address to send warning and error mail to. The address should be enclosed in double quotes<br />
# (") to protect against sudo interpreting the @ sign. Defaults to root.<br />
<br />
#Defaults secure_path<br />
# Path used for every command run from sudo. If you don't trust the people running sudo to have a sane PATH environment<br />
# variable you may want to use this. Another use is if you want to option are not affected by secure_path.<br />
# This option is not set by default.<br />
<br />
#Defaults syslog<br />
# Syslog facility if syslog is being used for logging (negate to disable syslog logging). Defaults to auth.<br />
# authpriv (if OS supports it), auth, daemon, user, local0, local1, local2, local3, local4, local5, local6, and local7.<br />
<br />
#Defaults verifypw<br />
# This option controls when a password will be required when a user runs sudo with the -v option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD flag to avoid pw.<br />
# always - The user must always enter a password to use the -v option.<br />
# any - At least one of the user's sudoers entries for the current host must have NOPASSWD to avoid pw.<br />
# never - The user need never enter a password to use the -v option<br />
# If no value is specified, a value of all is implied. Negating the option results in a value of never being used.<br />
# The default value is all.<br />
<br />
#Defaults env_check<br />
# Environment variables to be removed from the user's environment if the variable's value contains % or / characters.<br />
# This can be used to guard against printf-style format vulnerabilities value without double-quotes. The list can be<br />
# replaced, added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively. Regardless of<br />
# whether the env_reset option is ena they pass the aforementioned check. The default list of environment variables<br />
# to check is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_delete<br />
# Environment variables to be removed from the user's environment when the env_reset option is not in effect. The<br />
# argument may be a double-quoted, space-separated list or a single value w +=, -=, and ! operators respectively.<br />
# The default list of environment variables to remove is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_keep<br />
# Environment variables to be preserved in the user's environment when the env_reset option is in effect. This<br />
# allows fine-grained control over the environment sudo-spawned processes will r quotes. The list can be replaced,<br />
# added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively.</nowiki>}}</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Sudo&diff=281639Sudo2013-11-06T02:53:04Z<p>Hunterthomson: /* Harden with Sudo Example */ Better commands, use (username) SHELL, (otheruser) SHELL</p>
<hr />
<div>[[Category:Security]]<br />
[[cs:Sudo]]<br />
[[es:Sudo]]<br />
[[fr:Sudo]]<br />
[[it:Sudo]]<br />
[[ja:Sudo]]<br />
[[ru:Sudo]]<br />
[[sr:Sudo]]<br />
[[tr:Sudo]]<br />
[[uk:Sudo]]<br />
[[zh-CN:Sudo]]<br />
{{Article summary start}}<br />
{{Article summary text|An overview of the popular privilege escalation utility.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Access control overview}}}}<br />
{{Article summary end}}<br />
<br />
[http://www.gratisoft.us/sudo/ sudo] ("substitute user do") allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments.<br />
<br />
== Rationale ==<br />
<br />
Sudo is an alternative to [[su]] for running commands as root. Unlike [[su]], which launches a root shell that allows all further commands root access, sudo instead grants temporary privilege escalation to a single command. By enabling root privileges only when needed, sudo usage reduces the likelyhood that a typo or a bug in an invoked command will ruin the system.<br />
Sudo can also be used to run commands as other users; additionally, sudo logs all commands and failed access attempts for security auditing.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|sudo}} package, available in the [[Official Repositories|official repositories]]:<br />
<br />
# pacman -S sudo<br />
<br />
To begin using {{ic|sudo}} as a non-privileged user, it must be properly configured. So make sure you read the configuration section.<br />
<br />
== Usage ==<br />
<br />
With sudo, users can prefix commands with {{ic|sudo}} to run them with superuser (or other) privileges.<br />
<br />
For example, to use pacman:<br />
<br />
$ sudo pacman -Syu<br />
<br />
See the [http://www.gratisoft.us/sudo/man/sudo.html sudo manual] for more information.<br />
<br />
== Configuration ==<br />
<br />
=== View current settings ===<br />
<br />
Run {{ic|sudo -ll}} to print out the current sudo configuration.<br />
<br />
=== Using visudo ===<br />
<br />
The configuration file for sudo is {{ic|/etc/sudoers}}. It should '''always''' be edited with the {{ic|visudo}} command. {{ic|visudo}} locks the {{ic|sudoers}} file, saves edits to a temporary file, and checks that file's grammar before copying it to {{ic|/etc/sudoers}}.<br />
<br />
{{Warning|It is imperative that {{ic|sudoers}} be free of syntax errors! Any error makes sudo unusable. '''Always''' edit it with {{ic|visudo}} to prevent errors.}}<br />
<br />
The default editor for visudo is {{ic|vi}}. It will be used if you do not specify another editor, by setting either VISUAL or EDITOR environment variables (used in that order) to the desired editor, e.g. {{ic|nano}}. The command is run as root:<br />
<br />
# EDITOR=nano visudo<br />
<br />
You can permanently change the setting for your user to e.g. {{ic|nano}} by appending:<br />
<br />
export EDITOR=nano<br />
<br />
to your {{ic|~/.bashrc}} file. Note that this won't take effect for already-running shells.<br />
<br />
To change the editor of choice permanently system-wide only for {{ic|visudo}}, add the following line to {{ic|/etc/sudoers}} where {{ic|nano}} is your prefered editor:<br />
<br />
# Reset environment by default<br />
Defaults env_reset<br />
# Set default EDITOR to nano, and do not allow visudo to use EDITOR/VISUAL.<br />
Defaults editor=/usr/bin/nano, !env_editor<br />
<br />
=== Example Entries ===<br />
<br />
To allow a user to gain full root privileges when he/she precedes a command with {{ic|sudo}}, add the following line:<br />
<br />
USER_NAME ALL=(ALL) ALL<br />
<br />
To allow a user to run all commands as any user but only the machine with hostname HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=(ALL) ALL<br />
<br />
To allow members of group {{ic|wheel}} sudo access:<br />
<br />
%wheel ALL=(ALL) ALL<br />
<br />
To disable asking for a password for user USER_NAME:<br />
<br />
Defaults:USER_NAME !authenticate<br />
<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=/usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
{{note| the most customized option should go at the end of the file, as the later lines overrides the previous ones. In particular such a line should be after the {{ic|%wheel}} line if your user is in this group.}}<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME without password:<br />
USER_NAME HOST_NAME= NOPASSWD: /usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
<br />
A detailed sudoers example can be found [http://www.gratisoft.us/sudo/sample.sudoers here]. Otherwise, see the [http://www.gratisoft.us/sudo/man/sudoers.html sudoers manual] for detailed information.<br />
<br />
=== Sudoers default file permissions ===<br />
<br />
The owner and group for the sudoers file must both be 0. The file permissions must be set to 0440. These permissions are set by default, but if you accidentally change them, they should be changed back immediately or sudo will fail.<br />
<br />
# chown -c root:root /etc/sudoers<br />
# chmod -c 0440 /etc/sudoers<br />
<br />
=== Password cache timeout ===<br />
<br />
Users may wish to change the default timeout before the cached password expires. This is accomplished with the timestamp_timeout option in {{ic|/etc/sudoers}} which is in minutes.<br />
Set timeout to 20 minutes.<br />
<br />
Defaults:USER_NAME timestamp_timeout=20<br />
<br />
{{Tip|To ensure sudo always asks for a password, set the timeout to 0. To ensure the password never times out, set to less than 0.}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== File example ===<br />
<br />
This example is especially helpful for those using terminal multiplexers like screen, tmux, or ratpoison, and those using sudo from scripts/cronjobs:<br />
<br />
{{hc|/etc/sudoers|<nowiki><br />
Cmnd_Alias WHEELER = /usr/bin/lsof, /bin/nice, /bin/ps, /usr/bin/top, /usr/local/bin/nano, /usr/bin/ss, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync<br />
Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/kill, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
Cmnd_Alias EDITS = /usr/bin/vim, /usr/bin/nano, /usr/bin/cat, /usr/bin/vi<br />
Cmnd_Alias ARCHLINUX = /usr/bin/gparted, /usr/bin/pacman<br />
<br />
root ALL = (ALL) ALL<br />
USER_NAME ALL = (ALL) ALL, NOPASSWD: WHEELER, NOPASSWD: PROCESSES, NOPASSWD: ARCHLINUX, NOPASSWD: EDITS<br />
<br />
Defaults !requiretty, !tty_tickets, !umask<br />
Defaults visiblepw, path_info, insults, lecture=always<br />
Defaults loglinelen = 0, logfile =/var/log/sudo.log, log_year, log_host, syslog=auth<br />
Defaults mailto=webmaster@foobar.com, mail_badpass, mail_no_user, mail_no_perms<br />
Defaults passwd_tries = 8, passwd_timeout = 1<br />
Defaults env_reset, always_set_home, set_home, set_logname<br />
Defaults !env_editor, editor="/usr/bin/vim:/usr/bin/vi:/usr/bin/nano"<br />
Defaults timestamp_timeout=360<br />
Defaults passprompt="Sudo invoked by [%u] on [%H] - Cmd run as %U - Password for user %p:"<br />
</nowiki>}}<br />
<br />
=== Enabling Tab-completion in Bash ===<br />
<br />
{{ic|Tab}}-completion, by default, will not work when a user is initially added to the sudoers file. For example, normally john only needs to type:<br />
<br />
$ fire<{{ic|Tab}}><br />
<br />
and the shell will complete the command for him as:<br />
<br />
$ firefox<br />
<br />
If, however, john is added to the sudoers file and he types:<br />
<br />
$ sudo fire<{{ic|Tab}}><br />
<br />
the shell will do nothing.<br />
<br />
To enable {{ic|Tab}}-completion with sudo, [[pacman|install]] the {{pkg|bash-completion}} package from the [[Official Repositories|official repositories]]. see [[bash#Tab_completion]] for more information.<br />
<br />
Alternatively, add the following to your {{ic|~/.bashrc}}:<br />
<br />
complete -cf sudo<br />
<br />
=== Run X11 apps using sudo ===<br />
<br />
To allow sudo to start graphical application in X11, you need to add:<br />
<br />
Defaults env_keep += "HOME"<br />
<br />
to visudo.<br />
<br />
=== Disable per-terminal sudo ===<br />
<br />
{{Warning|This will let any process use your sudo session.}}<br />
<br />
If you are annoyed by sudo's defaults that require you to enter your password every time you open a new terminal, disable '''tty_tickets''':<br />
<br />
Defaults !tty_tickets<br />
<br />
=== Environment variables ===<br />
<br />
If you have a lot of environment variables, or you export your proxy settings via {{ic|1=export http_proxy="..."}}, when using sudo these variables do not get passed to the root account unless you run sudo with the {{ic|-E}} option.<br />
<br />
$ sudo -E pacman -Syu<br />
<br />
The recommended way of preserving environment variables is to append them to {{ic|env_keep}}:<br />
{{hc|/etc/sudoers|<nowiki><br />
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"<br />
</nowiki>}}<br />
<br />
=== Passing aliases ===<br />
<br />
If you use a lot of aliases, you might have noticed that they do not carry over to the root account when using sudo. However, there is an easy way to make them work. Simply add the following to your {{ic|~/.bashrc}} or {{ic|/etc/bash.bashrc}}:<br />
<br />
alias sudo='sudo '<br />
<br />
=== Insults ===<br />
<br />
Users can configure sudo to display clever insults when an incorrect password is entered instead of printing the default "wrong password" message. Find the Defaults line in {{ic|/etc/sudoers}} and append "insults" after a comma to existing options. The final result might look like this:<br />
<br />
#Defaults specification<br />
Defaults insults<br />
<br />
To test, type {{ic|sudo -K}} to end the current session and let sudo ask for the password again.<br />
<br />
=== Root password ===<br />
<br />
Users can configure sudo to ask for the root password instead of the user password by adding "rootpw" to the Defaults line in {{ic|/etc/sudoers}}:<br />
<br />
Defaults timestamp_timeout=0,rootpw<br />
<br />
=== Disable root login ===<br />
<br />
{{Warning|Arch Linux is not fine-tuned to run with a disabled root account. Users may encounter problems with this method.}}<br />
<br />
With sudo installed and configured, users may wish to disable the root login. Without root, attackers must first guess a user name configured as a sudoer as well as the user password.<br />
<br />
{{Warning|Ensure a user is properly configured as a sudoer ''before'' disabling the root account!}}<br />
<br />
The account can be locked via {{ic|passwd}}:<br />
<br />
# passwd -l root<br />
<br />
A similar command unlocks root.<br />
<br />
$ sudo passwd -u root<br />
<br />
Alternatively, edit {{ic|/etc/shadow}} and replace the root's encrypted password with "!":<br />
<br />
root:!:12345::::::<br />
<br />
To enable root login again:<br />
<br />
$ sudo passwd root<br />
<br />
==== kdesu ====<br />
<br />
kdesu may be used under KDE to launch GUI applications with root privileges. It is possible that by default kdesu will try to use su even if the root account is disabled. Fortunately one can tell kdesu to use sudo instead of su. Create/edit the file {{ic|~/.kde4/share/config/kdesurc}}:<br />
<br />
[super-user-command]<br />
super-user-command=sudo<br />
<br />
==== PolicyKit ====<br />
<br />
When disabling the root account, it is necessary to change the [[PolicyKit]] configuration for local authorization to reflect that. The default is to ask for the root password, so that must be changed. With polkit-1, this can be achieved by editing {{ic|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf}} so that {{ic|1=AdminIdentities=unix-user:0}} is replaced with something else, depending on the system configuration. It can be a list of users and groups, for example:<br />
<br />
AdminIdentities=unix-group:wheel<br />
<br />
or<br />
<br />
AdminIdentities=unix-user:me;unixuser:mom;unix-group:wheel<br />
<br />
For more information, see {{ic|man pklocalauthority}}.<br />
<br />
==== NetworkManager ====<br />
<br />
Even with the above PolicyKit configuration you still need to configure a policy for NetworkManager. This is documented on the [[NetworkManager#Can.27t_edit_connections_as_normal_user|NetworkManager]] page of this wiki.<br />
<br />
=== Harden with Sudo Example ===<br />
<br />
Lets say you create 3 users: admin, devel, and Joe<br />
admin is used for journalctl, systemctl, mount, kill, and iptables.<br />
devel is used for installing packages, and editing config's<br />
Joe is the user you log in with. Let's let him reboot, shutdown, and use netctl<br />
<br />
Edit /etc/pam.d/su and /etc/pam.d/su-1<br />
Require user be in the wheel group, but don't put anyone in it.<br />
#%PAM-1.0<br />
auth sufficient pam_rootok.so<br />
# Uncomment the following line to implicitly trust users in the "wheel" group.<br />
#auth sufficient pam_wheel.so trust use_uid<br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
auth required pam_unix.so<br />
account required pam_unix.so<br />
session required pam_unix.so<br />
<br />
Limit SSH login to the 'ssh' group, Only put Joe in it<br />
groupadd -r ssh<br />
gpasswd -a Joe ssh<br />
echo 'AllowGroups ssh' >> /etc/ssh/sshd_config<br />
systemctl restart sshd.service<br />
<br />
Lets add users to other goups.<br />
for g in network power ;do ;gpasswd -a Joe $g ;done<br />
for g in network power disk ;do ;gpasswd -a Joe $g ;done<br />
<br />
Set permissions on configs so devel can edit them.<br />
chown -R devel:root /etc/{http,openvpn,cups,zsh,vim,screenrc}<br />
<br />
Cmnd_Alias POWER = /usr/bin/shutdown -h now, /usr/bin/halt, /usr/bin/poweroff, /usr/bin/reboot<br />
Cmnd_Alias DISK = /usr/bin/mount, /usr/bin/umount<br />
Cmnd_Alias SYSTEMD = /usr/bin/journalctl, /usr/bin/systemctl<br />
Cmnd_Alias KILL = /usr/bin/kill<br />
Cmnd_Alias PKGMAN = /usr/bin/pacman<br />
Cmnd_Alias NETWORK = /usr/bin/netctl<br />
Cmnd_Alias SHELL = /usr/bin/zsh, /usr/bin/bash<br />
%power ALL = (root) NOPASSWD: POWER<br />
%network ALL = (root) NETWORK<br />
root ALL = (ALL) ALL<br />
admin ALL = (root) SYSTEMD, KILL<br />
devel ALL = (root) PKGMAN<br />
Joe ALL = (devel) SHELL, (admin) SU_DEVEL <br />
<br />
With this setup, you will almost never need to login as the Root user.<br />
<br />
Joe can connect to his home WiFi<br />
sudo netctl start home<br />
sudo poweroff<br />
<br />
Joe can not use netctl as any other user like admin...<br />
sudo -u admin -- netctl start home<br />
<br />
When Joe needs to use journalctl or kill run away process he can switch to that user<br />
sudo -i -u devel<br />
sudo -i -u admin<br />
<br />
But not Root<br />
sudo -i -u root<br />
<br />
If joe want to start a gnu-screen session as admin he can do it like this<br />
sudo -i -u admin<br />
admin% chown admin:tty `echo $TTY`<br />
admin% screen<br />
<br />
== Troubleshooting ==<br />
<br />
=== SSH TTY Issues ===<br />
<br />
SSH does not allocate a tty by default when running a remote command. Without a tty, sudo cannot disable echo when prompting for a password. You can use ssh's {{ic|-tt}} option to force it to allocate a tty (or {{ic|-t}} twice).<br />
<br />
The {{ic|Defaults}} option {{ic|requiretty}} only allows the user to run sudo if they have a tty.<br />
<br />
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear text. You have to run "ssh -t hostname sudo <cmd>".<br />
#<br />
#Defaults requiretty<br />
<br />
=== Display User Privileges ===<br />
<br />
You can find out what privileges a particular user has with the following command:<br />
<br />
$ sudo -lU yourusename<br />
<br />
Or view your own with:<br />
<br />
{{hc|$ sudo -l|<nowiki><br />
Matching Defaults entries for yourusename on this host:<br />
loglinelen=0, logfile=/var/log/sudo.log, log_year, syslog=auth, mailto=webmaster@gmail.com, mail_badpass, mail_no_user,<br />
mail_no_perms,env_reset, always_set_home, tty_tickets, lecture=always, pwfeedback, rootpw, set_home<br />
<br />
User yourusename may run the following commands on this host:<br />
<br />
(ALL) ALL<br />
(ALL) NOPASSWD: /usr/bin/lsof, /bin/nice, /usr/bin/su, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync, /usr/bin/strace,<br />
(ALL) /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
(ALL) /usr/bin/gparted, /usr/bin/pacman<br />
(ALL) /usr/local/bin/synergyc, /usr/local/bin/synergys<br />
(ALL) /usr/bin/vim, /usr/bin/nano, /usr/bin/cat<br />
(root) NOPASSWD: /usr/local/bin/synergyc</nowiki>}}<br />
<br />
=== Permissive Umask ===<br />
<br />
Sudo will union the user's [[umask]] value with its own umask (which defaults to 0022). This prevents sudo from creating files with more open permissions than the user's umask allows. While this is a sane default if no custom umask is in use, this can lead to situations where a utility run by sudo may create files with different permissions than if run by root directly. If errors arise from this, sudo provides a means to fix the umask, even if the desired umask is more permissive than the umask that the user has specified. Adding this (using {{ic|visudo}}) will override sudo's default behavior:<br />
<br />
Defaults umask = 0022<br />
Defaults umask_override<br />
<br />
This sets sudo's umask to root's default umask (0022) and overrides the default behavior, always using the indicated umask regardless of what umask the user as set.<br />
<br />
<br />
=== Defaults Skeleton ===<br />
<br />
The authors site has a [http://www.gratisoft.us/sudo/sudoers.man.html#sudoers_options list of all the options] that can be used with the {{ic|Defaults}} command in the {{ic|/etc/sudoers}} file.<br />
<br />
The full list of options ''(parsed from the version 1.8.7 source code)'' is below in a format optimized for copying and pasting into your sudoers files for quick editing.<br />
<br />
{{bc|<nowiki>#Defaults always_set_home<br />
# If enabled, sudo will set the HOME environment variable to the home directory of the target user<br />
# (which is root unless the -u option is used). This effectively means that the -H option<br />
# always_set_home is only effective for configurations where either env_reset is disabled or HOME is present<br />
# in the env_keep list. Default: OFF<br />
<br />
#Defaults authenticate<br />
# If set, users must authenticate themselves via a password (or other means of authentication)<br />
# before they may run commands. This default may be overridden via the PASSWD and NOPASSWD<br />
<br />
#Defaults closefrom_override<br />
# If set, the user may use sudo's -C option which overrides the default starting<br />
# point at which sudo begins closing open file descriptors. Default: OFF<br />
<br />
#Defaults compress_io<br />
# If set, and sudo is configured to log a command's input or output, the I/O logs will be<br />
# compressed using zlib. This flag is on by default when sudo is compiled with zlib support.<br />
<br />
#Defaults env_editor<br />
# If set, visudo will use the value of the EDITOR or VISUAL environment variables before falling back on the default<br />
# editor list. Note that this may create a security hole as it allows th separated list of editors in the editor<br />
# variable. visudo will then only use the EDITOR or VISUAL if they match a value specified in editor. On by default.<br />
<br />
#Defaults env_reset<br />
# If set, sudo will run the command in a minimal environment containing the TERM, PATH, HOME, MAIL, SHELL, LOGNAME,<br />
# USER, USERNAME and SUDO_* variables. Any variables in the caller's env in the file specified by the env_file<br />
# option (if any). The default contents of the env_keep and env_check lists are displayed when sudo is run by<br />
# root with the -V option.<br />
<br />
#Defaults fast_glob<br />
# Normally, sudo uses the glob(3) function to do shell-style globbing when matching path names.<br />
# However, since it accesses the file system, glob(3) can take a long time to complete for som (automounted).<br />
# The fast_glob option causes sudo to use the fnmatch(3) function, which does not access the file system to do<br />
# its matching. The disadvantage of fast_glob is that it is unable to ma names that include globbing characters<br />
# are used with the negation operator, '!', as such rules can be trivially bypassed. As such, this option should<br />
# not be used when sudoers contains rules that<br />
<br />
#Defaults fqdn<br />
# Set this flag if you want to put fully qualified host names in the sudoers file. I.e., instead of myhost you<br />
# would use myhost.mydomain.edu. You may still use the short form if you wish (and sudo unusable if DNS stops<br />
# working (for example if the machine is not plugged into the network). Also note that you must use the<br />
# host's official name as DNS knows it. That is, you may not use a all aliases from DNS. If your machine's<br />
# host name (as returned by the hostname command) is already fully qualified you shouldn't need to set fqdn.<br />
# Default: OFF<br />
<br />
#Defaults ignore_dot<br />
# If set, sudo will ignore '.' or '' (current dir) in the PATH environment variable; the PATH<br />
# itself is not modified. Default: OFF<br />
<br />
#Defaults ignore_local_sudoers<br />
# If set via LDAP, parsing of /etc/sudoers will be skipped. This is intended for Enterprises that wish to prevent<br />
# the usage of local sudoers files so that only LDAP is used. /etc/sudoers does not even need to exist.<br />
# Since this option tells sudo how to behave when no specific LDAP entries have been matched, this sudo<br />
# Option is only meaningful for the cn=default<br />
<br />
#Defaults insults<br />
# If set, sudo will insult users when they enter an incorrect password. Default: OFF<br />
<br />
#Defaults log_host<br />
# If set, the host name will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults log_input<br />
# If set, sudo will run the command in a pseudo tty and log all user input. If the standard<br />
# input is not connected to the user's tty, due to I/O redirection or because the command is part Input is logged<br />
# to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that<br />
# is included in the normal sudo log line, prefixed with TSID=. Note that user input may contain sensitive<br />
# information such as passwords (even if they are not echoed to the screen), which will be stored in the log file<br />
# unencrypted.<br />
<br />
#Defaults log_output<br />
# If set, sudo will run the command in a pseudo tty and log all output that is sent to the<br />
# screen, similar to the script(1) command. If the standard output or standard error is not connec is also captured and<br />
# stored in separate log files. Output is logged to the directory specified by the iolog_dir option (/var/log/sudo-io<br />
# by default) using a unique session ID that is included in the normal sudo log line, prefixed with TSID=. The Output<br />
# logs may be viewed with the sudoreplay(8) utility, which can also be used to list or search the available logs.<br />
<br />
#Defaults log_year<br />
# If set, the four-digit year will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults long_otp_prompt<br />
# When validating with a One Time Password (OTP) scheme such as S/Key or OPIE, a two-line<br />
# prompt is used to make it easier to cut and paste the challenge to a local window<br />
<br />
#Defaults mail_always<br />
# Send mail to the mailto user every time a users runs sudo. Default: OFF<br />
<br />
#Defaults mail_badpass<br />
# Send mail to the mailto user if the user running sudo does not enter the correct password.<br />
# Default: OFF<br />
<br />
#Defaults mail_no_host<br />
# If set, mail will be sent to the mailto user if the invoking user exists in the sudoers<br />
# file, but is not allowed to run commands on the current host. Default: OFF<br />
<br />
#Defaults mail_no_perms<br />
# If set, mail will be sent to the mailto user if the invoking user is allowed to use sudo<br />
# but the command they are trying is not listed in their sudoers file entry or is explicitly denied<br />
<br />
#Defaults mail_no_user<br />
# If set, mail will be sent to the mailto user if the invoking user is not in the sudoers file.<br />
# Default: ON<br />
<br />
#Defaults noexec<br />
# If set, all commands run via sudo will behave as if the NOEXEC tag has been set, unless overridden<br />
# by a EXEC tag. See the description of NOEXEC and EXEC below as well as the "PREVENTING SHE<br />
<br />
#Defaults path_info<br />
# Normally, sudo will tell the user when a command could not be found in their PATH environment<br />
# variable. Some sites may wish to disable this as it could be used to gather information on t the executable is<br />
# simply not in the user's PATH, sudo will tell the user that they are not allowed to run it, which can be confusing.<br />
# Default: ON<br />
<br />
#Defaults passprompt_override<br />
# The password prompt specified by passprompt will normally only be used if the password prompt provided by<br />
# systems such as PAM matches the string "Password:"<br />
<br />
#Defaults preserve_groups<br />
# By default, sudo will initialize the group vector to the list of groups the target<br />
# user is in. When preserve_groups is set, the user's existing group vector is left unaltered.<br />
<br />
#Defaults pwfeedback<br />
# By default, sudo reads the password like most other Unix programs, by turning off echo<br />
# until the user hits the return (or enter) key. Some users become confused by this as it appears to the user<br />
# presses a key. Note that this does have a security impact as an onlooker may be able to determine the length of<br />
# the password being entered. Default: OFF<br />
<br />
#Defaults requiretty<br />
# If set, sudo will only run when the user is logged in to a real tty. When this flag is set,<br />
# sudo can only be run from a login session and not via other means such as cron(8) or cgi-bin<br />
<br />
#Defaults root_sudo<br />
# If set, root is allowed to run sudo too. Disabling this prevents users from "chaining" sudo<br />
# commands to get a root shell by doing something like "sudo sudo /bin/sh". Note, however, that real additional<br />
# security; it exists purely for historical reasons. Default: ON<br />
<br />
#Defaults rootpw<br />
# If set, sudo will prompt for the root password instead of the password of the invoking user.<br />
# Default: OFF<br />
<br />
#Defaults runaspw<br />
# If set, sudo will prompt for the password of the user defined by the runas_default option<br />
# (defaults to root) instead of the password of the invoking user. Default: OFF<br />
<br />
#Defaults set_home<br />
# If enabled and sudo is invoked with the -s option the HOME environment variable will be set<br />
# to the home directory of the target user (which is root unless the -u option is used). So set_home is only<br />
# effective for configs where either env_reset is disabled or HOME is present in the env_keep list. Default: OFF<br />
<br />
#Defaults set_logname<br />
# Normally, sudo will set the LOGNAME, USER and USERNAME environment variables to the name<br />
# of the target user (usually root unless the -u option is given). However, since some programs ( may be desirable<br />
# to change this behavior. This can be done by negating the set_logname option. Note that if the env_reset option<br />
# has not been disabled, entries in the env_keep list will override<br />
<br />
#Defaults set_utmp<br />
# When enabled, sudo will create an entry in the utmp (or utmpx) file when a pseudo-tty is<br />
# allocated. A pseudo-tty is allocated by sudo when the log_input, log_output or use_pty flags are e the tty, time,<br />
# type and pid fields updated. Default: ON<br />
<br />
#Defaults setenv<br />
# Allow the user to disable the env_reset option from the command line via the -E option.<br />
# Additionally, environment variables set via the command line are not subject to the restrictions impo variables<br />
# in this manner. Default: OFF<br />
<br />
#Defaults shell_noargs<br />
# If set and sudo is invoked with no arguments it acts as if the -s option had been given.<br />
# That is, it runs a shell as root (the shell is determined by the SHELL environment variable if is off by default.<br />
<br />
#Defaults stay_setuid<br />
# Normally, when sudo executes a command the real and effective UIDs are set to the target<br />
# user (root by default). This option changes that behaviour such that the real UID is left as the systems that<br />
# disable some potentially dangerous functionality when a program is run setuid. This option is only effective on<br />
# systems with either the setreuid() or setresuid() function. This flag<br />
<br />
#Defaults targetpw<br />
# If set, sudo will prompt for the password of the user specified by the -u option (defaults to root) instead<br />
# of the password of the invoking user. In addition, the timestamp file name will passwd database as an argument<br />
# to the -u option. Default: OFF<br />
<br />
#Defaults tty_tickets<br />
# If set, users must authenticate on a per-tty basis. With this flag enabled, sudo will<br />
# use a file named for the tty the user is logged in on in the user's time stamp directory.<br />
<br />
#Defaults umask_override<br />
# If set, sudo will set the umask as specified by sudoers without modification. This makes<br />
# it possible to specify a more permissive umask in sudoers than the user's own umask and match user's umask and what<br />
# is specified in sudoers. Default: OFF<br />
<br />
#Defaults use_pty<br />
# If set, sudo will run the command in a pseudo-pty even if no I/O logging is being gone.<br />
# A malicious program run under sudo could conceivably fork a background process that retains to the u that impossible.<br />
# Default: OFF<br />
<br />
#Defaults utmp_runas<br />
# If set, sudo will store the name of the runas user when updating the utmp (or utmpx) file.<br />
# By default, sudo stores the name of the invoking user. Default: OFF<br />
<br />
#Defaults visiblepw<br />
# By default, sudo will refuse to run if the user must enter a password but it is not possible to disable echo on the <br />
# terminal. If the visiblepw flag is set, sudo will prompt for a password even when it would be visible on the screen. <br />
# This makes it possible to run things like "rsh somehost sudo ls" since rsh(1) does not allocate a tty. Default: OFF<br />
<br />
#Defaults closefrom<br />
# Before it executes a command, sudo will close all open file descriptors other than standard<br />
# input, standard output and standard error (ie: file descriptors 0-2).<br />
<br />
#Defaults passwd_tries<br />
# The number of tries a user gets to enter his/her password before sudo logs the failure<br />
# and exits. The default is 3.<br />
<br />
#Defaults loglinelen<br />
# Number of characters per line for the file log. This value is used to decide when to wrap<br />
# lines for nicer log files. This has no effect on the syslog log file, only the file log.<br />
<br />
#Defaults passwd_timeout<br />
# Number of minutes before the sudo password prompt times out, or 0 for no timeout.<br />
# The timeout may include a fractional component if minute granularity is insufficient, for example 2<br />
<br />
#Defaults timestamp_timeout<br />
# Number of minutes that can elapse before sudo will ask for a passwd again. The timeout<br />
# may include a fractional component if minute granularity is insufficient, for example 2.5. timestamp will never expire.<br />
# This can be used to allow users to create or delete their own timestamps via sudo -v and sudo -k respectively.<br />
<br />
#Defaults umask<br />
# Umask to use when running the command. Negate this option or set it to 0777 to preserve<br />
# the user's umask. The actual umask that is used will be the union of the user's umask and the value o running<br />
# a command. Note on systems that use PAM, the default PAM configuration may specify its own umask which will<br />
# override the value set in sudoers.<br />
<br />
#Defaults badpass_message<br />
# Message that is displayed if a user enters an incorrect password. The default is Sorry,<br />
# try again. unless insults are enabled.<br />
<br />
#Defaults editor<br />
# A colon (':') separated list of editors allowed to be used with visudo. visudo will choose<br />
# the editor that matches the user's EDITOR environment variable if possible, or the first editor in<br />
<br />
#Defaults iolog_dir<br />
# The top-level directory to use when constructing the path name for the input/output log<br />
# directory. Only used if the log_input or log_output options are enabled or when the LOG_INPUT or L directory.<br />
# The default is "/var/log/sudo-io". The following percent (%) escape sequences are supported:<br />
# %{seq} - expanded to base-36 sequence number, such as 0100A5, to form a new directory, e.g. 01/00/A5<br />
# %{user} - expanded to the invoking user's login name<br />
# %{group} - expanded to the name of the invoking user's real group ID<br />
# %{runas_user} - expanded to the login name of the user the command will be run as (e.g. root)<br />
# %{runas_group} - expanded to the group name of the user the command will be run as (e.g. wheel)<br />
# %{hostname} - expanded to the local host name without the domain name<br />
# %{command} - expanded to the base name of the command being run In addition, any escape sequences supported by<br />
# strftime() function will be expanded. To include a literal % character, the string %% should be used.<br />
<br />
#Defaults iolog_file<br />
# The path name, relative to iolog_dir, in which to store input/output logs when the log_input or log_output options are<br />
# enabled or when the LOG_INPUT or LOG_OUTPUT tags are present for a See the iolog_dir option above for a list of<br />
# supported percent (%) escape sequences. In addition to the escape sequences, path names that end in six or more Xs will<br />
# have the Xs replaced with a unique combination of digits and letters, similar to the mktemp() function.<br />
<br />
#Defaults mailsub<br />
# Subject of the mail sent to the mailto user. The escape %h will expand to the host name of<br />
# the machine. Default is *** SECURITY information for %h ***.<br />
<br />
#Defaults noexec_file<br />
# This option is no longer supported. The path to the noexec file should now be set in the /etc/sudo.conf file.<br />
<br />
#Defaults passprompt<br />
# The default prompt to use when asking for a password; can be overridden via the -p option or the SUDO_PROMPT<br />
# environment variable. The following percent (%) escape sequences are supported:<br />
# %H - expanded to the local host name including the domain (only if the host name is fqdn or fqdn option is set)<br />
# %h - expanded to the local host name without the domain name<br />
# %p - expanded to the user whose password is being asked for (respects the rootpw, targetpw and runaspw flags)<br />
# %U - expanded to the login name of the user the command will be run as (defaults to root)<br />
# %u - expanded to the invoking user's login name<br />
# %% - two consecutive % characters are collapsed into a single % character<br />
# The default value is Password:.<br />
<br />
#Defaults runas_default<br />
# The default user to run commands as if the -u option is not specified on the command line. This defaults to root.<br />
<br />
#Defaults syslog_badpri<br />
# Syslog priority to use when user authenticates unsuccessfully. Defaults to alert.<br />
# alert, crit, debug, emerg, err, info, notice, and warning.<br />
<br />
#Defaults syslog_goodpri<br />
# Syslog priority to use when user authenticates successfully. Defaults to notice. See syslog_badpri for the priorities.<br />
<br />
#Defaults sudoers_locale<br />
# Locale to use when parsing the sudoers file, logging commands, and sending email.<br />
# Note that changing the locale may affect how sudoers is interpreted. Defaults to "C".<br />
<br />
#Defaults timestampdir<br />
# The directory in which sudo stores its timestamp files. The default is /var/db/sudo.<br />
<br />
#Defaults timestampowner<br />
# The owner of the timestamp directory and the timestamps stored therein. The default is root.<br />
<br />
#Defaults env_file<br />
# The env_file option specifies the fully qualified path to a file containing variables to<br />
# be set in the environment of the program being run. Entries in this file should either be of the f quotes.<br />
# Variables in this file are subject to other sudo environment settings such as env_keep and env_check.<br />
<br />
#Defaults exempt_group<br />
# Users in this group are exempt from password and PATH requirements. The group name specified should not include<br />
# a % prefix. This is not set by default.<br />
<br />
#Defaults group_plugin<br />
# A string containing a sudoers group plugin with optional arguments. This can be used to implement support for the<br />
# nonunix_group syntax described earlier. The string should consist of configuration arguments the plugin requires.<br />
# These arguments (if any) will be passed to the plugin's initialization function. If arguments are present, the<br />
# string must be enclosed in double quote For example, given /etc/sudo-group, a group file in Unix group format,<br />
# the sample group plugin can be used: Defaults group_plugin="sample_group.so /etc/sudo-group"<br />
# For more information see sudo_plugin(5).<br />
<br />
#Defaults lecture<br />
# This option controls when a short lecture will be printed along with the password prompt. The default value is once.<br />
# It has the following possible values:<br />
# always - Always lecture the user.<br />
# never - Never lecture the user.<br />
# once - Only lecture the user the first time they run sudo.<br />
# If no value is specified, a value of once is implied. Negating the option results in a value of never being used.<br />
<br />
#Defaults lecture_file<br />
# Path to a file containing an alternate sudo lecture that will be used in place of the standard lecture if the named<br />
# file exists. By default, sudo uses a built-in lecture.<br />
<br />
#Defaults listpw<br />
# This option controls when a password will be required when a user runs sudo with the -l option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD set to avoid entering a pass.<br />
# always - The user must always enter a password to use the -l option.<br />
# any - At least one of the user's sudoers entries for the current host must have the NOPASSWD set to avoid pass.<br />
# never - The user need never enter a password to use the -l option.<br />
# If no value is specified, a value of any is implied. The default value is any.<br />
<br />
#Defaults logfile<br />
# Path to the sudo log file (not the syslog log file). Setting a path turns on logging to a file;<br />
# negating this option turns it off. By default, sudo logs via syslog.<br />
<br />
#Defaults mailerflags<br />
# Flags to use when invoking mailer. Defaults to -t.<br />
<br />
#Defaults mailerpath<br />
# Path to mail program used to send warning mail. Defaults to the path to sendmail found at configure time.<br />
<br />
#Defaults mailfrom<br />
# Address to use for the "from" address when sending warning and error mail. The address should<br />
# be enclosed in double quotes (") to protect against sudo interpreting the @ sign.<br />
<br />
#Defaults mailto<br />
# Address to send warning and error mail to. The address should be enclosed in double quotes<br />
# (") to protect against sudo interpreting the @ sign. Defaults to root.<br />
<br />
#Defaults secure_path<br />
# Path used for every command run from sudo. If you don't trust the people running sudo to have a sane PATH environment<br />
# variable you may want to use this. Another use is if you want to option are not affected by secure_path.<br />
# This option is not set by default.<br />
<br />
#Defaults syslog<br />
# Syslog facility if syslog is being used for logging (negate to disable syslog logging). Defaults to auth.<br />
# authpriv (if OS supports it), auth, daemon, user, local0, local1, local2, local3, local4, local5, local6, and local7.<br />
<br />
#Defaults verifypw<br />
# This option controls when a password will be required when a user runs sudo with the -v option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD flag to avoid pw.<br />
# always - The user must always enter a password to use the -v option.<br />
# any - At least one of the user's sudoers entries for the current host must have NOPASSWD to avoid pw.<br />
# never - The user need never enter a password to use the -v option<br />
# If no value is specified, a value of all is implied. Negating the option results in a value of never being used.<br />
# The default value is all.<br />
<br />
#Defaults env_check<br />
# Environment variables to be removed from the user's environment if the variable's value contains % or / characters.<br />
# This can be used to guard against printf-style format vulnerabilities value without double-quotes. The list can be<br />
# replaced, added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively. Regardless of<br />
# whether the env_reset option is ena they pass the aforementioned check. The default list of environment variables<br />
# to check is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_delete<br />
# Environment variables to be removed from the user's environment when the env_reset option is not in effect. The<br />
# argument may be a double-quoted, space-separated list or a single value w +=, -=, and ! operators respectively.<br />
# The default list of environment variables to remove is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_keep<br />
# Environment variables to be preserved in the user's environment when the env_reset option is in effect. This<br />
# allows fine-grained control over the environment sudo-spawned processes will r quotes. The list can be replaced,<br />
# added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively.</nowiki>}}</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Sudo&diff=281533Sudo2013-11-05T15:24:20Z<p>Hunterthomson: /* Harden with Sudo Example */ One more typo</p>
<hr />
<div>[[Category:Security]]<br />
[[cs:Sudo]]<br />
[[es:Sudo]]<br />
[[fr:Sudo]]<br />
[[it:Sudo]]<br />
[[ja:Sudo]]<br />
[[ru:Sudo]]<br />
[[sr:Sudo]]<br />
[[tr:Sudo]]<br />
[[uk:Sudo]]<br />
[[zh-CN:Sudo]]<br />
{{Article summary start}}<br />
{{Article summary text|An overview of the popular privilege escalation utility.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Access control overview}}}}<br />
{{Article summary end}}<br />
<br />
[http://www.gratisoft.us/sudo/ sudo] ("substitute user do") allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments.<br />
<br />
== Rationale ==<br />
<br />
Sudo is an alternative to [[su]] for running commands as root. Unlike [[su]], which launches a root shell that allows all further commands root access, sudo instead grants temporary privilege escalation to a single command. By enabling root privileges only when needed, sudo usage reduces the likelyhood that a typo or a bug in an invoked command will ruin the system.<br />
Sudo can also be used to run commands as other users; additionally, sudo logs all commands and failed access attempts for security auditing.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|sudo}} package, available in the [[Official Repositories|official repositories]]:<br />
<br />
# pacman -S sudo<br />
<br />
To begin using {{ic|sudo}} as a non-privileged user, it must be properly configured. So make sure you read the configuration section.<br />
<br />
== Usage ==<br />
<br />
With sudo, users can prefix commands with {{ic|sudo}} to run them with superuser (or other) privileges.<br />
<br />
For example, to use pacman:<br />
<br />
$ sudo pacman -Syu<br />
<br />
See the [http://www.gratisoft.us/sudo/man/sudo.html sudo manual] for more information.<br />
<br />
== Configuration ==<br />
<br />
=== View current settings ===<br />
<br />
Run {{ic|sudo -ll}} to print out the current sudo configuration.<br />
<br />
=== Using visudo ===<br />
<br />
The configuration file for sudo is {{ic|/etc/sudoers}}. It should '''always''' be edited with the {{ic|visudo}} command. {{ic|visudo}} locks the {{ic|sudoers}} file, saves edits to a temporary file, and checks that file's grammar before copying it to {{ic|/etc/sudoers}}.<br />
<br />
{{Warning|It is imperative that {{ic|sudoers}} be free of syntax errors! Any error makes sudo unusable. '''Always''' edit it with {{ic|visudo}} to prevent errors.}}<br />
<br />
The default editor for visudo is {{ic|vi}}. It will be used if you do not specify another editor, by setting either VISUAL or EDITOR environment variables (used in that order) to the desired editor, e.g. {{ic|nano}}. The command is run as root:<br />
<br />
# EDITOR=nano visudo<br />
<br />
You can permanently change the setting for your user to e.g. {{ic|nano}} by appending:<br />
<br />
export EDITOR=nano<br />
<br />
to your {{ic|~/.bashrc}} file. Note that this won't take effect for already-running shells.<br />
<br />
To change the editor of choice permanently system-wide only for {{ic|visudo}}, add the following line to {{ic|/etc/sudoers}} where {{ic|nano}} is your prefered editor:<br />
<br />
# Reset environment by default<br />
Defaults env_reset<br />
# Set default EDITOR to nano, and do not allow visudo to use EDITOR/VISUAL.<br />
Defaults editor=/usr/bin/nano, !env_editor<br />
<br />
=== Example Entries ===<br />
<br />
To allow a user to gain full root privileges when he/she precedes a command with {{ic|sudo}}, add the following line:<br />
<br />
USER_NAME ALL=(ALL) ALL<br />
<br />
To allow a user to run all commands as any user but only the machine with hostname HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=(ALL) ALL<br />
<br />
To allow members of group {{ic|wheel}} sudo access:<br />
<br />
%wheel ALL=(ALL) ALL<br />
<br />
To disable asking for a password for user USER_NAME:<br />
<br />
Defaults:USER_NAME !authenticate<br />
<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=/usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
{{note| the most customized option should go at the end of the file, as the later lines overrides the previous ones. In particular such a line should be after the {{ic|%wheel}} line if your user is in this group.}}<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME without password:<br />
USER_NAME HOST_NAME= NOPASSWD: /usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
<br />
A detailed sudoers example can be found [http://www.gratisoft.us/sudo/sample.sudoers here]. Otherwise, see the [http://www.gratisoft.us/sudo/man/sudoers.html sudoers manual] for detailed information.<br />
<br />
=== Sudoers default file permissions ===<br />
<br />
The owner and group for the sudoers file must both be 0. The file permissions must be set to 0440. These permissions are set by default, but if you accidentally change them, they should be changed back immediately or sudo will fail.<br />
<br />
# chown -c root:root /etc/sudoers<br />
# chmod -c 0440 /etc/sudoers<br />
<br />
=== Password cache timeout ===<br />
<br />
Users may wish to change the default timeout before the cached password expires. This is accomplished with the timestamp_timeout option in {{ic|/etc/sudoers}} which is in minutes.<br />
Set timeout to 20 minutes.<br />
<br />
Defaults:USER_NAME timestamp_timeout=20<br />
<br />
{{Tip|To ensure sudo always asks for a password, set the timeout to 0. To ensure the password never times out, set to less than 0.}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== File example ===<br />
<br />
This example is especially helpful for those using terminal multiplexers like screen, tmux, or ratpoison, and those using sudo from scripts/cronjobs:<br />
<br />
{{hc|/etc/sudoers|<nowiki><br />
Cmnd_Alias WHEELER = /usr/bin/lsof, /bin/nice, /bin/ps, /usr/bin/top, /usr/local/bin/nano, /usr/bin/ss, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync<br />
Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/kill, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
Cmnd_Alias EDITS = /usr/bin/vim, /usr/bin/nano, /usr/bin/cat, /usr/bin/vi<br />
Cmnd_Alias ARCHLINUX = /usr/bin/gparted, /usr/bin/pacman<br />
<br />
root ALL = (ALL) ALL<br />
USER_NAME ALL = (ALL) ALL, NOPASSWD: WHEELER, NOPASSWD: PROCESSES, NOPASSWD: ARCHLINUX, NOPASSWD: EDITS<br />
<br />
Defaults !requiretty, !tty_tickets, !umask<br />
Defaults visiblepw, path_info, insults, lecture=always<br />
Defaults loglinelen = 0, logfile =/var/log/sudo.log, log_year, log_host, syslog=auth<br />
Defaults mailto=webmaster@foobar.com, mail_badpass, mail_no_user, mail_no_perms<br />
Defaults passwd_tries = 8, passwd_timeout = 1<br />
Defaults env_reset, always_set_home, set_home, set_logname<br />
Defaults !env_editor, editor="/usr/bin/vim:/usr/bin/vi:/usr/bin/nano"<br />
Defaults timestamp_timeout=360<br />
Defaults passprompt="Sudo invoked by [%u] on [%H] - Cmd run as %U - Password for user %p:"<br />
</nowiki>}}<br />
<br />
=== Enabling Tab-completion in Bash ===<br />
<br />
{{ic|Tab}}-completion, by default, will not work when a user is initially added to the sudoers file. For example, normally john only needs to type:<br />
<br />
$ fire<{{ic|Tab}}><br />
<br />
and the shell will complete the command for him as:<br />
<br />
$ firefox<br />
<br />
If, however, john is added to the sudoers file and he types:<br />
<br />
$ sudo fire<{{ic|Tab}}><br />
<br />
the shell will do nothing.<br />
<br />
To enable {{ic|Tab}}-completion with sudo, [[pacman|install]] the {{pkg|bash-completion}} package from the [[Official Repositories|official repositories]]. see [[bash#Tab_completion]] for more information.<br />
<br />
Alternatively, add the following to your {{ic|~/.bashrc}}:<br />
<br />
complete -cf sudo<br />
<br />
=== Run X11 apps using sudo ===<br />
<br />
To allow sudo to start graphical application in X11, you need to add:<br />
<br />
Defaults env_keep += "HOME"<br />
<br />
to visudo.<br />
<br />
=== Disable per-terminal sudo ===<br />
<br />
{{Warning|This will let any process use your sudo session.}}<br />
<br />
If you are annoyed by sudo's defaults that require you to enter your password every time you open a new terminal, disable '''tty_tickets''':<br />
<br />
Defaults !tty_tickets<br />
<br />
=== Environment variables ===<br />
<br />
If you have a lot of environment variables, or you export your proxy settings via {{ic|1=export http_proxy="..."}}, when using sudo these variables do not get passed to the root account unless you run sudo with the {{ic|-E}} option.<br />
<br />
$ sudo -E pacman -Syu<br />
<br />
The recommended way of preserving environment variables is to append them to {{ic|env_keep}}:<br />
{{hc|/etc/sudoers|<nowiki><br />
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"<br />
</nowiki>}}<br />
<br />
=== Passing aliases ===<br />
<br />
If you use a lot of aliases, you might have noticed that they do not carry over to the root account when using sudo. However, there is an easy way to make them work. Simply add the following to your {{ic|~/.bashrc}} or {{ic|/etc/bash.bashrc}}:<br />
<br />
alias sudo='sudo '<br />
<br />
=== Insults ===<br />
<br />
Users can configure sudo to display clever insults when an incorrect password is entered instead of printing the default "wrong password" message. Find the Defaults line in {{ic|/etc/sudoers}} and append "insults" after a comma to existing options. The final result might look like this:<br />
<br />
#Defaults specification<br />
Defaults insults<br />
<br />
To test, type {{ic|sudo -K}} to end the current session and let sudo ask for the password again.<br />
<br />
=== Root password ===<br />
<br />
Users can configure sudo to ask for the root password instead of the user password by adding "rootpw" to the Defaults line in {{ic|/etc/sudoers}}:<br />
<br />
Defaults timestamp_timeout=0,rootpw<br />
<br />
=== Disable root login ===<br />
<br />
{{Warning|Arch Linux is not fine-tuned to run with a disabled root account. Users may encounter problems with this method.}}<br />
<br />
With sudo installed and configured, users may wish to disable the root login. Without root, attackers must first guess a user name configured as a sudoer as well as the user password.<br />
<br />
{{Warning|Ensure a user is properly configured as a sudoer ''before'' disabling the root account!}}<br />
<br />
The account can be locked via {{ic|passwd}}:<br />
<br />
# passwd -l root<br />
<br />
A similar command unlocks root.<br />
<br />
$ sudo passwd -u root<br />
<br />
Alternatively, edit {{ic|/etc/shadow}} and replace the root's encrypted password with "!":<br />
<br />
root:!:12345::::::<br />
<br />
To enable root login again:<br />
<br />
$ sudo passwd root<br />
<br />
==== kdesu ====<br />
<br />
kdesu may be used under KDE to launch GUI applications with root privileges. It is possible that by default kdesu will try to use su even if the root account is disabled. Fortunately one can tell kdesu to use sudo instead of su. Create/edit the file {{ic|~/.kde4/share/config/kdesurc}}:<br />
<br />
[super-user-command]<br />
super-user-command=sudo<br />
<br />
==== PolicyKit ====<br />
<br />
When disabling the root account, it is necessary to change the [[PolicyKit]] configuration for local authorization to reflect that. The default is to ask for the root password, so that must be changed. With polkit-1, this can be achieved by editing {{ic|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf}} so that {{ic|1=AdminIdentities=unix-user:0}} is replaced with something else, depending on the system configuration. It can be a list of users and groups, for example:<br />
<br />
AdminIdentities=unix-group:wheel<br />
<br />
or<br />
<br />
AdminIdentities=unix-user:me;unixuser:mom;unix-group:wheel<br />
<br />
For more information, see {{ic|man pklocalauthority}}.<br />
<br />
==== NetworkManager ====<br />
<br />
Even with the above PolicyKit configuration you still need to configure a policy for NetworkManager. This is documented on the [[NetworkManager#Can.27t_edit_connections_as_normal_user|NetworkManager]] page of this wiki.<br />
<br />
=== Harden with Sudo Example ===<br />
<br />
Lets say you create 3 users: admin, devel, and Joe<br />
admin is used for journalctl, systemctl, mount, kill, and iptables.<br />
devel is used for installing packages, and editing config's<br />
Joe is the user you log in with. Let's let him reboot, shutdown, and use netctl<br />
<br />
Edit /etc/pam.d/su and /etc/pam.d/su-1<br />
Require user be in the wheel group, but don't put anyone in it.<br />
#%PAM-1.0<br />
auth sufficient pam_rootok.so<br />
# Uncomment the following line to implicitly trust users in the "wheel" group.<br />
#auth sufficient pam_wheel.so trust use_uid<br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
auth required pam_unix.so<br />
account required pam_unix.so<br />
session required pam_unix.so<br />
<br />
Limit SSH login to the 'ssh' group, Only put Joe in it<br />
groupadd -r ssh<br />
gpasswd -a Joe ssh<br />
echo 'AllowGroups ssh' >> /etc/ssh/sshd_config<br />
systemctl restart sshd.service<br />
<br />
Lets add users to other goups.<br />
for g in network power ;do ;gpasswd -a Joe $g ;done<br />
for g in network power disk ;do ;gpasswd -a Joe $g ;done<br />
<br />
Set permissions on configs so devel can edit them.<br />
chown -R devel:root /etc/{http,openvpn,cups,zsh,vim,screenrc}<br />
<br />
Cmnd_Alias POWER = /usr/bin/shutdown -h now, /usr/bin/halt, /usr/bin/poweroff, /usr/bin/reboot<br />
Cmnd_Alias DISK = /usr/bin/mount, /usr/bin/umount<br />
Cmnd_Alias SYSTEMD = /usr/bin/journalctl, /usr/bin/systemctl<br />
Cmnd_Alias KILL = /usr/bin/kill<br />
Cmnd_Alias PKGMAN = /usr/bin/pacman<br />
Cmnd_Alias NETWORK = /usr/bin/netctl<br />
Cmnd_Alias SU_ADMIN = /usr/bin/su – admin<br />
Cmnd_Alias SU_DEVEL = /usr/bin/su – devel<br />
%power ALL = (root) NOPASSWD: POWER<br />
%network ALL = (root) NETWORK<br />
root ALL = (ALL) ALL<br />
admin ALL = (root) SYSTEMD, KILL<br />
devel ALL = (root) PKGMAN<br />
Joe ALL = (root) SU_ADMIN, SU_DEVEL <br />
<br />
With this setup, you will almost never need to login as the Root user.<br />
<br />
Joe can connect to his home WiFi<br />
sudo -- netctl start home<br />
sudo -- poweroff<br />
<br />
Joe can not use netctl as any other user like admin...<br />
sudo -u admin -- netctl start home<br />
<br />
When Joe needs to use journalctl or kill run away process he can switch to that user<br />
sudo su -- admin<br />
sudo su -- devel<br />
<br />
But not Root<br />
sudo su -- root<br />
<br />
If joe want to start a gnu-screen session as admin he can do it like this<br />
sudo su -- admin<br />
admin% chown admin:tty `echo $TTY`<br />
admin% screen<br />
<br />
== Troubleshooting ==<br />
<br />
=== SSH TTY Issues ===<br />
<br />
SSH does not allocate a tty by default when running a remote command. Without a tty, sudo cannot disable echo when prompting for a password. You can use ssh's {{ic|-tt}} option to force it to allocate a tty (or {{ic|-t}} twice).<br />
<br />
The {{ic|Defaults}} option {{ic|requiretty}} only allows the user to run sudo if they have a tty.<br />
<br />
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear text. You have to run "ssh -t hostname sudo <cmd>".<br />
#<br />
#Defaults requiretty<br />
<br />
=== Display User Privileges ===<br />
<br />
You can find out what privileges a particular user has with the following command:<br />
<br />
$ sudo -lU yourusename<br />
<br />
Or view your own with:<br />
<br />
{{hc|$ sudo -l|<nowiki><br />
Matching Defaults entries for yourusename on this host:<br />
loglinelen=0, logfile=/var/log/sudo.log, log_year, syslog=auth, mailto=webmaster@gmail.com, mail_badpass, mail_no_user,<br />
mail_no_perms,env_reset, always_set_home, tty_tickets, lecture=always, pwfeedback, rootpw, set_home<br />
<br />
User yourusename may run the following commands on this host:<br />
<br />
(ALL) ALL<br />
(ALL) NOPASSWD: /usr/bin/lsof, /bin/nice, /usr/bin/su, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync, /usr/bin/strace,<br />
(ALL) /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
(ALL) /usr/bin/gparted, /usr/bin/pacman<br />
(ALL) /usr/local/bin/synergyc, /usr/local/bin/synergys<br />
(ALL) /usr/bin/vim, /usr/bin/nano, /usr/bin/cat<br />
(root) NOPASSWD: /usr/local/bin/synergyc</nowiki>}}<br />
<br />
=== Permissive Umask ===<br />
<br />
Sudo will union the user's [[umask]] value with its own umask (which defaults to 0022). This prevents sudo from creating files with more open permissions than the user's umask allows. While this is a sane default if no custom umask is in use, this can lead to situations where a utility run by sudo may create files with different permissions than if run by root directly. If errors arise from this, sudo provides a means to fix the umask, even if the desired umask is more permissive than the umask that the user has specified. Adding this (using {{ic|visudo}}) will override sudo's default behavior:<br />
<br />
Defaults umask = 0022<br />
Defaults umask_override<br />
<br />
This sets sudo's umask to root's default umask (0022) and overrides the default behavior, always using the indicated umask regardless of what umask the user as set.<br />
<br />
<br />
=== Defaults Skeleton ===<br />
<br />
The authors site has a [http://www.gratisoft.us/sudo/sudoers.man.html#sudoers_options list of all the options] that can be used with the {{ic|Defaults}} command in the {{ic|/etc/sudoers}} file.<br />
<br />
The full list of options ''(parsed from the version 1.8.7 source code)'' is below in a format optimized for copying and pasting into your sudoers files for quick editing.<br />
<br />
{{bc|<nowiki>#Defaults always_set_home<br />
# If enabled, sudo will set the HOME environment variable to the home directory of the target user<br />
# (which is root unless the -u option is used). This effectively means that the -H option<br />
# always_set_home is only effective for configurations where either env_reset is disabled or HOME is present<br />
# in the env_keep list. Default: OFF<br />
<br />
#Defaults authenticate<br />
# If set, users must authenticate themselves via a password (or other means of authentication)<br />
# before they may run commands. This default may be overridden via the PASSWD and NOPASSWD<br />
<br />
#Defaults closefrom_override<br />
# If set, the user may use sudo's -C option which overrides the default starting<br />
# point at which sudo begins closing open file descriptors. Default: OFF<br />
<br />
#Defaults compress_io<br />
# If set, and sudo is configured to log a command's input or output, the I/O logs will be<br />
# compressed using zlib. This flag is on by default when sudo is compiled with zlib support.<br />
<br />
#Defaults env_editor<br />
# If set, visudo will use the value of the EDITOR or VISUAL environment variables before falling back on the default<br />
# editor list. Note that this may create a security hole as it allows th separated list of editors in the editor<br />
# variable. visudo will then only use the EDITOR or VISUAL if they match a value specified in editor. On by default.<br />
<br />
#Defaults env_reset<br />
# If set, sudo will run the command in a minimal environment containing the TERM, PATH, HOME, MAIL, SHELL, LOGNAME,<br />
# USER, USERNAME and SUDO_* variables. Any variables in the caller's env in the file specified by the env_file<br />
# option (if any). The default contents of the env_keep and env_check lists are displayed when sudo is run by<br />
# root with the -V option.<br />
<br />
#Defaults fast_glob<br />
# Normally, sudo uses the glob(3) function to do shell-style globbing when matching path names.<br />
# However, since it accesses the file system, glob(3) can take a long time to complete for som (automounted).<br />
# The fast_glob option causes sudo to use the fnmatch(3) function, which does not access the file system to do<br />
# its matching. The disadvantage of fast_glob is that it is unable to ma names that include globbing characters<br />
# are used with the negation operator, '!', as such rules can be trivially bypassed. As such, this option should<br />
# not be used when sudoers contains rules that<br />
<br />
#Defaults fqdn<br />
# Set this flag if you want to put fully qualified host names in the sudoers file. I.e., instead of myhost you<br />
# would use myhost.mydomain.edu. You may still use the short form if you wish (and sudo unusable if DNS stops<br />
# working (for example if the machine is not plugged into the network). Also note that you must use the<br />
# host's official name as DNS knows it. That is, you may not use a all aliases from DNS. If your machine's<br />
# host name (as returned by the hostname command) is already fully qualified you shouldn't need to set fqdn.<br />
# Default: OFF<br />
<br />
#Defaults ignore_dot<br />
# If set, sudo will ignore '.' or '' (current dir) in the PATH environment variable; the PATH<br />
# itself is not modified. Default: OFF<br />
<br />
#Defaults ignore_local_sudoers<br />
# If set via LDAP, parsing of /etc/sudoers will be skipped. This is intended for Enterprises that wish to prevent<br />
# the usage of local sudoers files so that only LDAP is used. /etc/sudoers does not even need to exist.<br />
# Since this option tells sudo how to behave when no specific LDAP entries have been matched, this sudo<br />
# Option is only meaningful for the cn=default<br />
<br />
#Defaults insults<br />
# If set, sudo will insult users when they enter an incorrect password. Default: OFF<br />
<br />
#Defaults log_host<br />
# If set, the host name will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults log_input<br />
# If set, sudo will run the command in a pseudo tty and log all user input. If the standard<br />
# input is not connected to the user's tty, due to I/O redirection or because the command is part Input is logged<br />
# to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that<br />
# is included in the normal sudo log line, prefixed with TSID=. Note that user input may contain sensitive<br />
# information such as passwords (even if they are not echoed to the screen), which will be stored in the log file<br />
# unencrypted.<br />
<br />
#Defaults log_output<br />
# If set, sudo will run the command in a pseudo tty and log all output that is sent to the<br />
# screen, similar to the script(1) command. If the standard output or standard error is not connec is also captured and<br />
# stored in separate log files. Output is logged to the directory specified by the iolog_dir option (/var/log/sudo-io<br />
# by default) using a unique session ID that is included in the normal sudo log line, prefixed with TSID=. The Output<br />
# logs may be viewed with the sudoreplay(8) utility, which can also be used to list or search the available logs.<br />
<br />
#Defaults log_year<br />
# If set, the four-digit year will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults long_otp_prompt<br />
# When validating with a One Time Password (OTP) scheme such as S/Key or OPIE, a two-line<br />
# prompt is used to make it easier to cut and paste the challenge to a local window<br />
<br />
#Defaults mail_always<br />
# Send mail to the mailto user every time a users runs sudo. Default: OFF<br />
<br />
#Defaults mail_badpass<br />
# Send mail to the mailto user if the user running sudo does not enter the correct password.<br />
# Default: OFF<br />
<br />
#Defaults mail_no_host<br />
# If set, mail will be sent to the mailto user if the invoking user exists in the sudoers<br />
# file, but is not allowed to run commands on the current host. Default: OFF<br />
<br />
#Defaults mail_no_perms<br />
# If set, mail will be sent to the mailto user if the invoking user is allowed to use sudo<br />
# but the command they are trying is not listed in their sudoers file entry or is explicitly denied<br />
<br />
#Defaults mail_no_user<br />
# If set, mail will be sent to the mailto user if the invoking user is not in the sudoers file.<br />
# Default: ON<br />
<br />
#Defaults noexec<br />
# If set, all commands run via sudo will behave as if the NOEXEC tag has been set, unless overridden<br />
# by a EXEC tag. See the description of NOEXEC and EXEC below as well as the "PREVENTING SHE<br />
<br />
#Defaults path_info<br />
# Normally, sudo will tell the user when a command could not be found in their PATH environment<br />
# variable. Some sites may wish to disable this as it could be used to gather information on t the executable is<br />
# simply not in the user's PATH, sudo will tell the user that they are not allowed to run it, which can be confusing.<br />
# Default: ON<br />
<br />
#Defaults passprompt_override<br />
# The password prompt specified by passprompt will normally only be used if the password prompt provided by<br />
# systems such as PAM matches the string "Password:"<br />
<br />
#Defaults preserve_groups<br />
# By default, sudo will initialize the group vector to the list of groups the target<br />
# user is in. When preserve_groups is set, the user's existing group vector is left unaltered.<br />
<br />
#Defaults pwfeedback<br />
# By default, sudo reads the password like most other Unix programs, by turning off echo<br />
# until the user hits the return (or enter) key. Some users become confused by this as it appears to the user<br />
# presses a key. Note that this does have a security impact as an onlooker may be able to determine the length of<br />
# the password being entered. Default: OFF<br />
<br />
#Defaults requiretty<br />
# If set, sudo will only run when the user is logged in to a real tty. When this flag is set,<br />
# sudo can only be run from a login session and not via other means such as cron(8) or cgi-bin<br />
<br />
#Defaults root_sudo<br />
# If set, root is allowed to run sudo too. Disabling this prevents users from "chaining" sudo<br />
# commands to get a root shell by doing something like "sudo sudo /bin/sh". Note, however, that real additional<br />
# security; it exists purely for historical reasons. Default: ON<br />
<br />
#Defaults rootpw<br />
# If set, sudo will prompt for the root password instead of the password of the invoking user.<br />
# Default: OFF<br />
<br />
#Defaults runaspw<br />
# If set, sudo will prompt for the password of the user defined by the runas_default option<br />
# (defaults to root) instead of the password of the invoking user. Default: OFF<br />
<br />
#Defaults set_home<br />
# If enabled and sudo is invoked with the -s option the HOME environment variable will be set<br />
# to the home directory of the target user (which is root unless the -u option is used). So set_home is only<br />
# effective for configs where either env_reset is disabled or HOME is present in the env_keep list. Default: OFF<br />
<br />
#Defaults set_logname<br />
# Normally, sudo will set the LOGNAME, USER and USERNAME environment variables to the name<br />
# of the target user (usually root unless the -u option is given). However, since some programs ( may be desirable<br />
# to change this behavior. This can be done by negating the set_logname option. Note that if the env_reset option<br />
# has not been disabled, entries in the env_keep list will override<br />
<br />
#Defaults set_utmp<br />
# When enabled, sudo will create an entry in the utmp (or utmpx) file when a pseudo-tty is<br />
# allocated. A pseudo-tty is allocated by sudo when the log_input, log_output or use_pty flags are e the tty, time,<br />
# type and pid fields updated. Default: ON<br />
<br />
#Defaults setenv<br />
# Allow the user to disable the env_reset option from the command line via the -E option.<br />
# Additionally, environment variables set via the command line are not subject to the restrictions impo variables<br />
# in this manner. Default: OFF<br />
<br />
#Defaults shell_noargs<br />
# If set and sudo is invoked with no arguments it acts as if the -s option had been given.<br />
# That is, it runs a shell as root (the shell is determined by the SHELL environment variable if is off by default.<br />
<br />
#Defaults stay_setuid<br />
# Normally, when sudo executes a command the real and effective UIDs are set to the target<br />
# user (root by default). This option changes that behaviour such that the real UID is left as the systems that<br />
# disable some potentially dangerous functionality when a program is run setuid. This option is only effective on<br />
# systems with either the setreuid() or setresuid() function. This flag<br />
<br />
#Defaults targetpw<br />
# If set, sudo will prompt for the password of the user specified by the -u option (defaults to root) instead<br />
# of the password of the invoking user. In addition, the timestamp file name will passwd database as an argument<br />
# to the -u option. Default: OFF<br />
<br />
#Defaults tty_tickets<br />
# If set, users must authenticate on a per-tty basis. With this flag enabled, sudo will<br />
# use a file named for the tty the user is logged in on in the user's time stamp directory.<br />
<br />
#Defaults umask_override<br />
# If set, sudo will set the umask as specified by sudoers without modification. This makes<br />
# it possible to specify a more permissive umask in sudoers than the user's own umask and match user's umask and what<br />
# is specified in sudoers. Default: OFF<br />
<br />
#Defaults use_pty<br />
# If set, sudo will run the command in a pseudo-pty even if no I/O logging is being gone.<br />
# A malicious program run under sudo could conceivably fork a background process that retains to the u that impossible.<br />
# Default: OFF<br />
<br />
#Defaults utmp_runas<br />
# If set, sudo will store the name of the runas user when updating the utmp (or utmpx) file.<br />
# By default, sudo stores the name of the invoking user. Default: OFF<br />
<br />
#Defaults visiblepw<br />
# By default, sudo will refuse to run if the user must enter a password but it is not possible to disable echo on the <br />
# terminal. If the visiblepw flag is set, sudo will prompt for a password even when it would be visible on the screen. <br />
# This makes it possible to run things like "rsh somehost sudo ls" since rsh(1) does not allocate a tty. Default: OFF<br />
<br />
#Defaults closefrom<br />
# Before it executes a command, sudo will close all open file descriptors other than standard<br />
# input, standard output and standard error (ie: file descriptors 0-2).<br />
<br />
#Defaults passwd_tries<br />
# The number of tries a user gets to enter his/her password before sudo logs the failure<br />
# and exits. The default is 3.<br />
<br />
#Defaults loglinelen<br />
# Number of characters per line for the file log. This value is used to decide when to wrap<br />
# lines for nicer log files. This has no effect on the syslog log file, only the file log.<br />
<br />
#Defaults passwd_timeout<br />
# Number of minutes before the sudo password prompt times out, or 0 for no timeout.<br />
# The timeout may include a fractional component if minute granularity is insufficient, for example 2<br />
<br />
#Defaults timestamp_timeout<br />
# Number of minutes that can elapse before sudo will ask for a passwd again. The timeout<br />
# may include a fractional component if minute granularity is insufficient, for example 2.5. timestamp will never expire.<br />
# This can be used to allow users to create or delete their own timestamps via sudo -v and sudo -k respectively.<br />
<br />
#Defaults umask<br />
# Umask to use when running the command. Negate this option or set it to 0777 to preserve<br />
# the user's umask. The actual umask that is used will be the union of the user's umask and the value o running<br />
# a command. Note on systems that use PAM, the default PAM configuration may specify its own umask which will<br />
# override the value set in sudoers.<br />
<br />
#Defaults badpass_message<br />
# Message that is displayed if a user enters an incorrect password. The default is Sorry,<br />
# try again. unless insults are enabled.<br />
<br />
#Defaults editor<br />
# A colon (':') separated list of editors allowed to be used with visudo. visudo will choose<br />
# the editor that matches the user's EDITOR environment variable if possible, or the first editor in<br />
<br />
#Defaults iolog_dir<br />
# The top-level directory to use when constructing the path name for the input/output log<br />
# directory. Only used if the log_input or log_output options are enabled or when the LOG_INPUT or L directory.<br />
# The default is "/var/log/sudo-io". The following percent (%) escape sequences are supported:<br />
# %{seq} - expanded to base-36 sequence number, such as 0100A5, to form a new directory, e.g. 01/00/A5<br />
# %{user} - expanded to the invoking user's login name<br />
# %{group} - expanded to the name of the invoking user's real group ID<br />
# %{runas_user} - expanded to the login name of the user the command will be run as (e.g. root)<br />
# %{runas_group} - expanded to the group name of the user the command will be run as (e.g. wheel)<br />
# %{hostname} - expanded to the local host name without the domain name<br />
# %{command} - expanded to the base name of the command being run In addition, any escape sequences supported by<br />
# strftime() function will be expanded. To include a literal % character, the string %% should be used.<br />
<br />
#Defaults iolog_file<br />
# The path name, relative to iolog_dir, in which to store input/output logs when the log_input or log_output options are<br />
# enabled or when the LOG_INPUT or LOG_OUTPUT tags are present for a See the iolog_dir option above for a list of<br />
# supported percent (%) escape sequences. In addition to the escape sequences, path names that end in six or more Xs will<br />
# have the Xs replaced with a unique combination of digits and letters, similar to the mktemp() function.<br />
<br />
#Defaults mailsub<br />
# Subject of the mail sent to the mailto user. The escape %h will expand to the host name of<br />
# the machine. Default is *** SECURITY information for %h ***.<br />
<br />
#Defaults noexec_file<br />
# This option is no longer supported. The path to the noexec file should now be set in the /etc/sudo.conf file.<br />
<br />
#Defaults passprompt<br />
# The default prompt to use when asking for a password; can be overridden via the -p option or the SUDO_PROMPT<br />
# environment variable. The following percent (%) escape sequences are supported:<br />
# %H - expanded to the local host name including the domain (only if the host name is fqdn or fqdn option is set)<br />
# %h - expanded to the local host name without the domain name<br />
# %p - expanded to the user whose password is being asked for (respects the rootpw, targetpw and runaspw flags)<br />
# %U - expanded to the login name of the user the command will be run as (defaults to root)<br />
# %u - expanded to the invoking user's login name<br />
# %% - two consecutive % characters are collapsed into a single % character<br />
# The default value is Password:.<br />
<br />
#Defaults runas_default<br />
# The default user to run commands as if the -u option is not specified on the command line. This defaults to root.<br />
<br />
#Defaults syslog_badpri<br />
# Syslog priority to use when user authenticates unsuccessfully. Defaults to alert.<br />
# alert, crit, debug, emerg, err, info, notice, and warning.<br />
<br />
#Defaults syslog_goodpri<br />
# Syslog priority to use when user authenticates successfully. Defaults to notice. See syslog_badpri for the priorities.<br />
<br />
#Defaults sudoers_locale<br />
# Locale to use when parsing the sudoers file, logging commands, and sending email.<br />
# Note that changing the locale may affect how sudoers is interpreted. Defaults to "C".<br />
<br />
#Defaults timestampdir<br />
# The directory in which sudo stores its timestamp files. The default is /var/db/sudo.<br />
<br />
#Defaults timestampowner<br />
# The owner of the timestamp directory and the timestamps stored therein. The default is root.<br />
<br />
#Defaults env_file<br />
# The env_file option specifies the fully qualified path to a file containing variables to<br />
# be set in the environment of the program being run. Entries in this file should either be of the f quotes.<br />
# Variables in this file are subject to other sudo environment settings such as env_keep and env_check.<br />
<br />
#Defaults exempt_group<br />
# Users in this group are exempt from password and PATH requirements. The group name specified should not include<br />
# a % prefix. This is not set by default.<br />
<br />
#Defaults group_plugin<br />
# A string containing a sudoers group plugin with optional arguments. This can be used to implement support for the<br />
# nonunix_group syntax described earlier. The string should consist of configuration arguments the plugin requires.<br />
# These arguments (if any) will be passed to the plugin's initialization function. If arguments are present, the<br />
# string must be enclosed in double quote For example, given /etc/sudo-group, a group file in Unix group format,<br />
# the sample group plugin can be used: Defaults group_plugin="sample_group.so /etc/sudo-group"<br />
# For more information see sudo_plugin(5).<br />
<br />
#Defaults lecture<br />
# This option controls when a short lecture will be printed along with the password prompt. The default value is once.<br />
# It has the following possible values:<br />
# always - Always lecture the user.<br />
# never - Never lecture the user.<br />
# once - Only lecture the user the first time they run sudo.<br />
# If no value is specified, a value of once is implied. Negating the option results in a value of never being used.<br />
<br />
#Defaults lecture_file<br />
# Path to a file containing an alternate sudo lecture that will be used in place of the standard lecture if the named<br />
# file exists. By default, sudo uses a built-in lecture.<br />
<br />
#Defaults listpw<br />
# This option controls when a password will be required when a user runs sudo with the -l option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD set to avoid entering a pass.<br />
# always - The user must always enter a password to use the -l option.<br />
# any - At least one of the user's sudoers entries for the current host must have the NOPASSWD set to avoid pass.<br />
# never - The user need never enter a password to use the -l option.<br />
# If no value is specified, a value of any is implied. The default value is any.<br />
<br />
#Defaults logfile<br />
# Path to the sudo log file (not the syslog log file). Setting a path turns on logging to a file;<br />
# negating this option turns it off. By default, sudo logs via syslog.<br />
<br />
#Defaults mailerflags<br />
# Flags to use when invoking mailer. Defaults to -t.<br />
<br />
#Defaults mailerpath<br />
# Path to mail program used to send warning mail. Defaults to the path to sendmail found at configure time.<br />
<br />
#Defaults mailfrom<br />
# Address to use for the "from" address when sending warning and error mail. The address should<br />
# be enclosed in double quotes (") to protect against sudo interpreting the @ sign.<br />
<br />
#Defaults mailto<br />
# Address to send warning and error mail to. The address should be enclosed in double quotes<br />
# (") to protect against sudo interpreting the @ sign. Defaults to root.<br />
<br />
#Defaults secure_path<br />
# Path used for every command run from sudo. If you don't trust the people running sudo to have a sane PATH environment<br />
# variable you may want to use this. Another use is if you want to option are not affected by secure_path.<br />
# This option is not set by default.<br />
<br />
#Defaults syslog<br />
# Syslog facility if syslog is being used for logging (negate to disable syslog logging). Defaults to auth.<br />
# authpriv (if OS supports it), auth, daemon, user, local0, local1, local2, local3, local4, local5, local6, and local7.<br />
<br />
#Defaults verifypw<br />
# This option controls when a password will be required when a user runs sudo with the -v option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD flag to avoid pw.<br />
# always - The user must always enter a password to use the -v option.<br />
# any - At least one of the user's sudoers entries for the current host must have NOPASSWD to avoid pw.<br />
# never - The user need never enter a password to use the -v option<br />
# If no value is specified, a value of all is implied. Negating the option results in a value of never being used.<br />
# The default value is all.<br />
<br />
#Defaults env_check<br />
# Environment variables to be removed from the user's environment if the variable's value contains % or / characters.<br />
# This can be used to guard against printf-style format vulnerabilities value without double-quotes. The list can be<br />
# replaced, added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively. Regardless of<br />
# whether the env_reset option is ena they pass the aforementioned check. The default list of environment variables<br />
# to check is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_delete<br />
# Environment variables to be removed from the user's environment when the env_reset option is not in effect. The<br />
# argument may be a double-quoted, space-separated list or a single value w +=, -=, and ! operators respectively.<br />
# The default list of environment variables to remove is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_keep<br />
# Environment variables to be preserved in the user's environment when the env_reset option is in effect. This<br />
# allows fine-grained control over the environment sudo-spawned processes will r quotes. The list can be replaced,<br />
# added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively.</nowiki>}}</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Sudo&diff=281531Sudo2013-11-05T15:23:06Z<p>Hunterthomson: /* Harden with Sudo Example */ Typos</p>
<hr />
<div>[[Category:Security]]<br />
[[cs:Sudo]]<br />
[[es:Sudo]]<br />
[[fr:Sudo]]<br />
[[it:Sudo]]<br />
[[ja:Sudo]]<br />
[[ru:Sudo]]<br />
[[sr:Sudo]]<br />
[[tr:Sudo]]<br />
[[uk:Sudo]]<br />
[[zh-CN:Sudo]]<br />
{{Article summary start}}<br />
{{Article summary text|An overview of the popular privilege escalation utility.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Access control overview}}}}<br />
{{Article summary end}}<br />
<br />
[http://www.gratisoft.us/sudo/ sudo] ("substitute user do") allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments.<br />
<br />
== Rationale ==<br />
<br />
Sudo is an alternative to [[su]] for running commands as root. Unlike [[su]], which launches a root shell that allows all further commands root access, sudo instead grants temporary privilege escalation to a single command. By enabling root privileges only when needed, sudo usage reduces the likelyhood that a typo or a bug in an invoked command will ruin the system.<br />
Sudo can also be used to run commands as other users; additionally, sudo logs all commands and failed access attempts for security auditing.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|sudo}} package, available in the [[Official Repositories|official repositories]]:<br />
<br />
# pacman -S sudo<br />
<br />
To begin using {{ic|sudo}} as a non-privileged user, it must be properly configured. So make sure you read the configuration section.<br />
<br />
== Usage ==<br />
<br />
With sudo, users can prefix commands with {{ic|sudo}} to run them with superuser (or other) privileges.<br />
<br />
For example, to use pacman:<br />
<br />
$ sudo pacman -Syu<br />
<br />
See the [http://www.gratisoft.us/sudo/man/sudo.html sudo manual] for more information.<br />
<br />
== Configuration ==<br />
<br />
=== View current settings ===<br />
<br />
Run {{ic|sudo -ll}} to print out the current sudo configuration.<br />
<br />
=== Using visudo ===<br />
<br />
The configuration file for sudo is {{ic|/etc/sudoers}}. It should '''always''' be edited with the {{ic|visudo}} command. {{ic|visudo}} locks the {{ic|sudoers}} file, saves edits to a temporary file, and checks that file's grammar before copying it to {{ic|/etc/sudoers}}.<br />
<br />
{{Warning|It is imperative that {{ic|sudoers}} be free of syntax errors! Any error makes sudo unusable. '''Always''' edit it with {{ic|visudo}} to prevent errors.}}<br />
<br />
The default editor for visudo is {{ic|vi}}. It will be used if you do not specify another editor, by setting either VISUAL or EDITOR environment variables (used in that order) to the desired editor, e.g. {{ic|nano}}. The command is run as root:<br />
<br />
# EDITOR=nano visudo<br />
<br />
You can permanently change the setting for your user to e.g. {{ic|nano}} by appending:<br />
<br />
export EDITOR=nano<br />
<br />
to your {{ic|~/.bashrc}} file. Note that this won't take effect for already-running shells.<br />
<br />
To change the editor of choice permanently system-wide only for {{ic|visudo}}, add the following line to {{ic|/etc/sudoers}} where {{ic|nano}} is your prefered editor:<br />
<br />
# Reset environment by default<br />
Defaults env_reset<br />
# Set default EDITOR to nano, and do not allow visudo to use EDITOR/VISUAL.<br />
Defaults editor=/usr/bin/nano, !env_editor<br />
<br />
=== Example Entries ===<br />
<br />
To allow a user to gain full root privileges when he/she precedes a command with {{ic|sudo}}, add the following line:<br />
<br />
USER_NAME ALL=(ALL) ALL<br />
<br />
To allow a user to run all commands as any user but only the machine with hostname HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=(ALL) ALL<br />
<br />
To allow members of group {{ic|wheel}} sudo access:<br />
<br />
%wheel ALL=(ALL) ALL<br />
<br />
To disable asking for a password for user USER_NAME:<br />
<br />
Defaults:USER_NAME !authenticate<br />
<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=/usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
{{note| the most customized option should go at the end of the file, as the later lines overrides the previous ones. In particular such a line should be after the {{ic|%wheel}} line if your user is in this group.}}<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME without password:<br />
USER_NAME HOST_NAME= NOPASSWD: /usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
<br />
A detailed sudoers example can be found [http://www.gratisoft.us/sudo/sample.sudoers here]. Otherwise, see the [http://www.gratisoft.us/sudo/man/sudoers.html sudoers manual] for detailed information.<br />
<br />
=== Sudoers default file permissions ===<br />
<br />
The owner and group for the sudoers file must both be 0. The file permissions must be set to 0440. These permissions are set by default, but if you accidentally change them, they should be changed back immediately or sudo will fail.<br />
<br />
# chown -c root:root /etc/sudoers<br />
# chmod -c 0440 /etc/sudoers<br />
<br />
=== Password cache timeout ===<br />
<br />
Users may wish to change the default timeout before the cached password expires. This is accomplished with the timestamp_timeout option in {{ic|/etc/sudoers}} which is in minutes.<br />
Set timeout to 20 minutes.<br />
<br />
Defaults:USER_NAME timestamp_timeout=20<br />
<br />
{{Tip|To ensure sudo always asks for a password, set the timeout to 0. To ensure the password never times out, set to less than 0.}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== File example ===<br />
<br />
This example is especially helpful for those using terminal multiplexers like screen, tmux, or ratpoison, and those using sudo from scripts/cronjobs:<br />
<br />
{{hc|/etc/sudoers|<nowiki><br />
Cmnd_Alias WHEELER = /usr/bin/lsof, /bin/nice, /bin/ps, /usr/bin/top, /usr/local/bin/nano, /usr/bin/ss, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync<br />
Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/kill, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
Cmnd_Alias EDITS = /usr/bin/vim, /usr/bin/nano, /usr/bin/cat, /usr/bin/vi<br />
Cmnd_Alias ARCHLINUX = /usr/bin/gparted, /usr/bin/pacman<br />
<br />
root ALL = (ALL) ALL<br />
USER_NAME ALL = (ALL) ALL, NOPASSWD: WHEELER, NOPASSWD: PROCESSES, NOPASSWD: ARCHLINUX, NOPASSWD: EDITS<br />
<br />
Defaults !requiretty, !tty_tickets, !umask<br />
Defaults visiblepw, path_info, insults, lecture=always<br />
Defaults loglinelen = 0, logfile =/var/log/sudo.log, log_year, log_host, syslog=auth<br />
Defaults mailto=webmaster@foobar.com, mail_badpass, mail_no_user, mail_no_perms<br />
Defaults passwd_tries = 8, passwd_timeout = 1<br />
Defaults env_reset, always_set_home, set_home, set_logname<br />
Defaults !env_editor, editor="/usr/bin/vim:/usr/bin/vi:/usr/bin/nano"<br />
Defaults timestamp_timeout=360<br />
Defaults passprompt="Sudo invoked by [%u] on [%H] - Cmd run as %U - Password for user %p:"<br />
</nowiki>}}<br />
<br />
=== Enabling Tab-completion in Bash ===<br />
<br />
{{ic|Tab}}-completion, by default, will not work when a user is initially added to the sudoers file. For example, normally john only needs to type:<br />
<br />
$ fire<{{ic|Tab}}><br />
<br />
and the shell will complete the command for him as:<br />
<br />
$ firefox<br />
<br />
If, however, john is added to the sudoers file and he types:<br />
<br />
$ sudo fire<{{ic|Tab}}><br />
<br />
the shell will do nothing.<br />
<br />
To enable {{ic|Tab}}-completion with sudo, [[pacman|install]] the {{pkg|bash-completion}} package from the [[Official Repositories|official repositories]]. see [[bash#Tab_completion]] for more information.<br />
<br />
Alternatively, add the following to your {{ic|~/.bashrc}}:<br />
<br />
complete -cf sudo<br />
<br />
=== Run X11 apps using sudo ===<br />
<br />
To allow sudo to start graphical application in X11, you need to add:<br />
<br />
Defaults env_keep += "HOME"<br />
<br />
to visudo.<br />
<br />
=== Disable per-terminal sudo ===<br />
<br />
{{Warning|This will let any process use your sudo session.}}<br />
<br />
If you are annoyed by sudo's defaults that require you to enter your password every time you open a new terminal, disable '''tty_tickets''':<br />
<br />
Defaults !tty_tickets<br />
<br />
=== Environment variables ===<br />
<br />
If you have a lot of environment variables, or you export your proxy settings via {{ic|1=export http_proxy="..."}}, when using sudo these variables do not get passed to the root account unless you run sudo with the {{ic|-E}} option.<br />
<br />
$ sudo -E pacman -Syu<br />
<br />
The recommended way of preserving environment variables is to append them to {{ic|env_keep}}:<br />
{{hc|/etc/sudoers|<nowiki><br />
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"<br />
</nowiki>}}<br />
<br />
=== Passing aliases ===<br />
<br />
If you use a lot of aliases, you might have noticed that they do not carry over to the root account when using sudo. However, there is an easy way to make them work. Simply add the following to your {{ic|~/.bashrc}} or {{ic|/etc/bash.bashrc}}:<br />
<br />
alias sudo='sudo '<br />
<br />
=== Insults ===<br />
<br />
Users can configure sudo to display clever insults when an incorrect password is entered instead of printing the default "wrong password" message. Find the Defaults line in {{ic|/etc/sudoers}} and append "insults" after a comma to existing options. The final result might look like this:<br />
<br />
#Defaults specification<br />
Defaults insults<br />
<br />
To test, type {{ic|sudo -K}} to end the current session and let sudo ask for the password again.<br />
<br />
=== Root password ===<br />
<br />
Users can configure sudo to ask for the root password instead of the user password by adding "rootpw" to the Defaults line in {{ic|/etc/sudoers}}:<br />
<br />
Defaults timestamp_timeout=0,rootpw<br />
<br />
=== Disable root login ===<br />
<br />
{{Warning|Arch Linux is not fine-tuned to run with a disabled root account. Users may encounter problems with this method.}}<br />
<br />
With sudo installed and configured, users may wish to disable the root login. Without root, attackers must first guess a user name configured as a sudoer as well as the user password.<br />
<br />
{{Warning|Ensure a user is properly configured as a sudoer ''before'' disabling the root account!}}<br />
<br />
The account can be locked via {{ic|passwd}}:<br />
<br />
# passwd -l root<br />
<br />
A similar command unlocks root.<br />
<br />
$ sudo passwd -u root<br />
<br />
Alternatively, edit {{ic|/etc/shadow}} and replace the root's encrypted password with "!":<br />
<br />
root:!:12345::::::<br />
<br />
To enable root login again:<br />
<br />
$ sudo passwd root<br />
<br />
==== kdesu ====<br />
<br />
kdesu may be used under KDE to launch GUI applications with root privileges. It is possible that by default kdesu will try to use su even if the root account is disabled. Fortunately one can tell kdesu to use sudo instead of su. Create/edit the file {{ic|~/.kde4/share/config/kdesurc}}:<br />
<br />
[super-user-command]<br />
super-user-command=sudo<br />
<br />
==== PolicyKit ====<br />
<br />
When disabling the root account, it is necessary to change the [[PolicyKit]] configuration for local authorization to reflect that. The default is to ask for the root password, so that must be changed. With polkit-1, this can be achieved by editing {{ic|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf}} so that {{ic|1=AdminIdentities=unix-user:0}} is replaced with something else, depending on the system configuration. It can be a list of users and groups, for example:<br />
<br />
AdminIdentities=unix-group:wheel<br />
<br />
or<br />
<br />
AdminIdentities=unix-user:me;unixuser:mom;unix-group:wheel<br />
<br />
For more information, see {{ic|man pklocalauthority}}.<br />
<br />
==== NetworkManager ====<br />
<br />
Even with the above PolicyKit configuration you still need to configure a policy for NetworkManager. This is documented on the [[NetworkManager#Can.27t_edit_connections_as_normal_user|NetworkManager]] page of this wiki.<br />
<br />
=== Harden with Sudo Example ===<br />
<br />
Lets say you create 3 users: admin, devel, and Joe<br />
admin is used for journalctl, systemctl, mount, kill, and iptables.<br />
devel is used for installing packages, and editing config's<br />
Joe is the user you log in with. Let's let him reboot, shutdown, and use netctl<br />
<br />
Edit /etc/pam.d/su and /etc/pam.d/su-1<br />
Require user be in the wheel group, but don't put anyone in it.<br />
#%PAM-1.0<br />
auth sufficient pam_rootok.so<br />
# Uncomment the following line to implicitly trust users in the "wheel" group.<br />
#auth sufficient pam_wheel.so trust use_uid<br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
auth required pam_unix.so<br />
account required pam_unix.so<br />
session required pam_unix.so<br />
<br />
Limit SSH login to the 'ssh' group, Only put Joe in it<br />
groupadd -r ssh<br />
gpasswd -a Joe ssh<br />
echo 'AllowGroups ssh' >> /etc/ssh/sshd_config<br />
systemctl restart sshd.service<br />
<br />
Lets add users to other goups.<br />
for g in network power ;do ;gpasswd -a Joe $g ;done<br />
for g in network power disk ;do ;gpasswd -a Joe $g ;done<br />
<br />
Set permissions on configs so devel can edit them.<br />
chown -R devel:root /etc/{http,openvpn,cups,zsh,vim,screenrc}<br />
<br />
Cmnd_Alias POWER = /usr/bin/shutdown -h now, /usr/bin/halt, /usr/bin/poweroff, /usr/bin/reboot<br />
Cmnd_Alias DISK = /usr/bin/mount, /usr/bin/umount<br />
Cmnd_Alias SYSTEMD = /usr/bin/journalctl, /usr/bin/systemctl<br />
Cmnd_Alias KILL = /usr/bin/kill<br />
Cmnd_Alias PKGMAN = /usr/bin/pacman<br />
Cmnd_Alias NETWORK = /usr/bin/netctl<br />
Cmnd_Alias SU_ADMIN = /usr/bin/su – admin<br />
Cmnd_Alias SU_DEVEL = /usr/bin/su – devel<br />
%power ALL = (root) NOPASSWD: POWER<br />
%network ALL = (root) NETWORK<br />
root ALL = (ALL) ALL<br />
admin ALL = (root) SYSTEMD, KILL<br />
devel ALL = (root) PKGMAN<br />
Joe ALL = (root) SU_ADMIN, SU_DEVEL <br />
<br />
With this setup, you will almost never need to login as the Root user.<br />
<br />
Joe can connect to his home WiFi<br />
sudo -- netctl start home<br />
sudo -- poweroff<br />
<br />
Joe can not use netctl as any other user like admin...<br />
sudo -u admin -- netctl start home<br />
<br />
When Joe needs to use journalctl or kill run away process he can switch to that user<br />
sudo su -- admin<br />
sudo su -- devel<br />
<br />
But not Root<br />
sudo su -- root<br />
<br />
If joe want to start a gnu-screen session as admin he can do it like this<br />
sudo su -- admin<br />
admin% chown admin:tty `echo $TTY`<br />
admin% screen<br />
<br />
== Troubleshooting ==<br />
<br />
=== SSH TTY Issues ===<br />
<br />
SSH does not allocate a tty by default when running a remote command. Without a tty, sudo cannot disable echo when prompting for a password. You can use ssh's {{ic|-tt}} option to force it to allocate a tty (or {{ic|-t}} twice).<br />
<br />
The {{ic|Defaults}} option {{ic|requiretty}} only allows the user to run sudo if they have a tty.<br />
<br />
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear text. You have to run "ssh -t hostname sudo <cmd>".<br />
#<br />
#Defaults requiretty<br />
<br />
=== Display User Privileges ===<br />
<br />
You can find out what privileges a particular user has with the following command:<br />
<br />
$ sudo -lU yourusename<br />
<br />
Or view your own with:<br />
<br />
{{hc|$ sudo -l|<nowiki><br />
Matching Defaults entries for yourusename on this host:<br />
loglinelen=0, logfile=/var/log/sudo.log, log_year, syslog=auth, mailto=webmaster@gmail.com, mail_badpass, mail_no_user,<br />
mail_no_perms,env_reset, always_set_home, tty_tickets, lecture=always, pwfeedback, rootpw, set_home<br />
<br />
User yourusename may run the following commands on this host:<br />
<br />
(ALL) ALL<br />
(ALL) NOPASSWD: /usr/bin/lsof, /bin/nice, /usr/bin/su, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync, /usr/bin/strace,<br />
(ALL) /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
(ALL) /usr/bin/gparted, /usr/bin/pacman<br />
(ALL) /usr/local/bin/synergyc, /usr/local/bin/synergys<br />
(ALL) /usr/bin/vim, /usr/bin/nano, /usr/bin/cat<br />
(root) NOPASSWD: /usr/local/bin/synergyc</nowiki>}}<br />
<br />
=== Permissive Umask ===<br />
<br />
Sudo will union the user's [[umask]] value with its own umask (which defaults to 0022). This prevents sudo from creating files with more open permissions than the user's umask allows. While this is a sane default if no custom umask is in use, this can lead to situations where a utility run by sudo may create files with different permissions than if run by root directly. If errors arise from this, sudo provides a means to fix the umask, even if the desired umask is more permissive than the umask that the user has specified. Adding this (using {{ic|visudo}}) will override sudo's default behavior:<br />
<br />
Defaults umask = 0022<br />
Defaults umask_override<br />
<br />
This sets sudo's umask to root's default umask (0022) and overrides the default behavior, always using the indicated umask regardless of what umask the user as set.<br />
<br />
<br />
=== Defaults Skeleton ===<br />
<br />
The authors site has a [http://www.gratisoft.us/sudo/sudoers.man.html#sudoers_options list of all the options] that can be used with the {{ic|Defaults}} command in the {{ic|/etc/sudoers}} file.<br />
<br />
The full list of options ''(parsed from the version 1.8.7 source code)'' is below in a format optimized for copying and pasting into your sudoers files for quick editing.<br />
<br />
{{bc|<nowiki>#Defaults always_set_home<br />
# If enabled, sudo will set the HOME environment variable to the home directory of the target user<br />
# (which is root unless the -u option is used). This effectively means that the -H option<br />
# always_set_home is only effective for configurations where either env_reset is disabled or HOME is present<br />
# in the env_keep list. Default: OFF<br />
<br />
#Defaults authenticate<br />
# If set, users must authenticate themselves via a password (or other means of authentication)<br />
# before they may run commands. This default may be overridden via the PASSWD and NOPASSWD<br />
<br />
#Defaults closefrom_override<br />
# If set, the user may use sudo's -C option which overrides the default starting<br />
# point at which sudo begins closing open file descriptors. Default: OFF<br />
<br />
#Defaults compress_io<br />
# If set, and sudo is configured to log a command's input or output, the I/O logs will be<br />
# compressed using zlib. This flag is on by default when sudo is compiled with zlib support.<br />
<br />
#Defaults env_editor<br />
# If set, visudo will use the value of the EDITOR or VISUAL environment variables before falling back on the default<br />
# editor list. Note that this may create a security hole as it allows th separated list of editors in the editor<br />
# variable. visudo will then only use the EDITOR or VISUAL if they match a value specified in editor. On by default.<br />
<br />
#Defaults env_reset<br />
# If set, sudo will run the command in a minimal environment containing the TERM, PATH, HOME, MAIL, SHELL, LOGNAME,<br />
# USER, USERNAME and SUDO_* variables. Any variables in the caller's env in the file specified by the env_file<br />
# option (if any). The default contents of the env_keep and env_check lists are displayed when sudo is run by<br />
# root with the -V option.<br />
<br />
#Defaults fast_glob<br />
# Normally, sudo uses the glob(3) function to do shell-style globbing when matching path names.<br />
# However, since it accesses the file system, glob(3) can take a long time to complete for som (automounted).<br />
# The fast_glob option causes sudo to use the fnmatch(3) function, which does not access the file system to do<br />
# its matching. The disadvantage of fast_glob is that it is unable to ma names that include globbing characters<br />
# are used with the negation operator, '!', as such rules can be trivially bypassed. As such, this option should<br />
# not be used when sudoers contains rules that<br />
<br />
#Defaults fqdn<br />
# Set this flag if you want to put fully qualified host names in the sudoers file. I.e., instead of myhost you<br />
# would use myhost.mydomain.edu. You may still use the short form if you wish (and sudo unusable if DNS stops<br />
# working (for example if the machine is not plugged into the network). Also note that you must use the<br />
# host's official name as DNS knows it. That is, you may not use a all aliases from DNS. If your machine's<br />
# host name (as returned by the hostname command) is already fully qualified you shouldn't need to set fqdn.<br />
# Default: OFF<br />
<br />
#Defaults ignore_dot<br />
# If set, sudo will ignore '.' or '' (current dir) in the PATH environment variable; the PATH<br />
# itself is not modified. Default: OFF<br />
<br />
#Defaults ignore_local_sudoers<br />
# If set via LDAP, parsing of /etc/sudoers will be skipped. This is intended for Enterprises that wish to prevent<br />
# the usage of local sudoers files so that only LDAP is used. /etc/sudoers does not even need to exist.<br />
# Since this option tells sudo how to behave when no specific LDAP entries have been matched, this sudo<br />
# Option is only meaningful for the cn=default<br />
<br />
#Defaults insults<br />
# If set, sudo will insult users when they enter an incorrect password. Default: OFF<br />
<br />
#Defaults log_host<br />
# If set, the host name will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults log_input<br />
# If set, sudo will run the command in a pseudo tty and log all user input. If the standard<br />
# input is not connected to the user's tty, due to I/O redirection or because the command is part Input is logged<br />
# to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that<br />
# is included in the normal sudo log line, prefixed with TSID=. Note that user input may contain sensitive<br />
# information such as passwords (even if they are not echoed to the screen), which will be stored in the log file<br />
# unencrypted.<br />
<br />
#Defaults log_output<br />
# If set, sudo will run the command in a pseudo tty and log all output that is sent to the<br />
# screen, similar to the script(1) command. If the standard output or standard error is not connec is also captured and<br />
# stored in separate log files. Output is logged to the directory specified by the iolog_dir option (/var/log/sudo-io<br />
# by default) using a unique session ID that is included in the normal sudo log line, prefixed with TSID=. The Output<br />
# logs may be viewed with the sudoreplay(8) utility, which can also be used to list or search the available logs.<br />
<br />
#Defaults log_year<br />
# If set, the four-digit year will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults long_otp_prompt<br />
# When validating with a One Time Password (OTP) scheme such as S/Key or OPIE, a two-line<br />
# prompt is used to make it easier to cut and paste the challenge to a local window<br />
<br />
#Defaults mail_always<br />
# Send mail to the mailto user every time a users runs sudo. Default: OFF<br />
<br />
#Defaults mail_badpass<br />
# Send mail to the mailto user if the user running sudo does not enter the correct password.<br />
# Default: OFF<br />
<br />
#Defaults mail_no_host<br />
# If set, mail will be sent to the mailto user if the invoking user exists in the sudoers<br />
# file, but is not allowed to run commands on the current host. Default: OFF<br />
<br />
#Defaults mail_no_perms<br />
# If set, mail will be sent to the mailto user if the invoking user is allowed to use sudo<br />
# but the command they are trying is not listed in their sudoers file entry or is explicitly denied<br />
<br />
#Defaults mail_no_user<br />
# If set, mail will be sent to the mailto user if the invoking user is not in the sudoers file.<br />
# Default: ON<br />
<br />
#Defaults noexec<br />
# If set, all commands run via sudo will behave as if the NOEXEC tag has been set, unless overridden<br />
# by a EXEC tag. See the description of NOEXEC and EXEC below as well as the "PREVENTING SHE<br />
<br />
#Defaults path_info<br />
# Normally, sudo will tell the user when a command could not be found in their PATH environment<br />
# variable. Some sites may wish to disable this as it could be used to gather information on t the executable is<br />
# simply not in the user's PATH, sudo will tell the user that they are not allowed to run it, which can be confusing.<br />
# Default: ON<br />
<br />
#Defaults passprompt_override<br />
# The password prompt specified by passprompt will normally only be used if the password prompt provided by<br />
# systems such as PAM matches the string "Password:"<br />
<br />
#Defaults preserve_groups<br />
# By default, sudo will initialize the group vector to the list of groups the target<br />
# user is in. When preserve_groups is set, the user's existing group vector is left unaltered.<br />
<br />
#Defaults pwfeedback<br />
# By default, sudo reads the password like most other Unix programs, by turning off echo<br />
# until the user hits the return (or enter) key. Some users become confused by this as it appears to the user<br />
# presses a key. Note that this does have a security impact as an onlooker may be able to determine the length of<br />
# the password being entered. Default: OFF<br />
<br />
#Defaults requiretty<br />
# If set, sudo will only run when the user is logged in to a real tty. When this flag is set,<br />
# sudo can only be run from a login session and not via other means such as cron(8) or cgi-bin<br />
<br />
#Defaults root_sudo<br />
# If set, root is allowed to run sudo too. Disabling this prevents users from "chaining" sudo<br />
# commands to get a root shell by doing something like "sudo sudo /bin/sh". Note, however, that real additional<br />
# security; it exists purely for historical reasons. Default: ON<br />
<br />
#Defaults rootpw<br />
# If set, sudo will prompt for the root password instead of the password of the invoking user.<br />
# Default: OFF<br />
<br />
#Defaults runaspw<br />
# If set, sudo will prompt for the password of the user defined by the runas_default option<br />
# (defaults to root) instead of the password of the invoking user. Default: OFF<br />
<br />
#Defaults set_home<br />
# If enabled and sudo is invoked with the -s option the HOME environment variable will be set<br />
# to the home directory of the target user (which is root unless the -u option is used). So set_home is only<br />
# effective for configs where either env_reset is disabled or HOME is present in the env_keep list. Default: OFF<br />
<br />
#Defaults set_logname<br />
# Normally, sudo will set the LOGNAME, USER and USERNAME environment variables to the name<br />
# of the target user (usually root unless the -u option is given). However, since some programs ( may be desirable<br />
# to change this behavior. This can be done by negating the set_logname option. Note that if the env_reset option<br />
# has not been disabled, entries in the env_keep list will override<br />
<br />
#Defaults set_utmp<br />
# When enabled, sudo will create an entry in the utmp (or utmpx) file when a pseudo-tty is<br />
# allocated. A pseudo-tty is allocated by sudo when the log_input, log_output or use_pty flags are e the tty, time,<br />
# type and pid fields updated. Default: ON<br />
<br />
#Defaults setenv<br />
# Allow the user to disable the env_reset option from the command line via the -E option.<br />
# Additionally, environment variables set via the command line are not subject to the restrictions impo variables<br />
# in this manner. Default: OFF<br />
<br />
#Defaults shell_noargs<br />
# If set and sudo is invoked with no arguments it acts as if the -s option had been given.<br />
# That is, it runs a shell as root (the shell is determined by the SHELL environment variable if is off by default.<br />
<br />
#Defaults stay_setuid<br />
# Normally, when sudo executes a command the real and effective UIDs are set to the target<br />
# user (root by default). This option changes that behaviour such that the real UID is left as the systems that<br />
# disable some potentially dangerous functionality when a program is run setuid. This option is only effective on<br />
# systems with either the setreuid() or setresuid() function. This flag<br />
<br />
#Defaults targetpw<br />
# If set, sudo will prompt for the password of the user specified by the -u option (defaults to root) instead<br />
# of the password of the invoking user. In addition, the timestamp file name will passwd database as an argument<br />
# to the -u option. Default: OFF<br />
<br />
#Defaults tty_tickets<br />
# If set, users must authenticate on a per-tty basis. With this flag enabled, sudo will<br />
# use a file named for the tty the user is logged in on in the user's time stamp directory.<br />
<br />
#Defaults umask_override<br />
# If set, sudo will set the umask as specified by sudoers without modification. This makes<br />
# it possible to specify a more permissive umask in sudoers than the user's own umask and match user's umask and what<br />
# is specified in sudoers. Default: OFF<br />
<br />
#Defaults use_pty<br />
# If set, sudo will run the command in a pseudo-pty even if no I/O logging is being gone.<br />
# A malicious program run under sudo could conceivably fork a background process that retains to the u that impossible.<br />
# Default: OFF<br />
<br />
#Defaults utmp_runas<br />
# If set, sudo will store the name of the runas user when updating the utmp (or utmpx) file.<br />
# By default, sudo stores the name of the invoking user. Default: OFF<br />
<br />
#Defaults visiblepw<br />
# By default, sudo will refuse to run if the user must enter a password but it is not possible to disable echo on the <br />
# terminal. If the visiblepw flag is set, sudo will prompt for a password even when it would be visible on the screen. <br />
# This makes it possible to run things like "rsh somehost sudo ls" since rsh(1) does not allocate a tty. Default: OFF<br />
<br />
#Defaults closefrom<br />
# Before it executes a command, sudo will close all open file descriptors other than standard<br />
# input, standard output and standard error (ie: file descriptors 0-2).<br />
<br />
#Defaults passwd_tries<br />
# The number of tries a user gets to enter his/her password before sudo logs the failure<br />
# and exits. The default is 3.<br />
<br />
#Defaults loglinelen<br />
# Number of characters per line for the file log. This value is used to decide when to wrap<br />
# lines for nicer log files. This has no effect on the syslog log file, only the file log.<br />
<br />
#Defaults passwd_timeout<br />
# Number of minutes before the sudo password prompt times out, or 0 for no timeout.<br />
# The timeout may include a fractional component if minute granularity is insufficient, for example 2<br />
<br />
#Defaults timestamp_timeout<br />
# Number of minutes that can elapse before sudo will ask for a passwd again. The timeout<br />
# may include a fractional component if minute granularity is insufficient, for example 2.5. timestamp will never expire.<br />
# This can be used to allow users to create or delete their own timestamps via sudo -v and sudo -k respectively.<br />
<br />
#Defaults umask<br />
# Umask to use when running the command. Negate this option or set it to 0777 to preserve<br />
# the user's umask. The actual umask that is used will be the union of the user's umask and the value o running<br />
# a command. Note on systems that use PAM, the default PAM configuration may specify its own umask which will<br />
# override the value set in sudoers.<br />
<br />
#Defaults badpass_message<br />
# Message that is displayed if a user enters an incorrect password. The default is Sorry,<br />
# try again. unless insults are enabled.<br />
<br />
#Defaults editor<br />
# A colon (':') separated list of editors allowed to be used with visudo. visudo will choose<br />
# the editor that matches the user's EDITOR environment variable if possible, or the first editor in<br />
<br />
#Defaults iolog_dir<br />
# The top-level directory to use when constructing the path name for the input/output log<br />
# directory. Only used if the log_input or log_output options are enabled or when the LOG_INPUT or L directory.<br />
# The default is "/var/log/sudo-io". The following percent (%) escape sequences are supported:<br />
# %{seq} - expanded to base-36 sequence number, such as 0100A5, to form a new directory, e.g. 01/00/A5<br />
# %{user} - expanded to the invoking user's login name<br />
# %{group} - expanded to the name of the invoking user's real group ID<br />
# %{runas_user} - expanded to the login name of the user the command will be run as (e.g. root)<br />
# %{runas_group} - expanded to the group name of the user the command will be run as (e.g. wheel)<br />
# %{hostname} - expanded to the local host name without the domain name<br />
# %{command} - expanded to the base name of the command being run In addition, any escape sequences supported by<br />
# strftime() function will be expanded. To include a literal % character, the string %% should be used.<br />
<br />
#Defaults iolog_file<br />
# The path name, relative to iolog_dir, in which to store input/output logs when the log_input or log_output options are<br />
# enabled or when the LOG_INPUT or LOG_OUTPUT tags are present for a See the iolog_dir option above for a list of<br />
# supported percent (%) escape sequences. In addition to the escape sequences, path names that end in six or more Xs will<br />
# have the Xs replaced with a unique combination of digits and letters, similar to the mktemp() function.<br />
<br />
#Defaults mailsub<br />
# Subject of the mail sent to the mailto user. The escape %h will expand to the host name of<br />
# the machine. Default is *** SECURITY information for %h ***.<br />
<br />
#Defaults noexec_file<br />
# This option is no longer supported. The path to the noexec file should now be set in the /etc/sudo.conf file.<br />
<br />
#Defaults passprompt<br />
# The default prompt to use when asking for a password; can be overridden via the -p option or the SUDO_PROMPT<br />
# environment variable. The following percent (%) escape sequences are supported:<br />
# %H - expanded to the local host name including the domain (only if the host name is fqdn or fqdn option is set)<br />
# %h - expanded to the local host name without the domain name<br />
# %p - expanded to the user whose password is being asked for (respects the rootpw, targetpw and runaspw flags)<br />
# %U - expanded to the login name of the user the command will be run as (defaults to root)<br />
# %u - expanded to the invoking user's login name<br />
# %% - two consecutive % characters are collapsed into a single % character<br />
# The default value is Password:.<br />
<br />
#Defaults runas_default<br />
# The default user to run commands as if the -u option is not specified on the command line. This defaults to root.<br />
<br />
#Defaults syslog_badpri<br />
# Syslog priority to use when user authenticates unsuccessfully. Defaults to alert.<br />
# alert, crit, debug, emerg, err, info, notice, and warning.<br />
<br />
#Defaults syslog_goodpri<br />
# Syslog priority to use when user authenticates successfully. Defaults to notice. See syslog_badpri for the priorities.<br />
<br />
#Defaults sudoers_locale<br />
# Locale to use when parsing the sudoers file, logging commands, and sending email.<br />
# Note that changing the locale may affect how sudoers is interpreted. Defaults to "C".<br />
<br />
#Defaults timestampdir<br />
# The directory in which sudo stores its timestamp files. The default is /var/db/sudo.<br />
<br />
#Defaults timestampowner<br />
# The owner of the timestamp directory and the timestamps stored therein. The default is root.<br />
<br />
#Defaults env_file<br />
# The env_file option specifies the fully qualified path to a file containing variables to<br />
# be set in the environment of the program being run. Entries in this file should either be of the f quotes.<br />
# Variables in this file are subject to other sudo environment settings such as env_keep and env_check.<br />
<br />
#Defaults exempt_group<br />
# Users in this group are exempt from password and PATH requirements. The group name specified should not include<br />
# a % prefix. This is not set by default.<br />
<br />
#Defaults group_plugin<br />
# A string containing a sudoers group plugin with optional arguments. This can be used to implement support for the<br />
# nonunix_group syntax described earlier. The string should consist of configuration arguments the plugin requires.<br />
# These arguments (if any) will be passed to the plugin's initialization function. If arguments are present, the<br />
# string must be enclosed in double quote For example, given /etc/sudo-group, a group file in Unix group format,<br />
# the sample group plugin can be used: Defaults group_plugin="sample_group.so /etc/sudo-group"<br />
# For more information see sudo_plugin(5).<br />
<br />
#Defaults lecture<br />
# This option controls when a short lecture will be printed along with the password prompt. The default value is once.<br />
# It has the following possible values:<br />
# always - Always lecture the user.<br />
# never - Never lecture the user.<br />
# once - Only lecture the user the first time they run sudo.<br />
# If no value is specified, a value of once is implied. Negating the option results in a value of never being used.<br />
<br />
#Defaults lecture_file<br />
# Path to a file containing an alternate sudo lecture that will be used in place of the standard lecture if the named<br />
# file exists. By default, sudo uses a built-in lecture.<br />
<br />
#Defaults listpw<br />
# This option controls when a password will be required when a user runs sudo with the -l option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD set to avoid entering a pass.<br />
# always - The user must always enter a password to use the -l option.<br />
# any - At least one of the user's sudoers entries for the current host must have the NOPASSWD set to avoid pass.<br />
# never - The user need never enter a password to use the -l option.<br />
# If no value is specified, a value of any is implied. The default value is any.<br />
<br />
#Defaults logfile<br />
# Path to the sudo log file (not the syslog log file). Setting a path turns on logging to a file;<br />
# negating this option turns it off. By default, sudo logs via syslog.<br />
<br />
#Defaults mailerflags<br />
# Flags to use when invoking mailer. Defaults to -t.<br />
<br />
#Defaults mailerpath<br />
# Path to mail program used to send warning mail. Defaults to the path to sendmail found at configure time.<br />
<br />
#Defaults mailfrom<br />
# Address to use for the "from" address when sending warning and error mail. The address should<br />
# be enclosed in double quotes (") to protect against sudo interpreting the @ sign.<br />
<br />
#Defaults mailto<br />
# Address to send warning and error mail to. The address should be enclosed in double quotes<br />
# (") to protect against sudo interpreting the @ sign. Defaults to root.<br />
<br />
#Defaults secure_path<br />
# Path used for every command run from sudo. If you don't trust the people running sudo to have a sane PATH environment<br />
# variable you may want to use this. Another use is if you want to option are not affected by secure_path.<br />
# This option is not set by default.<br />
<br />
#Defaults syslog<br />
# Syslog facility if syslog is being used for logging (negate to disable syslog logging). Defaults to auth.<br />
# authpriv (if OS supports it), auth, daemon, user, local0, local1, local2, local3, local4, local5, local6, and local7.<br />
<br />
#Defaults verifypw<br />
# This option controls when a password will be required when a user runs sudo with the -v option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD flag to avoid pw.<br />
# always - The user must always enter a password to use the -v option.<br />
# any - At least one of the user's sudoers entries for the current host must have NOPASSWD to avoid pw.<br />
# never - The user need never enter a password to use the -v option<br />
# If no value is specified, a value of all is implied. Negating the option results in a value of never being used.<br />
# The default value is all.<br />
<br />
#Defaults env_check<br />
# Environment variables to be removed from the user's environment if the variable's value contains % or / characters.<br />
# This can be used to guard against printf-style format vulnerabilities value without double-quotes. The list can be<br />
# replaced, added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively. Regardless of<br />
# whether the env_reset option is ena they pass the aforementioned check. The default list of environment variables<br />
# to check is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_delete<br />
# Environment variables to be removed from the user's environment when the env_reset option is not in effect. The<br />
# argument may be a double-quoted, space-separated list or a single value w +=, -=, and ! operators respectively.<br />
# The default list of environment variables to remove is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_keep<br />
# Environment variables to be preserved in the user's environment when the env_reset option is in effect. This<br />
# allows fine-grained control over the environment sudo-spawned processes will r quotes. The list can be replaced,<br />
# added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively.</nowiki>}}</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Sudo&diff=281529Sudo2013-11-05T14:31:36Z<p>Hunterthomson: /* Tips and tricks */ Added kind of a long example... edit if needed</p>
<hr />
<div>[[Category:Security]]<br />
[[cs:Sudo]]<br />
[[es:Sudo]]<br />
[[fr:Sudo]]<br />
[[it:Sudo]]<br />
[[ja:Sudo]]<br />
[[ru:Sudo]]<br />
[[sr:Sudo]]<br />
[[tr:Sudo]]<br />
[[uk:Sudo]]<br />
[[zh-CN:Sudo]]<br />
{{Article summary start}}<br />
{{Article summary text|An overview of the popular privilege escalation utility.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Access control overview}}}}<br />
{{Article summary end}}<br />
<br />
[http://www.gratisoft.us/sudo/ sudo] ("substitute user do") allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments.<br />
<br />
== Rationale ==<br />
<br />
Sudo is an alternative to [[su]] for running commands as root. Unlike [[su]], which launches a root shell that allows all further commands root access, sudo instead grants temporary privilege escalation to a single command. By enabling root privileges only when needed, sudo usage reduces the likelyhood that a typo or a bug in an invoked command will ruin the system.<br />
Sudo can also be used to run commands as other users; additionally, sudo logs all commands and failed access attempts for security auditing.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|sudo}} package, available in the [[Official Repositories|official repositories]]:<br />
<br />
# pacman -S sudo<br />
<br />
To begin using {{ic|sudo}} as a non-privileged user, it must be properly configured. So make sure you read the configuration section.<br />
<br />
== Usage ==<br />
<br />
With sudo, users can prefix commands with {{ic|sudo}} to run them with superuser (or other) privileges.<br />
<br />
For example, to use pacman:<br />
<br />
$ sudo pacman -Syu<br />
<br />
See the [http://www.gratisoft.us/sudo/man/sudo.html sudo manual] for more information.<br />
<br />
== Configuration ==<br />
<br />
=== View current settings ===<br />
<br />
Run {{ic|sudo -ll}} to print out the current sudo configuration.<br />
<br />
=== Using visudo ===<br />
<br />
The configuration file for sudo is {{ic|/etc/sudoers}}. It should '''always''' be edited with the {{ic|visudo}} command. {{ic|visudo}} locks the {{ic|sudoers}} file, saves edits to a temporary file, and checks that file's grammar before copying it to {{ic|/etc/sudoers}}.<br />
<br />
{{Warning|It is imperative that {{ic|sudoers}} be free of syntax errors! Any error makes sudo unusable. '''Always''' edit it with {{ic|visudo}} to prevent errors.}}<br />
<br />
The default editor for visudo is {{ic|vi}}. It will be used if you do not specify another editor, by setting either VISUAL or EDITOR environment variables (used in that order) to the desired editor, e.g. {{ic|nano}}. The command is run as root:<br />
<br />
# EDITOR=nano visudo<br />
<br />
You can permanently change the setting for your user to e.g. {{ic|nano}} by appending:<br />
<br />
export EDITOR=nano<br />
<br />
to your {{ic|~/.bashrc}} file. Note that this won't take effect for already-running shells.<br />
<br />
To change the editor of choice permanently system-wide only for {{ic|visudo}}, add the following line to {{ic|/etc/sudoers}} where {{ic|nano}} is your prefered editor:<br />
<br />
# Reset environment by default<br />
Defaults env_reset<br />
# Set default EDITOR to nano, and do not allow visudo to use EDITOR/VISUAL.<br />
Defaults editor=/usr/bin/nano, !env_editor<br />
<br />
=== Example Entries ===<br />
<br />
To allow a user to gain full root privileges when he/she precedes a command with {{ic|sudo}}, add the following line:<br />
<br />
USER_NAME ALL=(ALL) ALL<br />
<br />
To allow a user to run all commands as any user but only the machine with hostname HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=(ALL) ALL<br />
<br />
To allow members of group {{ic|wheel}} sudo access:<br />
<br />
%wheel ALL=(ALL) ALL<br />
<br />
To disable asking for a password for user USER_NAME:<br />
<br />
Defaults:USER_NAME !authenticate<br />
<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME:<br />
<br />
USER_NAME HOST_NAME=/usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
{{note| the most customized option should go at the end of the file, as the later lines overrides the previous ones. In particular such a line should be after the {{ic|%wheel}} line if your user is in this group.}}<br />
Enable explicitly defined commands only for user USER_NAME on host HOST_NAME without password:<br />
USER_NAME HOST_NAME= NOPASSWD: /usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu<br />
<br />
A detailed sudoers example can be found [http://www.gratisoft.us/sudo/sample.sudoers here]. Otherwise, see the [http://www.gratisoft.us/sudo/man/sudoers.html sudoers manual] for detailed information.<br />
<br />
=== Sudoers default file permissions ===<br />
<br />
The owner and group for the sudoers file must both be 0. The file permissions must be set to 0440. These permissions are set by default, but if you accidentally change them, they should be changed back immediately or sudo will fail.<br />
<br />
# chown -c root:root /etc/sudoers<br />
# chmod -c 0440 /etc/sudoers<br />
<br />
=== Password cache timeout ===<br />
<br />
Users may wish to change the default timeout before the cached password expires. This is accomplished with the timestamp_timeout option in {{ic|/etc/sudoers}} which is in minutes.<br />
Set timeout to 20 minutes.<br />
<br />
Defaults:USER_NAME timestamp_timeout=20<br />
<br />
{{Tip|To ensure sudo always asks for a password, set the timeout to 0. To ensure the password never times out, set to less than 0.}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== File example ===<br />
<br />
This example is especially helpful for those using terminal multiplexers like screen, tmux, or ratpoison, and those using sudo from scripts/cronjobs:<br />
<br />
{{hc|/etc/sudoers|<nowiki><br />
Cmnd_Alias WHEELER = /usr/bin/lsof, /bin/nice, /bin/ps, /usr/bin/top, /usr/local/bin/nano, /usr/bin/ss, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync<br />
Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/kill, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
Cmnd_Alias EDITS = /usr/bin/vim, /usr/bin/nano, /usr/bin/cat, /usr/bin/vi<br />
Cmnd_Alias ARCHLINUX = /usr/bin/gparted, /usr/bin/pacman<br />
<br />
root ALL = (ALL) ALL<br />
USER_NAME ALL = (ALL) ALL, NOPASSWD: WHEELER, NOPASSWD: PROCESSES, NOPASSWD: ARCHLINUX, NOPASSWD: EDITS<br />
<br />
Defaults !requiretty, !tty_tickets, !umask<br />
Defaults visiblepw, path_info, insults, lecture=always<br />
Defaults loglinelen = 0, logfile =/var/log/sudo.log, log_year, log_host, syslog=auth<br />
Defaults mailto=webmaster@foobar.com, mail_badpass, mail_no_user, mail_no_perms<br />
Defaults passwd_tries = 8, passwd_timeout = 1<br />
Defaults env_reset, always_set_home, set_home, set_logname<br />
Defaults !env_editor, editor="/usr/bin/vim:/usr/bin/vi:/usr/bin/nano"<br />
Defaults timestamp_timeout=360<br />
Defaults passprompt="Sudo invoked by [%u] on [%H] - Cmd run as %U - Password for user %p:"<br />
</nowiki>}}<br />
<br />
=== Enabling Tab-completion in Bash ===<br />
<br />
{{ic|Tab}}-completion, by default, will not work when a user is initially added to the sudoers file. For example, normally john only needs to type:<br />
<br />
$ fire<{{ic|Tab}}><br />
<br />
and the shell will complete the command for him as:<br />
<br />
$ firefox<br />
<br />
If, however, john is added to the sudoers file and he types:<br />
<br />
$ sudo fire<{{ic|Tab}}><br />
<br />
the shell will do nothing.<br />
<br />
To enable {{ic|Tab}}-completion with sudo, [[pacman|install]] the {{pkg|bash-completion}} package from the [[Official Repositories|official repositories]]. see [[bash#Tab_completion]] for more information.<br />
<br />
Alternatively, add the following to your {{ic|~/.bashrc}}:<br />
<br />
complete -cf sudo<br />
<br />
=== Run X11 apps using sudo ===<br />
<br />
To allow sudo to start graphical application in X11, you need to add:<br />
<br />
Defaults env_keep += "HOME"<br />
<br />
to visudo.<br />
<br />
=== Disable per-terminal sudo ===<br />
<br />
{{Warning|This will let any process use your sudo session.}}<br />
<br />
If you are annoyed by sudo's defaults that require you to enter your password every time you open a new terminal, disable '''tty_tickets''':<br />
<br />
Defaults !tty_tickets<br />
<br />
=== Environment variables ===<br />
<br />
If you have a lot of environment variables, or you export your proxy settings via {{ic|1=export http_proxy="..."}}, when using sudo these variables do not get passed to the root account unless you run sudo with the {{ic|-E}} option.<br />
<br />
$ sudo -E pacman -Syu<br />
<br />
The recommended way of preserving environment variables is to append them to {{ic|env_keep}}:<br />
{{hc|/etc/sudoers|<nowiki><br />
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"<br />
</nowiki>}}<br />
<br />
=== Passing aliases ===<br />
<br />
If you use a lot of aliases, you might have noticed that they do not carry over to the root account when using sudo. However, there is an easy way to make them work. Simply add the following to your {{ic|~/.bashrc}} or {{ic|/etc/bash.bashrc}}:<br />
<br />
alias sudo='sudo '<br />
<br />
=== Insults ===<br />
<br />
Users can configure sudo to display clever insults when an incorrect password is entered instead of printing the default "wrong password" message. Find the Defaults line in {{ic|/etc/sudoers}} and append "insults" after a comma to existing options. The final result might look like this:<br />
<br />
#Defaults specification<br />
Defaults insults<br />
<br />
To test, type {{ic|sudo -K}} to end the current session and let sudo ask for the password again.<br />
<br />
=== Root password ===<br />
<br />
Users can configure sudo to ask for the root password instead of the user password by adding "rootpw" to the Defaults line in {{ic|/etc/sudoers}}:<br />
<br />
Defaults timestamp_timeout=0,rootpw<br />
<br />
=== Disable root login ===<br />
<br />
{{Warning|Arch Linux is not fine-tuned to run with a disabled root account. Users may encounter problems with this method.}}<br />
<br />
With sudo installed and configured, users may wish to disable the root login. Without root, attackers must first guess a user name configured as a sudoer as well as the user password.<br />
<br />
{{Warning|Ensure a user is properly configured as a sudoer ''before'' disabling the root account!}}<br />
<br />
The account can be locked via {{ic|passwd}}:<br />
<br />
# passwd -l root<br />
<br />
A similar command unlocks root.<br />
<br />
$ sudo passwd -u root<br />
<br />
Alternatively, edit {{ic|/etc/shadow}} and replace the root's encrypted password with "!":<br />
<br />
root:!:12345::::::<br />
<br />
To enable root login again:<br />
<br />
$ sudo passwd root<br />
<br />
==== kdesu ====<br />
<br />
kdesu may be used under KDE to launch GUI applications with root privileges. It is possible that by default kdesu will try to use su even if the root account is disabled. Fortunately one can tell kdesu to use sudo instead of su. Create/edit the file {{ic|~/.kde4/share/config/kdesurc}}:<br />
<br />
[super-user-command]<br />
super-user-command=sudo<br />
<br />
==== PolicyKit ====<br />
<br />
When disabling the root account, it is necessary to change the [[PolicyKit]] configuration for local authorization to reflect that. The default is to ask for the root password, so that must be changed. With polkit-1, this can be achieved by editing {{ic|/etc/polkit-1/localauthority.conf.d/50-localauthority.conf}} so that {{ic|1=AdminIdentities=unix-user:0}} is replaced with something else, depending on the system configuration. It can be a list of users and groups, for example:<br />
<br />
AdminIdentities=unix-group:wheel<br />
<br />
or<br />
<br />
AdminIdentities=unix-user:me;unixuser:mom;unix-group:wheel<br />
<br />
For more information, see {{ic|man pklocalauthority}}.<br />
<br />
==== NetworkManager ====<br />
<br />
Even with the above PolicyKit configuration you still need to configure a policy for NetworkManager. This is documented on the [[NetworkManager#Can.27t_edit_connections_as_normal_user|NetworkManager]] page of this wiki.<br />
<br />
=== Harden with Sudo Example ===<br />
<br />
Lets say you create 3 users: admin, devel, and Joe<br />
admin is used for journalctl, systemctl, mount, kill, and iptables.<br />
devel is used for installing packages, and editing config's<br />
Joe is the user you log in with. Let's let him reboot, shutdown, and use netctl<br />
<br />
Edit /etc/pam.d/su and /etc/pam.d/su-1<br />
Require user be in the wheel group, but don't put anyone in it.<br />
#%PAM-1.0<br />
auth sufficient pam_rootok.so<br />
# Uncomment the following line to implicitly trust users in the "wheel" group.<br />
#auth sufficient pam_wheel.so trust use_uid<br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
auth required pam_unix.so<br />
account required pam_unix.so<br />
session required pam_unix.so<br />
<br />
Limit SSH login to the 'ssh' group, Only put Joe in it<br />
groupadd -r ssh<br />
gpasswd -a Joe ssh<br />
echo 'AllowGroups ssh' >> /etc/ssh/sshd_config<br />
systemctl restart sshd.service<br />
<br />
Lets add users to other goups.<br />
for g in network power ;do ;gpasswd -a Joe $g ;done<br />
for g in network power disk ;do ;gpasswd -a Joe $g ;done<br />
<br />
Set permissions on configs so devel can edit them.<br />
chown -R devel:root /etc/{http,openvpn,cups,zsh,vim,screenrc}<br />
<br />
Cmnd_Alias POWER = /usr/bin/shutdown -h now, /usr/bin/halt, /usr/bin/poweroff, /usr/bin/reboot<br />
Cmnd_Alias DISK = /usr/bin/mount, /usr/bin/umount<br />
Cmnd_Alias SYSTEMD = /usr/bin/journalctl, /usr/bin/systemctl<br />
Cmnd_Alias KILL = /usr/bin/kill<br />
Cmnd_Alias PKGMAN = /usr/bin/pacman<br />
Cmnd_Alias NETWORK = /usr/bin/netctl<br />
Cmnd_Alias SU_ADMIN = /usr/bin/su – admin<br />
Cmnd_Alias SU_DEVEL = /usr/bin/su – devel<br />
root ALL = (ALL) ALL<br />
admin ALL = (root) SYSTEMD, KILL<br />
devel ALL = (root) PKGMAN<br />
Joe ALL = (root) SU_ADMIN, SU_DEVEL<br />
%power ALL = (root) NOPASSWD: POWER<br />
%network ALL = (root) NETWORK <br />
<br />
With this setup, you will almost never need to login as the Root user.<br />
<br />
Joe can connect to his home WiFi<br />
sudo -- netctl start home<br />
sudo -- poweroff<br />
<br />
Joe can not use netctl as any other user like admin...<br />
sudo -u admin -- netctl start home<br />
<br />
When Joe needs to use journalctl or kill run away process he can switch to that user<br />
sudo su – admin<br />
sudo su – devel<br />
<br />
But not Root<br />
sudo su – root<br />
<br />
If joe want to start a gnu-screen session as admin he can do it like this<br />
sudo su – admin<br />
admin% chown admin:tty `echo $TTY`<br />
admin% screen<br />
<br />
== Troubleshooting ==<br />
<br />
=== SSH TTY Issues ===<br />
<br />
SSH does not allocate a tty by default when running a remote command. Without a tty, sudo cannot disable echo when prompting for a password. You can use ssh's {{ic|-tt}} option to force it to allocate a tty (or {{ic|-t}} twice).<br />
<br />
The {{ic|Defaults}} option {{ic|requiretty}} only allows the user to run sudo if they have a tty.<br />
<br />
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear text. You have to run "ssh -t hostname sudo <cmd>".<br />
#<br />
#Defaults requiretty<br />
<br />
=== Display User Privileges ===<br />
<br />
You can find out what privileges a particular user has with the following command:<br />
<br />
$ sudo -lU yourusename<br />
<br />
Or view your own with:<br />
<br />
{{hc|$ sudo -l|<nowiki><br />
Matching Defaults entries for yourusename on this host:<br />
loglinelen=0, logfile=/var/log/sudo.log, log_year, syslog=auth, mailto=webmaster@gmail.com, mail_badpass, mail_no_user,<br />
mail_no_perms,env_reset, always_set_home, tty_tickets, lecture=always, pwfeedback, rootpw, set_home<br />
<br />
User yourusename may run the following commands on this host:<br />
<br />
(ALL) ALL<br />
(ALL) NOPASSWD: /usr/bin/lsof, /bin/nice, /usr/bin/su, /usr/bin/locate, /usr/bin/find, /usr/bin/rsync, /usr/bin/strace,<br />
(ALL) /bin/kill, /usr/bin/nice, /usr/bin/ionice, /usr/bin/top, /usr/bin/killall, /usr/bin/ps, /usr/bin/pkill<br />
(ALL) /usr/bin/gparted, /usr/bin/pacman<br />
(ALL) /usr/local/bin/synergyc, /usr/local/bin/synergys<br />
(ALL) /usr/bin/vim, /usr/bin/nano, /usr/bin/cat<br />
(root) NOPASSWD: /usr/local/bin/synergyc</nowiki>}}<br />
<br />
=== Permissive Umask ===<br />
<br />
Sudo will union the user's [[umask]] value with its own umask (which defaults to 0022). This prevents sudo from creating files with more open permissions than the user's umask allows. While this is a sane default if no custom umask is in use, this can lead to situations where a utility run by sudo may create files with different permissions than if run by root directly. If errors arise from this, sudo provides a means to fix the umask, even if the desired umask is more permissive than the umask that the user has specified. Adding this (using {{ic|visudo}}) will override sudo's default behavior:<br />
<br />
Defaults umask = 0022<br />
Defaults umask_override<br />
<br />
This sets sudo's umask to root's default umask (0022) and overrides the default behavior, always using the indicated umask regardless of what umask the user as set.<br />
<br />
<br />
=== Defaults Skeleton ===<br />
<br />
The authors site has a [http://www.gratisoft.us/sudo/sudoers.man.html#sudoers_options list of all the options] that can be used with the {{ic|Defaults}} command in the {{ic|/etc/sudoers}} file.<br />
<br />
The full list of options ''(parsed from the version 1.8.7 source code)'' is below in a format optimized for copying and pasting into your sudoers files for quick editing.<br />
<br />
{{bc|<nowiki>#Defaults always_set_home<br />
# If enabled, sudo will set the HOME environment variable to the home directory of the target user<br />
# (which is root unless the -u option is used). This effectively means that the -H option<br />
# always_set_home is only effective for configurations where either env_reset is disabled or HOME is present<br />
# in the env_keep list. Default: OFF<br />
<br />
#Defaults authenticate<br />
# If set, users must authenticate themselves via a password (or other means of authentication)<br />
# before they may run commands. This default may be overridden via the PASSWD and NOPASSWD<br />
<br />
#Defaults closefrom_override<br />
# If set, the user may use sudo's -C option which overrides the default starting<br />
# point at which sudo begins closing open file descriptors. Default: OFF<br />
<br />
#Defaults compress_io<br />
# If set, and sudo is configured to log a command's input or output, the I/O logs will be<br />
# compressed using zlib. This flag is on by default when sudo is compiled with zlib support.<br />
<br />
#Defaults env_editor<br />
# If set, visudo will use the value of the EDITOR or VISUAL environment variables before falling back on the default<br />
# editor list. Note that this may create a security hole as it allows th separated list of editors in the editor<br />
# variable. visudo will then only use the EDITOR or VISUAL if they match a value specified in editor. On by default.<br />
<br />
#Defaults env_reset<br />
# If set, sudo will run the command in a minimal environment containing the TERM, PATH, HOME, MAIL, SHELL, LOGNAME,<br />
# USER, USERNAME and SUDO_* variables. Any variables in the caller's env in the file specified by the env_file<br />
# option (if any). The default contents of the env_keep and env_check lists are displayed when sudo is run by<br />
# root with the -V option.<br />
<br />
#Defaults fast_glob<br />
# Normally, sudo uses the glob(3) function to do shell-style globbing when matching path names.<br />
# However, since it accesses the file system, glob(3) can take a long time to complete for som (automounted).<br />
# The fast_glob option causes sudo to use the fnmatch(3) function, which does not access the file system to do<br />
# its matching. The disadvantage of fast_glob is that it is unable to ma names that include globbing characters<br />
# are used with the negation operator, '!', as such rules can be trivially bypassed. As such, this option should<br />
# not be used when sudoers contains rules that<br />
<br />
#Defaults fqdn<br />
# Set this flag if you want to put fully qualified host names in the sudoers file. I.e., instead of myhost you<br />
# would use myhost.mydomain.edu. You may still use the short form if you wish (and sudo unusable if DNS stops<br />
# working (for example if the machine is not plugged into the network). Also note that you must use the<br />
# host's official name as DNS knows it. That is, you may not use a all aliases from DNS. If your machine's<br />
# host name (as returned by the hostname command) is already fully qualified you shouldn't need to set fqdn.<br />
# Default: OFF<br />
<br />
#Defaults ignore_dot<br />
# If set, sudo will ignore '.' or '' (current dir) in the PATH environment variable; the PATH<br />
# itself is not modified. Default: OFF<br />
<br />
#Defaults ignore_local_sudoers<br />
# If set via LDAP, parsing of /etc/sudoers will be skipped. This is intended for Enterprises that wish to prevent<br />
# the usage of local sudoers files so that only LDAP is used. /etc/sudoers does not even need to exist.<br />
# Since this option tells sudo how to behave when no specific LDAP entries have been matched, this sudo<br />
# Option is only meaningful for the cn=default<br />
<br />
#Defaults insults<br />
# If set, sudo will insult users when they enter an incorrect password. Default: OFF<br />
<br />
#Defaults log_host<br />
# If set, the host name will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults log_input<br />
# If set, sudo will run the command in a pseudo tty and log all user input. If the standard<br />
# input is not connected to the user's tty, due to I/O redirection or because the command is part Input is logged<br />
# to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that<br />
# is included in the normal sudo log line, prefixed with TSID=. Note that user input may contain sensitive<br />
# information such as passwords (even if they are not echoed to the screen), which will be stored in the log file<br />
# unencrypted.<br />
<br />
#Defaults log_output<br />
# If set, sudo will run the command in a pseudo tty and log all output that is sent to the<br />
# screen, similar to the script(1) command. If the standard output or standard error is not connec is also captured and<br />
# stored in separate log files. Output is logged to the directory specified by the iolog_dir option (/var/log/sudo-io<br />
# by default) using a unique session ID that is included in the normal sudo log line, prefixed with TSID=. The Output<br />
# logs may be viewed with the sudoreplay(8) utility, which can also be used to list or search the available logs.<br />
<br />
#Defaults log_year<br />
# If set, the four-digit year will be logged in the (non-syslog) sudo log file. Default: OFF<br />
<br />
#Defaults long_otp_prompt<br />
# When validating with a One Time Password (OTP) scheme such as S/Key or OPIE, a two-line<br />
# prompt is used to make it easier to cut and paste the challenge to a local window<br />
<br />
#Defaults mail_always<br />
# Send mail to the mailto user every time a users runs sudo. Default: OFF<br />
<br />
#Defaults mail_badpass<br />
# Send mail to the mailto user if the user running sudo does not enter the correct password.<br />
# Default: OFF<br />
<br />
#Defaults mail_no_host<br />
# If set, mail will be sent to the mailto user if the invoking user exists in the sudoers<br />
# file, but is not allowed to run commands on the current host. Default: OFF<br />
<br />
#Defaults mail_no_perms<br />
# If set, mail will be sent to the mailto user if the invoking user is allowed to use sudo<br />
# but the command they are trying is not listed in their sudoers file entry or is explicitly denied<br />
<br />
#Defaults mail_no_user<br />
# If set, mail will be sent to the mailto user if the invoking user is not in the sudoers file.<br />
# Default: ON<br />
<br />
#Defaults noexec<br />
# If set, all commands run via sudo will behave as if the NOEXEC tag has been set, unless overridden<br />
# by a EXEC tag. See the description of NOEXEC and EXEC below as well as the "PREVENTING SHE<br />
<br />
#Defaults path_info<br />
# Normally, sudo will tell the user when a command could not be found in their PATH environment<br />
# variable. Some sites may wish to disable this as it could be used to gather information on t the executable is<br />
# simply not in the user's PATH, sudo will tell the user that they are not allowed to run it, which can be confusing.<br />
# Default: ON<br />
<br />
#Defaults passprompt_override<br />
# The password prompt specified by passprompt will normally only be used if the password prompt provided by<br />
# systems such as PAM matches the string "Password:"<br />
<br />
#Defaults preserve_groups<br />
# By default, sudo will initialize the group vector to the list of groups the target<br />
# user is in. When preserve_groups is set, the user's existing group vector is left unaltered.<br />
<br />
#Defaults pwfeedback<br />
# By default, sudo reads the password like most other Unix programs, by turning off echo<br />
# until the user hits the return (or enter) key. Some users become confused by this as it appears to the user<br />
# presses a key. Note that this does have a security impact as an onlooker may be able to determine the length of<br />
# the password being entered. Default: OFF<br />
<br />
#Defaults requiretty<br />
# If set, sudo will only run when the user is logged in to a real tty. When this flag is set,<br />
# sudo can only be run from a login session and not via other means such as cron(8) or cgi-bin<br />
<br />
#Defaults root_sudo<br />
# If set, root is allowed to run sudo too. Disabling this prevents users from "chaining" sudo<br />
# commands to get a root shell by doing something like "sudo sudo /bin/sh". Note, however, that real additional<br />
# security; it exists purely for historical reasons. Default: ON<br />
<br />
#Defaults rootpw<br />
# If set, sudo will prompt for the root password instead of the password of the invoking user.<br />
# Default: OFF<br />
<br />
#Defaults runaspw<br />
# If set, sudo will prompt for the password of the user defined by the runas_default option<br />
# (defaults to root) instead of the password of the invoking user. Default: OFF<br />
<br />
#Defaults set_home<br />
# If enabled and sudo is invoked with the -s option the HOME environment variable will be set<br />
# to the home directory of the target user (which is root unless the -u option is used). So set_home is only<br />
# effective for configs where either env_reset is disabled or HOME is present in the env_keep list. Default: OFF<br />
<br />
#Defaults set_logname<br />
# Normally, sudo will set the LOGNAME, USER and USERNAME environment variables to the name<br />
# of the target user (usually root unless the -u option is given). However, since some programs ( may be desirable<br />
# to change this behavior. This can be done by negating the set_logname option. Note that if the env_reset option<br />
# has not been disabled, entries in the env_keep list will override<br />
<br />
#Defaults set_utmp<br />
# When enabled, sudo will create an entry in the utmp (or utmpx) file when a pseudo-tty is<br />
# allocated. A pseudo-tty is allocated by sudo when the log_input, log_output or use_pty flags are e the tty, time,<br />
# type and pid fields updated. Default: ON<br />
<br />
#Defaults setenv<br />
# Allow the user to disable the env_reset option from the command line via the -E option.<br />
# Additionally, environment variables set via the command line are not subject to the restrictions impo variables<br />
# in this manner. Default: OFF<br />
<br />
#Defaults shell_noargs<br />
# If set and sudo is invoked with no arguments it acts as if the -s option had been given.<br />
# That is, it runs a shell as root (the shell is determined by the SHELL environment variable if is off by default.<br />
<br />
#Defaults stay_setuid<br />
# Normally, when sudo executes a command the real and effective UIDs are set to the target<br />
# user (root by default). This option changes that behaviour such that the real UID is left as the systems that<br />
# disable some potentially dangerous functionality when a program is run setuid. This option is only effective on<br />
# systems with either the setreuid() or setresuid() function. This flag<br />
<br />
#Defaults targetpw<br />
# If set, sudo will prompt for the password of the user specified by the -u option (defaults to root) instead<br />
# of the password of the invoking user. In addition, the timestamp file name will passwd database as an argument<br />
# to the -u option. Default: OFF<br />
<br />
#Defaults tty_tickets<br />
# If set, users must authenticate on a per-tty basis. With this flag enabled, sudo will<br />
# use a file named for the tty the user is logged in on in the user's time stamp directory.<br />
<br />
#Defaults umask_override<br />
# If set, sudo will set the umask as specified by sudoers without modification. This makes<br />
# it possible to specify a more permissive umask in sudoers than the user's own umask and match user's umask and what<br />
# is specified in sudoers. Default: OFF<br />
<br />
#Defaults use_pty<br />
# If set, sudo will run the command in a pseudo-pty even if no I/O logging is being gone.<br />
# A malicious program run under sudo could conceivably fork a background process that retains to the u that impossible.<br />
# Default: OFF<br />
<br />
#Defaults utmp_runas<br />
# If set, sudo will store the name of the runas user when updating the utmp (or utmpx) file.<br />
# By default, sudo stores the name of the invoking user. Default: OFF<br />
<br />
#Defaults visiblepw<br />
# By default, sudo will refuse to run if the user must enter a password but it is not possible to disable echo on the <br />
# terminal. If the visiblepw flag is set, sudo will prompt for a password even when it would be visible on the screen. <br />
# This makes it possible to run things like "rsh somehost sudo ls" since rsh(1) does not allocate a tty. Default: OFF<br />
<br />
#Defaults closefrom<br />
# Before it executes a command, sudo will close all open file descriptors other than standard<br />
# input, standard output and standard error (ie: file descriptors 0-2).<br />
<br />
#Defaults passwd_tries<br />
# The number of tries a user gets to enter his/her password before sudo logs the failure<br />
# and exits. The default is 3.<br />
<br />
#Defaults loglinelen<br />
# Number of characters per line for the file log. This value is used to decide when to wrap<br />
# lines for nicer log files. This has no effect on the syslog log file, only the file log.<br />
<br />
#Defaults passwd_timeout<br />
# Number of minutes before the sudo password prompt times out, or 0 for no timeout.<br />
# The timeout may include a fractional component if minute granularity is insufficient, for example 2<br />
<br />
#Defaults timestamp_timeout<br />
# Number of minutes that can elapse before sudo will ask for a passwd again. The timeout<br />
# may include a fractional component if minute granularity is insufficient, for example 2.5. timestamp will never expire.<br />
# This can be used to allow users to create or delete their own timestamps via sudo -v and sudo -k respectively.<br />
<br />
#Defaults umask<br />
# Umask to use when running the command. Negate this option or set it to 0777 to preserve<br />
# the user's umask. The actual umask that is used will be the union of the user's umask and the value o running<br />
# a command. Note on systems that use PAM, the default PAM configuration may specify its own umask which will<br />
# override the value set in sudoers.<br />
<br />
#Defaults badpass_message<br />
# Message that is displayed if a user enters an incorrect password. The default is Sorry,<br />
# try again. unless insults are enabled.<br />
<br />
#Defaults editor<br />
# A colon (':') separated list of editors allowed to be used with visudo. visudo will choose<br />
# the editor that matches the user's EDITOR environment variable if possible, or the first editor in<br />
<br />
#Defaults iolog_dir<br />
# The top-level directory to use when constructing the path name for the input/output log<br />
# directory. Only used if the log_input or log_output options are enabled or when the LOG_INPUT or L directory.<br />
# The default is "/var/log/sudo-io". The following percent (%) escape sequences are supported:<br />
# %{seq} - expanded to base-36 sequence number, such as 0100A5, to form a new directory, e.g. 01/00/A5<br />
# %{user} - expanded to the invoking user's login name<br />
# %{group} - expanded to the name of the invoking user's real group ID<br />
# %{runas_user} - expanded to the login name of the user the command will be run as (e.g. root)<br />
# %{runas_group} - expanded to the group name of the user the command will be run as (e.g. wheel)<br />
# %{hostname} - expanded to the local host name without the domain name<br />
# %{command} - expanded to the base name of the command being run In addition, any escape sequences supported by<br />
# strftime() function will be expanded. To include a literal % character, the string %% should be used.<br />
<br />
#Defaults iolog_file<br />
# The path name, relative to iolog_dir, in which to store input/output logs when the log_input or log_output options are<br />
# enabled or when the LOG_INPUT or LOG_OUTPUT tags are present for a See the iolog_dir option above for a list of<br />
# supported percent (%) escape sequences. In addition to the escape sequences, path names that end in six or more Xs will<br />
# have the Xs replaced with a unique combination of digits and letters, similar to the mktemp() function.<br />
<br />
#Defaults mailsub<br />
# Subject of the mail sent to the mailto user. The escape %h will expand to the host name of<br />
# the machine. Default is *** SECURITY information for %h ***.<br />
<br />
#Defaults noexec_file<br />
# This option is no longer supported. The path to the noexec file should now be set in the /etc/sudo.conf file.<br />
<br />
#Defaults passprompt<br />
# The default prompt to use when asking for a password; can be overridden via the -p option or the SUDO_PROMPT<br />
# environment variable. The following percent (%) escape sequences are supported:<br />
# %H - expanded to the local host name including the domain (only if the host name is fqdn or fqdn option is set)<br />
# %h - expanded to the local host name without the domain name<br />
# %p - expanded to the user whose password is being asked for (respects the rootpw, targetpw and runaspw flags)<br />
# %U - expanded to the login name of the user the command will be run as (defaults to root)<br />
# %u - expanded to the invoking user's login name<br />
# %% - two consecutive % characters are collapsed into a single % character<br />
# The default value is Password:.<br />
<br />
#Defaults runas_default<br />
# The default user to run commands as if the -u option is not specified on the command line. This defaults to root.<br />
<br />
#Defaults syslog_badpri<br />
# Syslog priority to use when user authenticates unsuccessfully. Defaults to alert.<br />
# alert, crit, debug, emerg, err, info, notice, and warning.<br />
<br />
#Defaults syslog_goodpri<br />
# Syslog priority to use when user authenticates successfully. Defaults to notice. See syslog_badpri for the priorities.<br />
<br />
#Defaults sudoers_locale<br />
# Locale to use when parsing the sudoers file, logging commands, and sending email.<br />
# Note that changing the locale may affect how sudoers is interpreted. Defaults to "C".<br />
<br />
#Defaults timestampdir<br />
# The directory in which sudo stores its timestamp files. The default is /var/db/sudo.<br />
<br />
#Defaults timestampowner<br />
# The owner of the timestamp directory and the timestamps stored therein. The default is root.<br />
<br />
#Defaults env_file<br />
# The env_file option specifies the fully qualified path to a file containing variables to<br />
# be set in the environment of the program being run. Entries in this file should either be of the f quotes.<br />
# Variables in this file are subject to other sudo environment settings such as env_keep and env_check.<br />
<br />
#Defaults exempt_group<br />
# Users in this group are exempt from password and PATH requirements. The group name specified should not include<br />
# a % prefix. This is not set by default.<br />
<br />
#Defaults group_plugin<br />
# A string containing a sudoers group plugin with optional arguments. This can be used to implement support for the<br />
# nonunix_group syntax described earlier. The string should consist of configuration arguments the plugin requires.<br />
# These arguments (if any) will be passed to the plugin's initialization function. If arguments are present, the<br />
# string must be enclosed in double quote For example, given /etc/sudo-group, a group file in Unix group format,<br />
# the sample group plugin can be used: Defaults group_plugin="sample_group.so /etc/sudo-group"<br />
# For more information see sudo_plugin(5).<br />
<br />
#Defaults lecture<br />
# This option controls when a short lecture will be printed along with the password prompt. The default value is once.<br />
# It has the following possible values:<br />
# always - Always lecture the user.<br />
# never - Never lecture the user.<br />
# once - Only lecture the user the first time they run sudo.<br />
# If no value is specified, a value of once is implied. Negating the option results in a value of never being used.<br />
<br />
#Defaults lecture_file<br />
# Path to a file containing an alternate sudo lecture that will be used in place of the standard lecture if the named<br />
# file exists. By default, sudo uses a built-in lecture.<br />
<br />
#Defaults listpw<br />
# This option controls when a password will be required when a user runs sudo with the -l option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD set to avoid entering a pass.<br />
# always - The user must always enter a password to use the -l option.<br />
# any - At least one of the user's sudoers entries for the current host must have the NOPASSWD set to avoid pass.<br />
# never - The user need never enter a password to use the -l option.<br />
# If no value is specified, a value of any is implied. The default value is any.<br />
<br />
#Defaults logfile<br />
# Path to the sudo log file (not the syslog log file). Setting a path turns on logging to a file;<br />
# negating this option turns it off. By default, sudo logs via syslog.<br />
<br />
#Defaults mailerflags<br />
# Flags to use when invoking mailer. Defaults to -t.<br />
<br />
#Defaults mailerpath<br />
# Path to mail program used to send warning mail. Defaults to the path to sendmail found at configure time.<br />
<br />
#Defaults mailfrom<br />
# Address to use for the "from" address when sending warning and error mail. The address should<br />
# be enclosed in double quotes (") to protect against sudo interpreting the @ sign.<br />
<br />
#Defaults mailto<br />
# Address to send warning and error mail to. The address should be enclosed in double quotes<br />
# (") to protect against sudo interpreting the @ sign. Defaults to root.<br />
<br />
#Defaults secure_path<br />
# Path used for every command run from sudo. If you don't trust the people running sudo to have a sane PATH environment<br />
# variable you may want to use this. Another use is if you want to option are not affected by secure_path.<br />
# This option is not set by default.<br />
<br />
#Defaults syslog<br />
# Syslog facility if syslog is being used for logging (negate to disable syslog logging). Defaults to auth.<br />
# authpriv (if OS supports it), auth, daemon, user, local0, local1, local2, local3, local4, local5, local6, and local7.<br />
<br />
#Defaults verifypw<br />
# This option controls when a password will be required when a user runs sudo with the -v option.<br />
# It has the following possible values:<br />
# all - All the user's sudoers entries for the current host must have the NOPASSWD flag to avoid pw.<br />
# always - The user must always enter a password to use the -v option.<br />
# any - At least one of the user's sudoers entries for the current host must have NOPASSWD to avoid pw.<br />
# never - The user need never enter a password to use the -v option<br />
# If no value is specified, a value of all is implied. Negating the option results in a value of never being used.<br />
# The default value is all.<br />
<br />
#Defaults env_check<br />
# Environment variables to be removed from the user's environment if the variable's value contains % or / characters.<br />
# This can be used to guard against printf-style format vulnerabilities value without double-quotes. The list can be<br />
# replaced, added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively. Regardless of<br />
# whether the env_reset option is ena they pass the aforementioned check. The default list of environment variables<br />
# to check is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_delete<br />
# Environment variables to be removed from the user's environment when the env_reset option is not in effect. The<br />
# argument may be a double-quoted, space-separated list or a single value w +=, -=, and ! operators respectively.<br />
# The default list of environment variables to remove is displayed when sudo is run by root with the -V option.<br />
<br />
#Defaults env_keep<br />
# Environment variables to be preserved in the user's environment when the env_reset option is in effect. This<br />
# allows fine-grained control over the environment sudo-spawned processes will r quotes. The list can be replaced,<br />
# added to, deleted from, or disabled by using the =, +=, -=, and ! operators respectively.</nowiki>}}</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Thunar&diff=281468Thunar2013-11-05T00:31:02Z<p>Hunterthomson: /* Tips and tricks */ Added info on how to hide devices from side pane</p>
<hr />
<div>[[Category:File managers]]<br />
[[es:Thunar]]<br />
[[fr:Thunar]]<br />
[[it:Thunar]]<br />
[[pl:Thunar]]<br />
[[ru:Thunar]]<br />
[[zh-CN:Thunar]]<br />
{{Article summary start}}<br />
{{Article summary text|This article discusses every aspect of the file manager named [http://thunar.xfce.org/index.html Thunar].}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Xfce}}: Thunar is installed with a nominal installation of {{Grp|xfce4}}.<br />
{{Article summary text|[[GNOME#Nautilus|Nautilus]]: Thunar is not the only file manager. There are many. For example, Nautilus is the file manager for {{Grp|gnome}}}}.<br />
{{Article summary end}}<br />
<br />
From the project [http://docs.xfce.org/xfce/thunar/start home page]:<br />
: ''Thunar is a new modern file manager for the Xfce Desktop Environment. Thunar has been designed from the ground up to be fast and easy-to-use. Its user interface is clean and intuitive, and does not include any confusing or useless options by default. Thunar is fast and responsive with a good start up time and folder load time.''<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] the {{Pkg|thunar}} package which is available in the [[official repositories]]. It is part of the {{Grp|xfce4}} group, so if you are running [[Xfce4]], you probably already have Thunar installed.<br />
<br />
=== Automounting ===<br />
<br />
Thunar uses [[GVFS]] for automounting, see [[GVFS]] for details on getting it working.<br />
<br />
=== Plugins and addons ===<br />
<br />
* {{App|Thunar Archive Plugin|Plugin which allows you to create and extract archive files using contextual menu items. It does not create or extract archives directly, but instead acts as a frontend for other programs such as File Roller ({{Pkg|file-roller}}), Ark ({{Pkg|kdeutils-ark}}) or Xarchiver ({{AUR|xarchiver}}). Part of {{Grp|xfce4-goodies}}.|http://goodies.xfce.org/projects/thunar-plugins/thunar-archive-plugin|{{Pkg|thunar-archive-plugin}}}}<br />
* {{App|Thunar Media Tags Plugin|Plugin which allows you to view detailed information about media files. It also has a bulk renamed and allows editing of media tags. It supports ID3 (the MP3 file format's system) and Ogg/Vorbis tags. Part of {{Grp|xfce4-goodies}}.|http://goodies.xfce.org/projects/thunar-plugins/thunar-media-tags-plugin|{{Pkg|thunar-media-tags-plugin}}}}<br />
* {{App|Thunar Shares Plugin|Plugin which allows you to quickly share a folder using Samba from Thunar without requiring root access. See also [[Samba#Creating user share path|how to configure directions]].|http://goodies.xfce.org/projects/thunar-plugins/thunar-shares-plugin|{{AUR|thunar-shares-plugin}}}}<br />
* {{App|[[Thunar#Thunar Volume Manager|Thunar Volume Manager]]|Automatic management of removeable devices in Thunar. Part of {{Grp|xfce4}}.|http://goodies.xfce.org/projects/thunar-plugins/thunar-volman|{{Pkg|thunar-volman}}}}<br />
* {{App|Tumbler|External program to generate thumbnails. Also install {{Pkg|ffmpegthumbnailer}} to enable video thumbnailing.|http://git.xfce.org/xfce/tumbler/tree/README|{{Pkg|tumbler}}}}<br />
<br />
== Thunar Volume Manager ==<br />
<br />
While Thunar can support automatic mounting and unmounting of removable media, the Thunar Volume Manager allows extended functionality, such as automatically running commands or automatically opening a Thunar window for mounted media.<br />
<br />
=== Installation ===<br />
<br />
Thunar Volume Manager can be installed from the package {{Pkg|thunar-volman}} in the official repositories.<br />
<br />
=== Configuration ===<br />
<br />
It can also be configured to execute certain actions when cameras and audio players are connected. <br />
After installing the plugin:<br />
# Launch Thunar and go to ''Edit > Preferences''<br />
# Under the 'Advanced' tab, check 'Enable Volume Management'<br />
# Click configure and check the following items:<br />
#* Mount removable drives when hot-plugged.<br />
#* Mount removable media when inserted.<br />
# Also make desired changes (see the example below)<br />
Here's an example setting for making Amarok play an audio CD.<br />
Multimedia - Audio CDs: {{ic|amarok --cdplay %d}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== Using Thunar to browse remote locations ===<br />
<br />
Since Xfce 4.8 (Thunar 1.2) it is possible to browse remote locations (such as FTP servers or Samba shares) directly in Thunar, similar to the functionality found in GNOME and KDE. The {{Pkg|gvfs}}, {{Pkg|gvfs-smb}} and {{Pkg|sshfs}} packages are required to enable this functionality. These packages are available in the [[official repositories]].<br />
<br />
After a restart of Xfce an additional "Network" entry is added to Thunar's side bar and remote locations can be opened by using the following URI schemes in the location dialog (opened with {{ic|Ctrl+l}}): smb://, <nowiki>ftp://</nowiki>, ssh://, sftp://<br />
<br />
=== GVFS needs D-Bus and polkit ===<br />
<br />
If you use a standalone window manager, make sure [[D-Bus]] is launched on login, and you are running a [[polkit]] authentication agent. Otherwise GVFS will not be active. See [[General Troubleshooting#Session permissions]] for details.<br />
<br />
=== Starting in daemon mode ===<br />
<br />
Thunar may be run in daemon mode. This has several advantages, including a faster startup for Thunar, as well as Thunar running in the background and only opening a window when necessary (for instance, when a flash drive is inserted).<br />
<br />
Make sure the command {{ic|thunar --daemon}} is [[autostarting|autostarted]] on login.<br />
<br />
=== Setting the icon theme ===<br />
<br />
When using Thunar outside of Gnome or Xfce, certain packages and configurations that control which icons are used may be missing. Window Managers like Awesome and Xmonad do not come with XSettings managers, which is where Thunar looks first for it's icon setting. It is possible to install and run xfce-mcs-manager from a startup script if many Xfce4 and Gnome applications are going to be used. The gtk-icon-theme-name setting for gtk2 can be set for a user by adding something like the following to {{ic|~/.gtkrc-2.0}}:<br />
gtk-icon-theme-name = "Tango"<br />
<br />
Of course, just installing the {{Pkg|gnome-icon-theme}} package will give Thunar an icon theme to use other than the default paper icon for all items.<br />
<br />
=== Solving problem with slow cold start ===<br />
<br />
Some people still have problems with Thunar taking a long time to start for the first time. This is due to gvfs checking the network, preventing Thunar from starting until gvfs finishes its operations. To change this behaviour, edit {{ic|/usr/share/gvfs/mounts/network.mount}} and change '''AutoMount=true''' to '''AutoMount=false'''.<br />
<br />
=== Hide Shortcuts in Side Pane ===<br />
<br />
There is a hidden menu to hide Shortcuts in the Side Pane.<br />
<br />
Right click in the Side Pane where there are no shortcuts, like on the DEVICES section label. Then you will get a pop-up menu where you can uncheck items you do not want displayed.<br />
<br />
== Custom actions ==<br />
<br />
This section covers useful custom actions which can be accessed through Edit -> Configure custom actions. More examples are listed in the [http://docs.xfce.org/xfce/thunar/custom-actions thunar wiki].<br />
<br />
=== Scan for viruses ===<br />
<br />
To use this action you need to have clamav and clamtk installed.<br />
<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
! Name !! Command !! File patterns !! Appears if selection contains<br />
|-<br />
! Scan for virus<br />
| clamtk %F || * || Select all<br />
|}<br />
<br />
=== Link to Dropbox ===<br />
<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
! Name !! Command !! File patterns !! Appears if selection contains<br />
|-<br />
! Link to Dropbox<br />
| ln -s %f /path/to/DropboxFolder || * || Directories, other files<br />
|}<br />
<br />
Please note that when using many custom actions to symlink files and folder to a particular place, it might be useful to put them into the {{ic|Send To}} folder of the context menu to avoid that the menu itself gets bloated. This is fairly easy to achieve and requires a .desktop file in {{ic|~/.local/share/Thunar/sendto}} for each action to perform. Say we want to put the above dropbox symlink action into Send To, we create a {{ic|dropbox_folder.desktop}} with the following content. The new applied action will be active after restarting Thunar.<br />
<br />
{{bc|<nowiki><br />
[Desktop Entry]<br />
Type=Application<br />
Version=1.0<br />
Encoding=UTF-8<br />
Exec=ln -s %f /path/to/DropboxFolder<br />
Icon=/usr/share/icons/dropbox.png<br />
Name=Dropbox<br />
</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [http://thunar.xfce.org/index.html Thunar] project page<br />
* [http://goodies.xfce.org/projects/thunar-plugins/thunar-volman Thunar Volume Manager] project page<br />
* This [http://goodies.xfce.org/projects/thunar-plugins/start list] of plugins</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=GNOME/Evolution&diff=281420GNOME/Evolution2013-11-04T13:53:02Z<p>Hunterthomson: /* Failing to Synchronize with Server */ spelling</p>
<hr />
<div>[[Category:Email Client]]<br />
[[Category:GNOME]]<br />
Evolution is a [[GNOME]] mail client it supports IMAP, Microsoft Exchange Server and Novell GroupWise. It also has a calender function that supports vcal,csv, google calendar and many more. You can also organise your contacts, tasks and memos with Evolution. The beautiful thing about evolution is that it's easy to use and integrates with the gnome environment. You can see your calendar, tasks and location in the GNOME panel along with the weather and date. Just add the clock to your gnome panel.<br />
<br />
== Installation ==<br />
<br />
Evolution is available from the standard repositories: <br />
# pacman -S evolution<br />
<br />
Support for exchange servers:<br />
# pacman -S evolution-ews<br />
<br />
Support for web calendars (like Google calendar):<br />
# pacman -S evolution-data-server<br />
<br />
== IMAP Setup ==<br />
<br />
This is the setup for a standard IMAP mail address.<br />
Go to Edit -> Preferences -> Mail Accounts. Add a mail account insert your Name and real email adress. Then click 'forward' here you are going to select the server type, this is IMAP. Now fill in the textbox server, for the server adress and username. For the rest of the options just follow the wizard. It is very easy, if you get stuck read this guide [http://library.gnome.org/users/evolution/stable/].<br />
<br />
Unfortunately, Evolution currently (version 2.26) suffers from a serious IMAP issue, as reported in [http://bugzilla.gnome.org/show_bug.cgi?id=336076]. It appears this issue has existed for at least the past 3 years prior to this version, and it shows no signs of being dealt with soon. This bug especially affects to the point of unuseability those with slow connections. The next section shows an alternative IMAP connectivity method which works better.<br />
<br />
== Alternative IMAP Setup ==<br />
<br />
An alternative to letting Evolution connect directly to the IMAP server is to sync the IMAP server to your PC. This costs as much hard-disc space as you have mail, though it is possible to limit the folders synced in this manner (see below). An additional benefit (primary inspiration for this app) is that you have a full copy of your email, including attachments, on your PC for retrieval, even if on the move without an internet connection.<br />
<br />
To set this up, you will need to install offlineimap ([http://offlineimap.org/]). It is currently in the AUR, as well as in community, so just run the following:-<br />
# pacman -S offlineimap<br />
<br />
=== Offlineimap setup ===<br />
<br />
offlineimap takes its settings from the file ~/.offlineimaprc, which you will need to create. Most users will be able to use the .offlineimaprc below, for the most common case of a Gmail account. The settings for a general account are identical, except remotehost, ssl, and remoteport need to be set appropriately (see the comments below). See the [https://github.com/nicolas33/offlineimap official README] for more information.<br />
<br />
[general]<br />
accounts = MyAccount<br />
# Set this to the number of accounts you have.<br />
maxsyncaccounts = 1<br />
# You can set ui = TTY.TTYUI for interactive password entry if needed.<br />
# Setting it within this file (see below) is easier.<br />
ui = Noninteractive.Basic<br />
<br />
[Account MyAccount]<br />
# Each account should have a local and remote repository<br />
localrepository = MyLocal<br />
remoterepository = MyGmail<br />
# Specifies how often to do a repeated sync (if running without crond)<br />
autorefresh = 10<br />
<br />
[Repository MyLocal]<br />
type = Maildir<br />
localfolders = /home/path/to/your/maildir<br />
# This needs to be specified so the MailDir uses a folder structure<br />
# suitable to Evolution<br />
sep = /<br />
<br />
[Repository MyGmail]<br />
# Example for a gmail account<br />
type = Gmail<br />
# If using some other IMAP server, uncomment and set the following:-<br />
#remotehost = imap.gmail.com<br />
#ssl = yes<br />
#remoteport = 993<br />
# Specify the Gmail user name and password.<br />
remoteuser = yourname@gmail.com<br />
remotepass = yourpassword<br />
# realdelete is Gmail specific, setting to no ensures that deleting<br />
# a message sends it to 'All Mail' instead of the trash.<br />
realdelete = no<br />
# Use 1 here first, increase it if your connection (and the server's)<br />
# supports it.<br />
maxconnections = 1<br />
# This translates folder names such that everything (including your Inbox)<br />
# appears in the same folder (named root).<br />
nametrans = lambda foldername: re.sub('^Sent$', 'root/Sent',<br />
re.sub('^(\[G.*ail\]|INBOX)', 'root', foldername))<br />
# This excludes some folders from being synced. You will almost<br />
# certainly want to exclude 'All Mail', 'Trash', and 'Starred', at<br />
# least. Note that offlineimap does NOT honor subscription details.<br />
folderfilter = lambda foldername: foldername not in ['[Gmail]/All Mail',<br />
'[Gmail]/Trash','[Gmail]/Spam','[Gmail]/Starred']<br />
<br />
WARNING: Please note that any space indenting a line of code in .offlineimaprc would be considered as appending that line to the previous line. In other words, always make sure there is no space before any lines in your config file.<br />
<br />
Acknowledgement: This config file was done by referring both to the official example as well as to the config file in an article on http://www.linux.com (no longer available).<br />
<br />
=== First offlineimap sync and automated sync-ing ===<br />
<br />
Once you have completed your offlineimap setup, you should perform your first sync by running with your normal user account<br />
$ offlineimap<br />
Assuming you've set your password and all other settings correctly, offlineimap will begin to sync the requested repositories. This may take a long while, depending on connection speed and size of your mail account, so you should preferably find a fast connection to do this. You can run offlineimap using another interface by specifying<br />
$ offlineimap -u TTY.TTYUI<br />
This allows interactive entry of passwords.<br />
<br />
Once you've completed your first sync, you'll want to set up automatic syncing. This can be done using crond, or just by running offlineimap on startup. The disadvantage of running offlineimap on startup (with autorefresh set) is that if for any reason an error appears, your mail will just stop syncing from that point onwards. So, running through crond requires you to add the following line to your crontab.<br />
*/10 * * * * /path/to/scripts/runofflineimap >/dev/null 2>&1<br />
<br />
For those unfamiliar with crontab and/or vi, just run<br />
$ crontab -e<br />
Press 'i' to start input, type in the line above, press Esc to escape back to the prompt, and type ':wq' to save and quit. /path/to/scripts/runofflineimap should run offlineimap itself (with -o for a single run). Here is an example script for that:-<br />
<br />
#!/bin/sh<br />
# Run offlineimap through cron to fetch email periodically<br />
ps aux | grep "\/usr\/bin\/offlineimap"<br />
if [ $? -eq "0" ]; then<br />
logger -i -t offlineimap "Another instance of offlineimap running. Exiting."<br />
exit 0;<br />
else<br />
logger -i -t offlineimap "Starting offlineimap..."<br />
offlineimap -u Noninteractive.Quiet -o<br />
logger -i -t offlineimap "Done offlineimap..."<br />
exit 0;<br />
fi<br />
<br />
You should now have an automatically synced local copy of your IMAP server. Error messages (if any) will be shown in /var/log/cron.d or one of its variants.<br />
<br />
=== Evolution setup for offlineimap's maildir ===<br />
<br />
This is really quite simple, use Evolution's Account Assistant and select the Server Type "Maildir-format mail directories", under the Receiving Email section. Select also the path to your maildir (the 'root' folder if you're using a modified version of the .offlineimaprc above). You can change your 'Checking for New Mail' option to something very short, even 1 minute, since this only checks your local copy and not the server-side copy. SMTP settings are according to normal usage (does not go through offlineimap).<br />
<br />
== GMAIL Setup ==<br />
<br />
To setup a GMail account, go to Edit -> Preferences -> Mail Accounts and enter your mail account details.<br />
<br />
=== Receiving Mail ===<br />
* Server Type: POP<br />
* Server: pop.gmail.com<br />
* Username: <username>@gmail.com<br />
* Use Secure Connecetion: SSL encryption<br />
* Authenthication Type: Password<br />
<br />
Optionally fill in automatically check for new mail every ** minutes. The rest is user specific.<br />
<br />
=== Sending Mail ===<br />
<br />
* Server type: SMTP<br />
* Server: smtp.gmail.com<br />
* Port: 587<br />
* Server requires authentication: Checked<br />
* Use Secure Connection: TSL<br />
* Fill in Username: <username>@gmail.com<br />
* Authentication: PLAIN or Login<br />
<br />
You are now finished with configuring evolution for gmail. Just hit Send/ Receive in the main screen and wait for new mail.<br />
If it still didn't work, go to this link [http://tuxicity.wordpress.com/2007/03/08/howto-set-up-gmail-in-evolution-gnomes-mail-client-and-organizer/]<br />
<br />
== Gmail Calendar ==<br />
<br />
You can use your gmail calendar in evolution here's how:<br />
<br />
Go to your calendar in your browser. Click on manage calendars -> the click on the calendar you want to add -> In the Private URL section copy the URL of ICAL (green button).<br />
<br />
Now go to Evolution. Click on file -> new -> calendar .<br />
In the 'new calendar dialog box' select type: On The Web.<br />
You can fill in your own calendar name <br />
Then Copy the URL to the URL field <br />
<br />
Now you will see your google calendar in your calendar view in Evolution by the name you gave it in the Name field.<br />
<br />
'''Variant2 (with evolution-webcal):'''<br />
<br />
From Evolution click on -> new -> calendar .<br />
In the 'new calendar dialog box' select type: Google.<br />
You can fill in your own calendar name.<br />
Insert your username (not the email).<br />
Click the button "Get List" and choose the calendar you want to use.<br />
<br />
== Tudelft webmail (Exchange) ==<br />
<br />
This is the setup for your tudelft webmail for evolution. It might also work for other webmail based email accounts.<br />
<br />
Go to Edit -> Preferences -> Mail Accounts and make a mail account. For your Email Adress: <netid>@gmail.com . Be carefull your <netid>@student.tudelft.nl must be like this example: E.M.devries@student.tudelft.nl <br />
<br />
Receiving mail:<br />
Server type: Microsoft Exchange <br />
Username: <netid> this is just your netid like this example: edevries<br />
OWA URL: https://webmail.tudelft.nl -> now click 'Authenticate' and fill in your password. The mailbox will be filled in automaticlly<br />
<br />
Click Forward:<br />
The receiving options are already correct, you can select the option to automaticlly receive email every x minutes.<br />
<br />
Click Forward:<br />
Now just fill in the name of the mailbox and you are done.<br />
<br />
== Using Evolution Outside Of Gnome ==<br />
<br />
In order to use Evolution outside of Gnome desktop you must export [[GNOME Keyring|gnome-keyring]]:<br />
<br />
#!/bin/bash<br />
eval \`gnome-keyring-daemon\`<br />
export GNOME_KEYRING_PID<br />
export GNOME_KEYRING_SOCKET<br />
exit<br />
<br />
Run the above script before starting Evolution. Reboot or remove the appropriate files in your /tmp directory prior to running.<br />
<br />
== Troubleshooting ==<br />
<br />
If after some system upgrade one gets no accounts in Evolution then all is not lost.<br />
First, we can see if we got our account files in ~/.evolution/, if so, then the only solution is to just make a new account in Evolution with the same parameters. (I only lost the signatures<br />
<br />
=== Failing to Synchronize with Server ===<br />
<br />
If you change internet connections, such as switching VPN or restart X, Evolution may have problems connecting to the mail servers. You would see it endlessly trying to connect in the status bar at the bottom.<br />
<br />
A possible solution is to switch to "Work Offline" select "Don't Synchronize” in the pop-up. Then after a minute has passed, go back to On-line mode. It should now have no problem fetching from the mail servers.<br />
<br />
== References ==<br />
<br />
[http://library.gnome.org/users/evolution/stable/ Gnome Evolution Guide]<br />
<br />
[http://www.tudelft.nl/live/pagina.jsp?id=babae0a3-1479-4501-9ec4-e308153735dc&lang=nl Tudelft Evolution 2.24 Setup]</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=GNOME/Evolution&diff=281419GNOME/Evolution2013-11-04T13:51:44Z<p>Hunterthomson: /* Failing to connect to Servers */ better name</p>
<hr />
<div>[[Category:Email Client]]<br />
[[Category:GNOME]]<br />
Evolution is a [[GNOME]] mail client it supports IMAP, Microsoft Exchange Server and Novell GroupWise. It also has a calender function that supports vcal,csv, google calendar and many more. You can also organise your contacts, tasks and memos with Evolution. The beautiful thing about evolution is that it's easy to use and integrates with the gnome environment. You can see your calendar, tasks and location in the GNOME panel along with the weather and date. Just add the clock to your gnome panel.<br />
<br />
== Installation ==<br />
<br />
Evolution is available from the standard repositories: <br />
# pacman -S evolution<br />
<br />
Support for exchange servers:<br />
# pacman -S evolution-ews<br />
<br />
Support for web calendars (like Google calendar):<br />
# pacman -S evolution-data-server<br />
<br />
== IMAP Setup ==<br />
<br />
This is the setup for a standard IMAP mail address.<br />
Go to Edit -> Preferences -> Mail Accounts. Add a mail account insert your Name and real email adress. Then click 'forward' here you are going to select the server type, this is IMAP. Now fill in the textbox server, for the server adress and username. For the rest of the options just follow the wizard. It is very easy, if you get stuck read this guide [http://library.gnome.org/users/evolution/stable/].<br />
<br />
Unfortunately, Evolution currently (version 2.26) suffers from a serious IMAP issue, as reported in [http://bugzilla.gnome.org/show_bug.cgi?id=336076]. It appears this issue has existed for at least the past 3 years prior to this version, and it shows no signs of being dealt with soon. This bug especially affects to the point of unuseability those with slow connections. The next section shows an alternative IMAP connectivity method which works better.<br />
<br />
== Alternative IMAP Setup ==<br />
<br />
An alternative to letting Evolution connect directly to the IMAP server is to sync the IMAP server to your PC. This costs as much hard-disc space as you have mail, though it is possible to limit the folders synced in this manner (see below). An additional benefit (primary inspiration for this app) is that you have a full copy of your email, including attachments, on your PC for retrieval, even if on the move without an internet connection.<br />
<br />
To set this up, you will need to install offlineimap ([http://offlineimap.org/]). It is currently in the AUR, as well as in community, so just run the following:-<br />
# pacman -S offlineimap<br />
<br />
=== Offlineimap setup ===<br />
<br />
offlineimap takes its settings from the file ~/.offlineimaprc, which you will need to create. Most users will be able to use the .offlineimaprc below, for the most common case of a Gmail account. The settings for a general account are identical, except remotehost, ssl, and remoteport need to be set appropriately (see the comments below). See the [https://github.com/nicolas33/offlineimap official README] for more information.<br />
<br />
[general]<br />
accounts = MyAccount<br />
# Set this to the number of accounts you have.<br />
maxsyncaccounts = 1<br />
# You can set ui = TTY.TTYUI for interactive password entry if needed.<br />
# Setting it within this file (see below) is easier.<br />
ui = Noninteractive.Basic<br />
<br />
[Account MyAccount]<br />
# Each account should have a local and remote repository<br />
localrepository = MyLocal<br />
remoterepository = MyGmail<br />
# Specifies how often to do a repeated sync (if running without crond)<br />
autorefresh = 10<br />
<br />
[Repository MyLocal]<br />
type = Maildir<br />
localfolders = /home/path/to/your/maildir<br />
# This needs to be specified so the MailDir uses a folder structure<br />
# suitable to Evolution<br />
sep = /<br />
<br />
[Repository MyGmail]<br />
# Example for a gmail account<br />
type = Gmail<br />
# If using some other IMAP server, uncomment and set the following:-<br />
#remotehost = imap.gmail.com<br />
#ssl = yes<br />
#remoteport = 993<br />
# Specify the Gmail user name and password.<br />
remoteuser = yourname@gmail.com<br />
remotepass = yourpassword<br />
# realdelete is Gmail specific, setting to no ensures that deleting<br />
# a message sends it to 'All Mail' instead of the trash.<br />
realdelete = no<br />
# Use 1 here first, increase it if your connection (and the server's)<br />
# supports it.<br />
maxconnections = 1<br />
# This translates folder names such that everything (including your Inbox)<br />
# appears in the same folder (named root).<br />
nametrans = lambda foldername: re.sub('^Sent$', 'root/Sent',<br />
re.sub('^(\[G.*ail\]|INBOX)', 'root', foldername))<br />
# This excludes some folders from being synced. You will almost<br />
# certainly want to exclude 'All Mail', 'Trash', and 'Starred', at<br />
# least. Note that offlineimap does NOT honor subscription details.<br />
folderfilter = lambda foldername: foldername not in ['[Gmail]/All Mail',<br />
'[Gmail]/Trash','[Gmail]/Spam','[Gmail]/Starred']<br />
<br />
WARNING: Please note that any space indenting a line of code in .offlineimaprc would be considered as appending that line to the previous line. In other words, always make sure there is no space before any lines in your config file.<br />
<br />
Acknowledgement: This config file was done by referring both to the official example as well as to the config file in an article on http://www.linux.com (no longer available).<br />
<br />
=== First offlineimap sync and automated sync-ing ===<br />
<br />
Once you have completed your offlineimap setup, you should perform your first sync by running with your normal user account<br />
$ offlineimap<br />
Assuming you've set your password and all other settings correctly, offlineimap will begin to sync the requested repositories. This may take a long while, depending on connection speed and size of your mail account, so you should preferably find a fast connection to do this. You can run offlineimap using another interface by specifying<br />
$ offlineimap -u TTY.TTYUI<br />
This allows interactive entry of passwords.<br />
<br />
Once you've completed your first sync, you'll want to set up automatic syncing. This can be done using crond, or just by running offlineimap on startup. The disadvantage of running offlineimap on startup (with autorefresh set) is that if for any reason an error appears, your mail will just stop syncing from that point onwards. So, running through crond requires you to add the following line to your crontab.<br />
*/10 * * * * /path/to/scripts/runofflineimap >/dev/null 2>&1<br />
<br />
For those unfamiliar with crontab and/or vi, just run<br />
$ crontab -e<br />
Press 'i' to start input, type in the line above, press Esc to escape back to the prompt, and type ':wq' to save and quit. /path/to/scripts/runofflineimap should run offlineimap itself (with -o for a single run). Here is an example script for that:-<br />
<br />
#!/bin/sh<br />
# Run offlineimap through cron to fetch email periodically<br />
ps aux | grep "\/usr\/bin\/offlineimap"<br />
if [ $? -eq "0" ]; then<br />
logger -i -t offlineimap "Another instance of offlineimap running. Exiting."<br />
exit 0;<br />
else<br />
logger -i -t offlineimap "Starting offlineimap..."<br />
offlineimap -u Noninteractive.Quiet -o<br />
logger -i -t offlineimap "Done offlineimap..."<br />
exit 0;<br />
fi<br />
<br />
You should now have an automatically synced local copy of your IMAP server. Error messages (if any) will be shown in /var/log/cron.d or one of its variants.<br />
<br />
=== Evolution setup for offlineimap's maildir ===<br />
<br />
This is really quite simple, use Evolution's Account Assistant and select the Server Type "Maildir-format mail directories", under the Receiving Email section. Select also the path to your maildir (the 'root' folder if you're using a modified version of the .offlineimaprc above). You can change your 'Checking for New Mail' option to something very short, even 1 minute, since this only checks your local copy and not the server-side copy. SMTP settings are according to normal usage (does not go through offlineimap).<br />
<br />
== GMAIL Setup ==<br />
<br />
To setup a GMail account, go to Edit -> Preferences -> Mail Accounts and enter your mail account details.<br />
<br />
=== Receiving Mail ===<br />
* Server Type: POP<br />
* Server: pop.gmail.com<br />
* Username: <username>@gmail.com<br />
* Use Secure Connecetion: SSL encryption<br />
* Authenthication Type: Password<br />
<br />
Optionally fill in automatically check for new mail every ** minutes. The rest is user specific.<br />
<br />
=== Sending Mail ===<br />
<br />
* Server type: SMTP<br />
* Server: smtp.gmail.com<br />
* Port: 587<br />
* Server requires authentication: Checked<br />
* Use Secure Connection: TSL<br />
* Fill in Username: <username>@gmail.com<br />
* Authentication: PLAIN or Login<br />
<br />
You are now finished with configuring evolution for gmail. Just hit Send/ Receive in the main screen and wait for new mail.<br />
If it still didn't work, go to this link [http://tuxicity.wordpress.com/2007/03/08/howto-set-up-gmail-in-evolution-gnomes-mail-client-and-organizer/]<br />
<br />
== Gmail Calendar ==<br />
<br />
You can use your gmail calendar in evolution here's how:<br />
<br />
Go to your calendar in your browser. Click on manage calendars -> the click on the calendar you want to add -> In the Private URL section copy the URL of ICAL (green button).<br />
<br />
Now go to Evolution. Click on file -> new -> calendar .<br />
In the 'new calendar dialog box' select type: On The Web.<br />
You can fill in your own calendar name <br />
Then Copy the URL to the URL field <br />
<br />
Now you will see your google calendar in your calendar view in Evolution by the name you gave it in the Name field.<br />
<br />
'''Variant2 (with evolution-webcal):'''<br />
<br />
From Evolution click on -> new -> calendar .<br />
In the 'new calendar dialog box' select type: Google.<br />
You can fill in your own calendar name.<br />
Insert your username (not the email).<br />
Click the button "Get List" and choose the calendar you want to use.<br />
<br />
== Tudelft webmail (Exchange) ==<br />
<br />
This is the setup for your tudelft webmail for evolution. It might also work for other webmail based email accounts.<br />
<br />
Go to Edit -> Preferences -> Mail Accounts and make a mail account. For your Email Adress: <netid>@gmail.com . Be carefull your <netid>@student.tudelft.nl must be like this example: E.M.devries@student.tudelft.nl <br />
<br />
Receiving mail:<br />
Server type: Microsoft Exchange <br />
Username: <netid> this is just your netid like this example: edevries<br />
OWA URL: https://webmail.tudelft.nl -> now click 'Authenticate' and fill in your password. The mailbox will be filled in automaticlly<br />
<br />
Click Forward:<br />
The receiving options are already correct, you can select the option to automaticlly receive email every x minutes.<br />
<br />
Click Forward:<br />
Now just fill in the name of the mailbox and you are done.<br />
<br />
== Using Evolution Outside Of Gnome ==<br />
<br />
In order to use Evolution outside of Gnome desktop you must export [[GNOME Keyring|gnome-keyring]]:<br />
<br />
#!/bin/bash<br />
eval \`gnome-keyring-daemon\`<br />
export GNOME_KEYRING_PID<br />
export GNOME_KEYRING_SOCKET<br />
exit<br />
<br />
Run the above script before starting Evolution. Reboot or remove the appropriate files in your /tmp directory prior to running.<br />
<br />
== Troubleshooting ==<br />
<br />
If after some system upgrade one gets no accounts in Evolution then all is not lost.<br />
First, we can see if we got our account files in ~/.evolution/, if so, then the only solution is to just make a new account in Evolution with the same parameters. (I only lost the signatures<br />
<br />
=== Failing to Synchronize with Server ===<br />
<br />
If you change internet connections (like switch VPN) or restart X, Evolution may have problems connecting to the mail servers. You would see it endlessly trying to connect in the status bar at the bottom.<br />
<br />
A possible solution is to switch to "Work Offline" select "Don't Synchronize” in the pop-up. Then after a minute has passed, go back to On-line mode. It should now have no problem fetching from the mail servers.<br />
<br />
== References ==<br />
<br />
[http://library.gnome.org/users/evolution/stable/ Gnome Evolution Guide]<br />
<br />
[http://www.tudelft.nl/live/pagina.jsp?id=babae0a3-1479-4501-9ec4-e308153735dc&lang=nl Tudelft Evolution 2.24 Setup]</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=GNOME/Evolution&diff=281418GNOME/Evolution2013-11-04T13:50:55Z<p>Hunterthomson: /* Troubleshooting */ Added a solution to a Synchronization problem</p>
<hr />
<div>[[Category:Email Client]]<br />
[[Category:GNOME]]<br />
Evolution is a [[GNOME]] mail client it supports IMAP, Microsoft Exchange Server and Novell GroupWise. It also has a calender function that supports vcal,csv, google calendar and many more. You can also organise your contacts, tasks and memos with Evolution. The beautiful thing about evolution is that it's easy to use and integrates with the gnome environment. You can see your calendar, tasks and location in the GNOME panel along with the weather and date. Just add the clock to your gnome panel.<br />
<br />
== Installation ==<br />
<br />
Evolution is available from the standard repositories: <br />
# pacman -S evolution<br />
<br />
Support for exchange servers:<br />
# pacman -S evolution-ews<br />
<br />
Support for web calendars (like Google calendar):<br />
# pacman -S evolution-data-server<br />
<br />
== IMAP Setup ==<br />
<br />
This is the setup for a standard IMAP mail address.<br />
Go to Edit -> Preferences -> Mail Accounts. Add a mail account insert your Name and real email adress. Then click 'forward' here you are going to select the server type, this is IMAP. Now fill in the textbox server, for the server adress and username. For the rest of the options just follow the wizard. It is very easy, if you get stuck read this guide [http://library.gnome.org/users/evolution/stable/].<br />
<br />
Unfortunately, Evolution currently (version 2.26) suffers from a serious IMAP issue, as reported in [http://bugzilla.gnome.org/show_bug.cgi?id=336076]. It appears this issue has existed for at least the past 3 years prior to this version, and it shows no signs of being dealt with soon. This bug especially affects to the point of unuseability those with slow connections. The next section shows an alternative IMAP connectivity method which works better.<br />
<br />
== Alternative IMAP Setup ==<br />
<br />
An alternative to letting Evolution connect directly to the IMAP server is to sync the IMAP server to your PC. This costs as much hard-disc space as you have mail, though it is possible to limit the folders synced in this manner (see below). An additional benefit (primary inspiration for this app) is that you have a full copy of your email, including attachments, on your PC for retrieval, even if on the move without an internet connection.<br />
<br />
To set this up, you will need to install offlineimap ([http://offlineimap.org/]). It is currently in the AUR, as well as in community, so just run the following:-<br />
# pacman -S offlineimap<br />
<br />
=== Offlineimap setup ===<br />
<br />
offlineimap takes its settings from the file ~/.offlineimaprc, which you will need to create. Most users will be able to use the .offlineimaprc below, for the most common case of a Gmail account. The settings for a general account are identical, except remotehost, ssl, and remoteport need to be set appropriately (see the comments below). See the [https://github.com/nicolas33/offlineimap official README] for more information.<br />
<br />
[general]<br />
accounts = MyAccount<br />
# Set this to the number of accounts you have.<br />
maxsyncaccounts = 1<br />
# You can set ui = TTY.TTYUI for interactive password entry if needed.<br />
# Setting it within this file (see below) is easier.<br />
ui = Noninteractive.Basic<br />
<br />
[Account MyAccount]<br />
# Each account should have a local and remote repository<br />
localrepository = MyLocal<br />
remoterepository = MyGmail<br />
# Specifies how often to do a repeated sync (if running without crond)<br />
autorefresh = 10<br />
<br />
[Repository MyLocal]<br />
type = Maildir<br />
localfolders = /home/path/to/your/maildir<br />
# This needs to be specified so the MailDir uses a folder structure<br />
# suitable to Evolution<br />
sep = /<br />
<br />
[Repository MyGmail]<br />
# Example for a gmail account<br />
type = Gmail<br />
# If using some other IMAP server, uncomment and set the following:-<br />
#remotehost = imap.gmail.com<br />
#ssl = yes<br />
#remoteport = 993<br />
# Specify the Gmail user name and password.<br />
remoteuser = yourname@gmail.com<br />
remotepass = yourpassword<br />
# realdelete is Gmail specific, setting to no ensures that deleting<br />
# a message sends it to 'All Mail' instead of the trash.<br />
realdelete = no<br />
# Use 1 here first, increase it if your connection (and the server's)<br />
# supports it.<br />
maxconnections = 1<br />
# This translates folder names such that everything (including your Inbox)<br />
# appears in the same folder (named root).<br />
nametrans = lambda foldername: re.sub('^Sent$', 'root/Sent',<br />
re.sub('^(\[G.*ail\]|INBOX)', 'root', foldername))<br />
# This excludes some folders from being synced. You will almost<br />
# certainly want to exclude 'All Mail', 'Trash', and 'Starred', at<br />
# least. Note that offlineimap does NOT honor subscription details.<br />
folderfilter = lambda foldername: foldername not in ['[Gmail]/All Mail',<br />
'[Gmail]/Trash','[Gmail]/Spam','[Gmail]/Starred']<br />
<br />
WARNING: Please note that any space indenting a line of code in .offlineimaprc would be considered as appending that line to the previous line. In other words, always make sure there is no space before any lines in your config file.<br />
<br />
Acknowledgement: This config file was done by referring both to the official example as well as to the config file in an article on http://www.linux.com (no longer available).<br />
<br />
=== First offlineimap sync and automated sync-ing ===<br />
<br />
Once you have completed your offlineimap setup, you should perform your first sync by running with your normal user account<br />
$ offlineimap<br />
Assuming you've set your password and all other settings correctly, offlineimap will begin to sync the requested repositories. This may take a long while, depending on connection speed and size of your mail account, so you should preferably find a fast connection to do this. You can run offlineimap using another interface by specifying<br />
$ offlineimap -u TTY.TTYUI<br />
This allows interactive entry of passwords.<br />
<br />
Once you've completed your first sync, you'll want to set up automatic syncing. This can be done using crond, or just by running offlineimap on startup. The disadvantage of running offlineimap on startup (with autorefresh set) is that if for any reason an error appears, your mail will just stop syncing from that point onwards. So, running through crond requires you to add the following line to your crontab.<br />
*/10 * * * * /path/to/scripts/runofflineimap >/dev/null 2>&1<br />
<br />
For those unfamiliar with crontab and/or vi, just run<br />
$ crontab -e<br />
Press 'i' to start input, type in the line above, press Esc to escape back to the prompt, and type ':wq' to save and quit. /path/to/scripts/runofflineimap should run offlineimap itself (with -o for a single run). Here is an example script for that:-<br />
<br />
#!/bin/sh<br />
# Run offlineimap through cron to fetch email periodically<br />
ps aux | grep "\/usr\/bin\/offlineimap"<br />
if [ $? -eq "0" ]; then<br />
logger -i -t offlineimap "Another instance of offlineimap running. Exiting."<br />
exit 0;<br />
else<br />
logger -i -t offlineimap "Starting offlineimap..."<br />
offlineimap -u Noninteractive.Quiet -o<br />
logger -i -t offlineimap "Done offlineimap..."<br />
exit 0;<br />
fi<br />
<br />
You should now have an automatically synced local copy of your IMAP server. Error messages (if any) will be shown in /var/log/cron.d or one of its variants.<br />
<br />
=== Evolution setup for offlineimap's maildir ===<br />
<br />
This is really quite simple, use Evolution's Account Assistant and select the Server Type "Maildir-format mail directories", under the Receiving Email section. Select also the path to your maildir (the 'root' folder if you're using a modified version of the .offlineimaprc above). You can change your 'Checking for New Mail' option to something very short, even 1 minute, since this only checks your local copy and not the server-side copy. SMTP settings are according to normal usage (does not go through offlineimap).<br />
<br />
== GMAIL Setup ==<br />
<br />
To setup a GMail account, go to Edit -> Preferences -> Mail Accounts and enter your mail account details.<br />
<br />
=== Receiving Mail ===<br />
* Server Type: POP<br />
* Server: pop.gmail.com<br />
* Username: <username>@gmail.com<br />
* Use Secure Connecetion: SSL encryption<br />
* Authenthication Type: Password<br />
<br />
Optionally fill in automatically check for new mail every ** minutes. The rest is user specific.<br />
<br />
=== Sending Mail ===<br />
<br />
* Server type: SMTP<br />
* Server: smtp.gmail.com<br />
* Port: 587<br />
* Server requires authentication: Checked<br />
* Use Secure Connection: TSL<br />
* Fill in Username: <username>@gmail.com<br />
* Authentication: PLAIN or Login<br />
<br />
You are now finished with configuring evolution for gmail. Just hit Send/ Receive in the main screen and wait for new mail.<br />
If it still didn't work, go to this link [http://tuxicity.wordpress.com/2007/03/08/howto-set-up-gmail-in-evolution-gnomes-mail-client-and-organizer/]<br />
<br />
== Gmail Calendar ==<br />
<br />
You can use your gmail calendar in evolution here's how:<br />
<br />
Go to your calendar in your browser. Click on manage calendars -> the click on the calendar you want to add -> In the Private URL section copy the URL of ICAL (green button).<br />
<br />
Now go to Evolution. Click on file -> new -> calendar .<br />
In the 'new calendar dialog box' select type: On The Web.<br />
You can fill in your own calendar name <br />
Then Copy the URL to the URL field <br />
<br />
Now you will see your google calendar in your calendar view in Evolution by the name you gave it in the Name field.<br />
<br />
'''Variant2 (with evolution-webcal):'''<br />
<br />
From Evolution click on -> new -> calendar .<br />
In the 'new calendar dialog box' select type: Google.<br />
You can fill in your own calendar name.<br />
Insert your username (not the email).<br />
Click the button "Get List" and choose the calendar you want to use.<br />
<br />
== Tudelft webmail (Exchange) ==<br />
<br />
This is the setup for your tudelft webmail for evolution. It might also work for other webmail based email accounts.<br />
<br />
Go to Edit -> Preferences -> Mail Accounts and make a mail account. For your Email Adress: <netid>@gmail.com . Be carefull your <netid>@student.tudelft.nl must be like this example: E.M.devries@student.tudelft.nl <br />
<br />
Receiving mail:<br />
Server type: Microsoft Exchange <br />
Username: <netid> this is just your netid like this example: edevries<br />
OWA URL: https://webmail.tudelft.nl -> now click 'Authenticate' and fill in your password. The mailbox will be filled in automaticlly<br />
<br />
Click Forward:<br />
The receiving options are already correct, you can select the option to automaticlly receive email every x minutes.<br />
<br />
Click Forward:<br />
Now just fill in the name of the mailbox and you are done.<br />
<br />
== Using Evolution Outside Of Gnome ==<br />
<br />
In order to use Evolution outside of Gnome desktop you must export [[GNOME Keyring|gnome-keyring]]:<br />
<br />
#!/bin/bash<br />
eval \`gnome-keyring-daemon\`<br />
export GNOME_KEYRING_PID<br />
export GNOME_KEYRING_SOCKET<br />
exit<br />
<br />
Run the above script before starting Evolution. Reboot or remove the appropriate files in your /tmp directory prior to running.<br />
<br />
== Troubleshooting ==<br />
<br />
If after some system upgrade one gets no accounts in Evolution then all is not lost.<br />
First, we can see if we got our account files in ~/.evolution/, if so, then the only solution is to just make a new account in Evolution with the same parameters. (I only lost the signatures<br />
<br />
=== Failing to connect to Servers ===<br />
<br />
If you change internet connections (like switch VPN) or restart X, Evolution may have problems connecting to the mail servers. You would see it endlessly trying to connect in the status bar at the bottom.<br />
<br />
A possible solution is to switch to "Work Offline" select "Don't Synchronize” in the pop-up. Then after a minute has passed, go back to On-line mode. It should now have no problem fetching from the mail servers.<br />
<br />
== References ==<br />
<br />
[http://library.gnome.org/users/evolution/stable/ Gnome Evolution Guide]<br />
<br />
[http://www.tudelft.nl/live/pagina.jsp?id=babae0a3-1479-4501-9ec4-e308153735dc&lang=nl Tudelft Evolution 2.24 Setup]</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Security&diff=272428Security2013-08-25T01:50:03Z<p>Hunterthomson: /* Kernel Hardening */ Link fix</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[ru:Security]]<br />
{{expansion|<br />
Many of these categories are just links, or lists of links. Some of the language is repetitive or unclear.}}<br />
{{Article summary start}}<br />
{{Article summary text|This article contains recommendations and best practices for hardening an Arch Linux system.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|List of Applications/Security}}<br />
{{Article summary wiki|:Category:Security}}<br />
{{Article summary end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
==Concepts==<br />
*It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
*There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user himself. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
*Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
*The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
==Kernel Hardening==<br />
The Linux Kernel is insecure by default. It allows far more access to sensitive information then is needed and only provides minimal memory exploitation protections. [https://grsecurity.net/ Grsecurity] aims to fix this. Grsecurity ships bundled with the PaX memory patches. PaX invented ALSR and provides far more protections then just that. Grsecurity hardens the file system, provides an advanced Role Based Access Control system and, and prevents information leaks which render PaX memory protections useless.<br />
<br />
Grsecurity has it's own Wiki page that can be found [https://wiki.archlinux.org/index.php/Grsecurity Grsecurity Arch Wiki]<br />
<br />
==Passwords==<br />
Passwords are key to a secure linux system. They secure your [[Users and Groups|user accounts]], [[Disk Encryption|encrypted filesystems]], and [[SSH Keys|ssh]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
It is important that your passwords cannot be easily [[Wikipedia:Password cracking|cracked]] or guessed from personal information. For this reason, do not to use a dictionary word or something like your dog's name. A password should be at least eight characters long, with a mix of upper and lower case letters. It should include at least one number and/or one special character. As expected, longer, more complex passwords are generally better.<br />
<br />
Tools like {{Pkg|pwgen}} and {{Pkg|apg}} can help you generate secure passwords.<br />
<br />
Alternately you can make a password using the first characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to “t6!WdtR5”. This approach could make it easier to remember a password. Or, if you do not mind typing you could make it “The girl is walking down the rainy street.”<br />
<br />
===Maintaining passwords===<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. Tools like {{Pkg|pass}}, {{Pkg|keepassx}}, and {{Pkg|gnome-keyring}} can help manage large numbers of complex passwords. [[Wikipedia:LastPass Password Manager|Lastpass]] is a service that stores encrypted passwords online for synchronization between devices, but requires that you trust both closed-source code and an external corporation.<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
==Physical security==<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
Physical access to a computer is basically root access, but you can stop an attacker from having access without removing your hard drive (also see [[#Disk encryption]]) or resetting your BIOS settings (both of which involve opening the computer). <br />
<br />
===Locking down BIOS===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
===Bootloaders===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
====Syslinux====<br />
<br />
[[Syslinux]] has two levels of bootloader security: a menu master password, and a per-menu-item password. In {{ic|syslinux.cfg}}, use<br />
{{bc|<br />
MENU MASTER PASSWD passwd <br />
}}<br />
to set a master bootloader password, and<br />
{{bc|<br />
MENU PASSWD passwd <br />
}}<br />
within a {{ic|LABEL}} block to password-protect individual boot items.<br />
<br />
====GRUB====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB#Security]] for details.<br />
<br />
==Partitions==<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
===Mount options===<br />
<br />
Following the principle of least privilege, partitions should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
====Relevant mount options====<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
====Potential usage====<br />
<br />
{{Note|Data partitions should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}.}}<br />
<br />
{|<br />
| align="center" style="background:#f0f0f0;"|'''Partition'''<br />
| align="center" style="background:#f0f0f0;"|{{ic|nodev}}<br />
| align="center" style="background:#f0f0f0;"|{{ic|nosuid}}<br />
| align="center" style="background:#f0f0f0;"|{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1]</sup><br />
|- style="background:#e4e4e4"<br />
| {{ic|/home}}||yes||yes||yes, if you do not code or use wine<br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|- style="background:#e4e4e4"<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{AUR|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
==Filesystem permissions==<br />
The default filesystem permissions allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the http or nobody users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Setting the UMASK]].<br />
<br />
==Disk encryption==<br />
<br />
[[Disk Encryption]], preferably full disk encryption with a [[Disk Encryption#Choosing a strong passphrase|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[TrueCrypt#Encrypting a file as a virtual_volume|TrueCrypt]], allow the user to encrypt a single file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure. [[TrueCrypt#Creating a hidden volume|Hidden volumes]] create another layer of security, introducing [[Wikipedia:TrueCrypt#Plausible deniability|plausible deniability]] for encrypted data.<br />
<br />
==User setup==<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
===Password hashes===<br />
The default Arch hash [[SHA_password_hashes|sha512]] is very strong and there is no need to change it. By default, passwords are hashed in {{ic|/etc/shadow}}, readable only by root, and only user identifiers are stored in {{ic|/etc/passwd}}, therefore, as long as the [[Security#Restricting root|root user is secured]], the file cannot be copied and cracked on an external system.<br />
<br />
=== Automatic logout ===<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}}, so you will never forget an open virtual console shell (where screensavers cannot protect you):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very usefull.<br />
<br />
===Lockout user after three failed login attempts===<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
== Restricting root ==<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
===Use sudo instead of su===<br />
Using [[sudo]] for privileged access is preferable to [[Su|su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command). For example, to give the user ''alice'' access to a particular program:<br />
<br />
{{bc|<br />
# visudo<br />
}}<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|To use {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/nano<br />
}}<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
====Editing files using sudo====<br />
Using a text editor like {{ic|vim}} as root is a security vulnerability as it allows one to execute arbitrary shell commands, and does not log the user who executed the commands. To solve this, add<br />
<br />
{{bc|<br />
EXPORT SUDO_EDITOR&#61;rvim<br />
}}<br />
to your shell's configuration file and use {{ic|sudoedit filename}} or {{ic|sudo -e filename}} to edit files. This will automatically edit {{ic|filename}} with {{ic|rvim}}, disabling shell commands from within your text editor.<br />
<br />
===Restricting root login===<br />
Once [[Sudo|sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability.<br />
<br />
====Allow only certain users====<br />
The [[Wikipedia:Pluggable authentication module|PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit {{ic|/etc/pam.d/su}} and uncomment the line:<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
====Denying console login====<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a user-name that exists on the system and that users password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
====Denying ssh login====<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny_root_login|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control | Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control | discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
===Pathname MAC===<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical | Canonical]]-developed MAC implementation designed as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
===Grsecurity RBAC===<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
*[https://wiki.archlinux.org/index.php/Grsecurity#RBAC RBAC] has a learning mode like AppArmor for easy configureation<br />
*[https://wiki.archlinux.org/index.php/Grsecurity#RBAC RBAC] dose not rely on extra meta-data like SELinux. RBAC is significantly faster then SELinux.<br />
<br />
===Labels MAC===<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA | NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
[[Wikipedia:Access control list | Access control lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
*[[grsecurity]] implements ACL access control, as well as a complete kernel patchset focused on improving security. Its changes extend to control of memory allocation, improved chroot restrictions, and rules involving specific network behavior.<br />
<br />
==Network and Firewalls==<br />
<br />
===Firewalls===<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to install {{Pkg|iptables}} from the [[Official Repositories|official repositories]], enable it, and set up some form of firewall.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
<br />
===Kernel parameters===<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
===SSH===<br />
Avoid using [[Secure Shell]] without [[SSH Keys#Disabling password logins|requiring SSH keys]]. This helps against [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]].<br />
<br />
[[Secure Shell#Deny root login|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
==Authenticating packages==<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
==See also==<br />
* ArchWiki's Current list of security applications: [https://wiki.archlinux.org/index.php/List_of_Applications/Security Lists of Applications: Security]<br />
* [http://www.puschitz.com/SecuringLinux.shtml Securing and Hardening Red Hat Linux Production Systems]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the linux desktop]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the linux server]<br />
* [http://www.faqs.org/docs/securing/index.html Securing and Optimizing Linux]<br />
* [http://www.auscert.org.au/5816 UNIX and Linux Security Checklist v3.0]<br />
* [http://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Security&diff=272427Security2013-08-25T01:49:18Z<p>Hunterthomson: /* See also */ Meh, Remove Grsecurity link it is redundant...</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[ru:Security]]<br />
{{expansion|<br />
Many of these categories are just links, or lists of links. Some of the language is repetitive or unclear.}}<br />
{{Article summary start}}<br />
{{Article summary text|This article contains recommendations and best practices for hardening an Arch Linux system.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|List of Applications/Security}}<br />
{{Article summary wiki|:Category:Security}}<br />
{{Article summary end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
==Concepts==<br />
*It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
*There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user himself. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
*Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
*The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
==Kernel Hardening==<br />
The Linux Kernel is insecure by default. It allows far more access to sensitive information then is needed and only provides minimal memory exploitation protections. The [https://grsecurity.net/ Grsecurity Patchset] aims to fix this. Grsecurity ships bundled with the PaX memory patches. PaX invented ALSR and provides far more protections then just that. Grsecurity hardens the file system, provides an advanced Role Based Access Control system and, and prevents information leaks which render PaX memory protections useless.<br />
<br />
Grsecurity has it's own Wiki page that can be found [https://wiki.archlinux.org/index.php/Grsecurity_Patchset Grsecurity Patchset Arch Wiki]<br />
<br />
==Passwords==<br />
Passwords are key to a secure linux system. They secure your [[Users and Groups|user accounts]], [[Disk Encryption|encrypted filesystems]], and [[SSH Keys|ssh]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
It is important that your passwords cannot be easily [[Wikipedia:Password cracking|cracked]] or guessed from personal information. For this reason, do not to use a dictionary word or something like your dog's name. A password should be at least eight characters long, with a mix of upper and lower case letters. It should include at least one number and/or one special character. As expected, longer, more complex passwords are generally better.<br />
<br />
Tools like {{Pkg|pwgen}} and {{Pkg|apg}} can help you generate secure passwords.<br />
<br />
Alternately you can make a password using the first characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to “t6!WdtR5”. This approach could make it easier to remember a password. Or, if you do not mind typing you could make it “The girl is walking down the rainy street.”<br />
<br />
===Maintaining passwords===<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. Tools like {{Pkg|pass}}, {{Pkg|keepassx}}, and {{Pkg|gnome-keyring}} can help manage large numbers of complex passwords. [[Wikipedia:LastPass Password Manager|Lastpass]] is a service that stores encrypted passwords online for synchronization between devices, but requires that you trust both closed-source code and an external corporation.<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
==Physical security==<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
Physical access to a computer is basically root access, but you can stop an attacker from having access without removing your hard drive (also see [[#Disk encryption]]) or resetting your BIOS settings (both of which involve opening the computer). <br />
<br />
===Locking down BIOS===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
===Bootloaders===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
====Syslinux====<br />
<br />
[[Syslinux]] has two levels of bootloader security: a menu master password, and a per-menu-item password. In {{ic|syslinux.cfg}}, use<br />
{{bc|<br />
MENU MASTER PASSWD passwd <br />
}}<br />
to set a master bootloader password, and<br />
{{bc|<br />
MENU PASSWD passwd <br />
}}<br />
within a {{ic|LABEL}} block to password-protect individual boot items.<br />
<br />
====GRUB====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB#Security]] for details.<br />
<br />
==Partitions==<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
===Mount options===<br />
<br />
Following the principle of least privilege, partitions should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
====Relevant mount options====<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
====Potential usage====<br />
<br />
{{Note|Data partitions should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}.}}<br />
<br />
{|<br />
| align="center" style="background:#f0f0f0;"|'''Partition'''<br />
| align="center" style="background:#f0f0f0;"|{{ic|nodev}}<br />
| align="center" style="background:#f0f0f0;"|{{ic|nosuid}}<br />
| align="center" style="background:#f0f0f0;"|{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1]</sup><br />
|- style="background:#e4e4e4"<br />
| {{ic|/home}}||yes||yes||yes, if you do not code or use wine<br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|- style="background:#e4e4e4"<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{AUR|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
==Filesystem permissions==<br />
The default filesystem permissions allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the http or nobody users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Setting the UMASK]].<br />
<br />
==Disk encryption==<br />
<br />
[[Disk Encryption]], preferably full disk encryption with a [[Disk Encryption#Choosing a strong passphrase|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[TrueCrypt#Encrypting a file as a virtual_volume|TrueCrypt]], allow the user to encrypt a single file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure. [[TrueCrypt#Creating a hidden volume|Hidden volumes]] create another layer of security, introducing [[Wikipedia:TrueCrypt#Plausible deniability|plausible deniability]] for encrypted data.<br />
<br />
==User setup==<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
===Password hashes===<br />
The default Arch hash [[SHA_password_hashes|sha512]] is very strong and there is no need to change it. By default, passwords are hashed in {{ic|/etc/shadow}}, readable only by root, and only user identifiers are stored in {{ic|/etc/passwd}}, therefore, as long as the [[Security#Restricting root|root user is secured]], the file cannot be copied and cracked on an external system.<br />
<br />
=== Automatic logout ===<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}}, so you will never forget an open virtual console shell (where screensavers cannot protect you):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very usefull.<br />
<br />
===Lockout user after three failed login attempts===<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
== Restricting root ==<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
===Use sudo instead of su===<br />
Using [[sudo]] for privileged access is preferable to [[Su|su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command). For example, to give the user ''alice'' access to a particular program:<br />
<br />
{{bc|<br />
# visudo<br />
}}<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|To use {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/nano<br />
}}<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
====Editing files using sudo====<br />
Using a text editor like {{ic|vim}} as root is a security vulnerability as it allows one to execute arbitrary shell commands, and does not log the user who executed the commands. To solve this, add<br />
<br />
{{bc|<br />
EXPORT SUDO_EDITOR&#61;rvim<br />
}}<br />
to your shell's configuration file and use {{ic|sudoedit filename}} or {{ic|sudo -e filename}} to edit files. This will automatically edit {{ic|filename}} with {{ic|rvim}}, disabling shell commands from within your text editor.<br />
<br />
===Restricting root login===<br />
Once [[Sudo|sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability.<br />
<br />
====Allow only certain users====<br />
The [[Wikipedia:Pluggable authentication module|PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit {{ic|/etc/pam.d/su}} and uncomment the line:<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
====Denying console login====<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a user-name that exists on the system and that users password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
====Denying ssh login====<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny_root_login|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control | Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control | discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
===Pathname MAC===<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical | Canonical]]-developed MAC implementation designed as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
===Grsecurity RBAC===<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
*[https://wiki.archlinux.org/index.php/Grsecurity#RBAC RBAC] has a learning mode like AppArmor for easy configureation<br />
*[https://wiki.archlinux.org/index.php/Grsecurity#RBAC RBAC] dose not rely on extra meta-data like SELinux. RBAC is significantly faster then SELinux.<br />
<br />
===Labels MAC===<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA | NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
[[Wikipedia:Access control list | Access control lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
*[[grsecurity]] implements ACL access control, as well as a complete kernel patchset focused on improving security. Its changes extend to control of memory allocation, improved chroot restrictions, and rules involving specific network behavior.<br />
<br />
==Network and Firewalls==<br />
<br />
===Firewalls===<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to install {{Pkg|iptables}} from the [[Official Repositories|official repositories]], enable it, and set up some form of firewall.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
<br />
===Kernel parameters===<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
===SSH===<br />
Avoid using [[Secure Shell]] without [[SSH Keys#Disabling password logins|requiring SSH keys]]. This helps against [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]].<br />
<br />
[[Secure Shell#Deny root login|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
==Authenticating packages==<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
==See also==<br />
* ArchWiki's Current list of security applications: [https://wiki.archlinux.org/index.php/List_of_Applications/Security Lists of Applications: Security]<br />
* [http://www.puschitz.com/SecuringLinux.shtml Securing and Hardening Red Hat Linux Production Systems]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the linux desktop]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the linux server]<br />
* [http://www.faqs.org/docs/securing/index.html Securing and Optimizing Linux]<br />
* [http://www.auscert.org.au/5816 UNIX and Linux Security Checklist v3.0]<br />
* [http://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Security&diff=272426Security2013-08-25T01:48:36Z<p>Hunterthomson: /* See also */ Link Fix</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[ru:Security]]<br />
{{expansion|<br />
Many of these categories are just links, or lists of links. Some of the language is repetitive or unclear.}}<br />
{{Article summary start}}<br />
{{Article summary text|This article contains recommendations and best practices for hardening an Arch Linux system.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|List of Applications/Security}}<br />
{{Article summary wiki|:Category:Security}}<br />
{{Article summary end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
==Concepts==<br />
*It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
*There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user himself. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
*Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
*The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
==Kernel Hardening==<br />
The Linux Kernel is insecure by default. It allows far more access to sensitive information then is needed and only provides minimal memory exploitation protections. The [https://grsecurity.net/ Grsecurity Patchset] aims to fix this. Grsecurity ships bundled with the PaX memory patches. PaX invented ALSR and provides far more protections then just that. Grsecurity hardens the file system, provides an advanced Role Based Access Control system and, and prevents information leaks which render PaX memory protections useless.<br />
<br />
Grsecurity has it's own Wiki page that can be found [https://wiki.archlinux.org/index.php/Grsecurity_Patchset Grsecurity Patchset Arch Wiki]<br />
<br />
==Passwords==<br />
Passwords are key to a secure linux system. They secure your [[Users and Groups|user accounts]], [[Disk Encryption|encrypted filesystems]], and [[SSH Keys|ssh]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
It is important that your passwords cannot be easily [[Wikipedia:Password cracking|cracked]] or guessed from personal information. For this reason, do not to use a dictionary word or something like your dog's name. A password should be at least eight characters long, with a mix of upper and lower case letters. It should include at least one number and/or one special character. As expected, longer, more complex passwords are generally better.<br />
<br />
Tools like {{Pkg|pwgen}} and {{Pkg|apg}} can help you generate secure passwords.<br />
<br />
Alternately you can make a password using the first characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to “t6!WdtR5”. This approach could make it easier to remember a password. Or, if you do not mind typing you could make it “The girl is walking down the rainy street.”<br />
<br />
===Maintaining passwords===<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. Tools like {{Pkg|pass}}, {{Pkg|keepassx}}, and {{Pkg|gnome-keyring}} can help manage large numbers of complex passwords. [[Wikipedia:LastPass Password Manager|Lastpass]] is a service that stores encrypted passwords online for synchronization between devices, but requires that you trust both closed-source code and an external corporation.<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
==Physical security==<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
Physical access to a computer is basically root access, but you can stop an attacker from having access without removing your hard drive (also see [[#Disk encryption]]) or resetting your BIOS settings (both of which involve opening the computer). <br />
<br />
===Locking down BIOS===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
===Bootloaders===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
====Syslinux====<br />
<br />
[[Syslinux]] has two levels of bootloader security: a menu master password, and a per-menu-item password. In {{ic|syslinux.cfg}}, use<br />
{{bc|<br />
MENU MASTER PASSWD passwd <br />
}}<br />
to set a master bootloader password, and<br />
{{bc|<br />
MENU PASSWD passwd <br />
}}<br />
within a {{ic|LABEL}} block to password-protect individual boot items.<br />
<br />
====GRUB====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB#Security]] for details.<br />
<br />
==Partitions==<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
===Mount options===<br />
<br />
Following the principle of least privilege, partitions should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
====Relevant mount options====<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
====Potential usage====<br />
<br />
{{Note|Data partitions should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}.}}<br />
<br />
{|<br />
| align="center" style="background:#f0f0f0;"|'''Partition'''<br />
| align="center" style="background:#f0f0f0;"|{{ic|nodev}}<br />
| align="center" style="background:#f0f0f0;"|{{ic|nosuid}}<br />
| align="center" style="background:#f0f0f0;"|{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1]</sup><br />
|- style="background:#e4e4e4"<br />
| {{ic|/home}}||yes||yes||yes, if you do not code or use wine<br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|- style="background:#e4e4e4"<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{AUR|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
==Filesystem permissions==<br />
The default filesystem permissions allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the http or nobody users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Setting the UMASK]].<br />
<br />
==Disk encryption==<br />
<br />
[[Disk Encryption]], preferably full disk encryption with a [[Disk Encryption#Choosing a strong passphrase|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[TrueCrypt#Encrypting a file as a virtual_volume|TrueCrypt]], allow the user to encrypt a single file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure. [[TrueCrypt#Creating a hidden volume|Hidden volumes]] create another layer of security, introducing [[Wikipedia:TrueCrypt#Plausible deniability|plausible deniability]] for encrypted data.<br />
<br />
==User setup==<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
===Password hashes===<br />
The default Arch hash [[SHA_password_hashes|sha512]] is very strong and there is no need to change it. By default, passwords are hashed in {{ic|/etc/shadow}}, readable only by root, and only user identifiers are stored in {{ic|/etc/passwd}}, therefore, as long as the [[Security#Restricting root|root user is secured]], the file cannot be copied and cracked on an external system.<br />
<br />
=== Automatic logout ===<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}}, so you will never forget an open virtual console shell (where screensavers cannot protect you):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very usefull.<br />
<br />
===Lockout user after three failed login attempts===<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
== Restricting root ==<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
===Use sudo instead of su===<br />
Using [[sudo]] for privileged access is preferable to [[Su|su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command). For example, to give the user ''alice'' access to a particular program:<br />
<br />
{{bc|<br />
# visudo<br />
}}<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|To use {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/nano<br />
}}<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
====Editing files using sudo====<br />
Using a text editor like {{ic|vim}} as root is a security vulnerability as it allows one to execute arbitrary shell commands, and does not log the user who executed the commands. To solve this, add<br />
<br />
{{bc|<br />
EXPORT SUDO_EDITOR&#61;rvim<br />
}}<br />
to your shell's configuration file and use {{ic|sudoedit filename}} or {{ic|sudo -e filename}} to edit files. This will automatically edit {{ic|filename}} with {{ic|rvim}}, disabling shell commands from within your text editor.<br />
<br />
===Restricting root login===<br />
Once [[Sudo|sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability.<br />
<br />
====Allow only certain users====<br />
The [[Wikipedia:Pluggable authentication module|PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit {{ic|/etc/pam.d/su}} and uncomment the line:<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
====Denying console login====<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a user-name that exists on the system and that users password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
====Denying ssh login====<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny_root_login|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control | Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control | discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
===Pathname MAC===<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical | Canonical]]-developed MAC implementation designed as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
===Grsecurity RBAC===<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
*[https://wiki.archlinux.org/index.php/Grsecurity#RBAC RBAC] has a learning mode like AppArmor for easy configureation<br />
*[https://wiki.archlinux.org/index.php/Grsecurity#RBAC RBAC] dose not rely on extra meta-data like SELinux. RBAC is significantly faster then SELinux.<br />
<br />
===Labels MAC===<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA | NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
[[Wikipedia:Access control list | Access control lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
*[[grsecurity]] implements ACL access control, as well as a complete kernel patchset focused on improving security. Its changes extend to control of memory allocation, improved chroot restrictions, and rules involving specific network behavior.<br />
<br />
==Network and Firewalls==<br />
<br />
===Firewalls===<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to install {{Pkg|iptables}} from the [[Official Repositories|official repositories]], enable it, and set up some form of firewall.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
<br />
===Kernel parameters===<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
===SSH===<br />
Avoid using [[Secure Shell]] without [[SSH Keys#Disabling password logins|requiring SSH keys]]. This helps against [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]].<br />
<br />
[[Secure Shell#Deny root login|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
==Authenticating packages==<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
==See also==<br />
* ArchWiki's Current list of security applications: [https://wiki.archlinux.org/index.php/List_of_Applications/Security Lists of Applications: Security]<br />
* [https://wiki.archlinux.org/index.php/Grsecurity Grsecurity]<br />
* [http://www.puschitz.com/SecuringLinux.shtml Securing and Hardening Red Hat Linux Production Systems]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the linux desktop]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the linux server]<br />
* [http://www.faqs.org/docs/securing/index.html Securing and Optimizing Linux]<br />
* [http://www.auscert.org.au/5816 UNIX and Linux Security Checklist v3.0]<br />
* [http://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Security&diff=272425Security2013-08-25T01:48:00Z<p>Hunterthomson: /* Grsecurity RBAC */ Yet another link fix</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[ru:Security]]<br />
{{expansion|<br />
Many of these categories are just links, or lists of links. Some of the language is repetitive or unclear.}}<br />
{{Article summary start}}<br />
{{Article summary text|This article contains recommendations and best practices for hardening an Arch Linux system.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|List of Applications/Security}}<br />
{{Article summary wiki|:Category:Security}}<br />
{{Article summary end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
==Concepts==<br />
*It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
*There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user himself. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
*Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
*The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
==Kernel Hardening==<br />
The Linux Kernel is insecure by default. It allows far more access to sensitive information then is needed and only provides minimal memory exploitation protections. The [https://grsecurity.net/ Grsecurity Patchset] aims to fix this. Grsecurity ships bundled with the PaX memory patches. PaX invented ALSR and provides far more protections then just that. Grsecurity hardens the file system, provides an advanced Role Based Access Control system and, and prevents information leaks which render PaX memory protections useless.<br />
<br />
Grsecurity has it's own Wiki page that can be found [https://wiki.archlinux.org/index.php/Grsecurity_Patchset Grsecurity Patchset Arch Wiki]<br />
<br />
==Passwords==<br />
Passwords are key to a secure linux system. They secure your [[Users and Groups|user accounts]], [[Disk Encryption|encrypted filesystems]], and [[SSH Keys|ssh]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
It is important that your passwords cannot be easily [[Wikipedia:Password cracking|cracked]] or guessed from personal information. For this reason, do not to use a dictionary word or something like your dog's name. A password should be at least eight characters long, with a mix of upper and lower case letters. It should include at least one number and/or one special character. As expected, longer, more complex passwords are generally better.<br />
<br />
Tools like {{Pkg|pwgen}} and {{Pkg|apg}} can help you generate secure passwords.<br />
<br />
Alternately you can make a password using the first characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to “t6!WdtR5”. This approach could make it easier to remember a password. Or, if you do not mind typing you could make it “The girl is walking down the rainy street.”<br />
<br />
===Maintaining passwords===<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. Tools like {{Pkg|pass}}, {{Pkg|keepassx}}, and {{Pkg|gnome-keyring}} can help manage large numbers of complex passwords. [[Wikipedia:LastPass Password Manager|Lastpass]] is a service that stores encrypted passwords online for synchronization between devices, but requires that you trust both closed-source code and an external corporation.<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
==Physical security==<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
Physical access to a computer is basically root access, but you can stop an attacker from having access without removing your hard drive (also see [[#Disk encryption]]) or resetting your BIOS settings (both of which involve opening the computer). <br />
<br />
===Locking down BIOS===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
===Bootloaders===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
====Syslinux====<br />
<br />
[[Syslinux]] has two levels of bootloader security: a menu master password, and a per-menu-item password. In {{ic|syslinux.cfg}}, use<br />
{{bc|<br />
MENU MASTER PASSWD passwd <br />
}}<br />
to set a master bootloader password, and<br />
{{bc|<br />
MENU PASSWD passwd <br />
}}<br />
within a {{ic|LABEL}} block to password-protect individual boot items.<br />
<br />
====GRUB====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB#Security]] for details.<br />
<br />
==Partitions==<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
===Mount options===<br />
<br />
Following the principle of least privilege, partitions should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
====Relevant mount options====<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
====Potential usage====<br />
<br />
{{Note|Data partitions should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}.}}<br />
<br />
{|<br />
| align="center" style="background:#f0f0f0;"|'''Partition'''<br />
| align="center" style="background:#f0f0f0;"|{{ic|nodev}}<br />
| align="center" style="background:#f0f0f0;"|{{ic|nosuid}}<br />
| align="center" style="background:#f0f0f0;"|{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1]</sup><br />
|- style="background:#e4e4e4"<br />
| {{ic|/home}}||yes||yes||yes, if you do not code or use wine<br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|- style="background:#e4e4e4"<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{AUR|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
==Filesystem permissions==<br />
The default filesystem permissions allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the http or nobody users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Setting the UMASK]].<br />
<br />
==Disk encryption==<br />
<br />
[[Disk Encryption]], preferably full disk encryption with a [[Disk Encryption#Choosing a strong passphrase|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[TrueCrypt#Encrypting a file as a virtual_volume|TrueCrypt]], allow the user to encrypt a single file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure. [[TrueCrypt#Creating a hidden volume|Hidden volumes]] create another layer of security, introducing [[Wikipedia:TrueCrypt#Plausible deniability|plausible deniability]] for encrypted data.<br />
<br />
==User setup==<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
===Password hashes===<br />
The default Arch hash [[SHA_password_hashes|sha512]] is very strong and there is no need to change it. By default, passwords are hashed in {{ic|/etc/shadow}}, readable only by root, and only user identifiers are stored in {{ic|/etc/passwd}}, therefore, as long as the [[Security#Restricting root|root user is secured]], the file cannot be copied and cracked on an external system.<br />
<br />
=== Automatic logout ===<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}}, so you will never forget an open virtual console shell (where screensavers cannot protect you):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very usefull.<br />
<br />
===Lockout user after three failed login attempts===<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
== Restricting root ==<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
===Use sudo instead of su===<br />
Using [[sudo]] for privileged access is preferable to [[Su|su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command). For example, to give the user ''alice'' access to a particular program:<br />
<br />
{{bc|<br />
# visudo<br />
}}<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|To use {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/nano<br />
}}<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
====Editing files using sudo====<br />
Using a text editor like {{ic|vim}} as root is a security vulnerability as it allows one to execute arbitrary shell commands, and does not log the user who executed the commands. To solve this, add<br />
<br />
{{bc|<br />
EXPORT SUDO_EDITOR&#61;rvim<br />
}}<br />
to your shell's configuration file and use {{ic|sudoedit filename}} or {{ic|sudo -e filename}} to edit files. This will automatically edit {{ic|filename}} with {{ic|rvim}}, disabling shell commands from within your text editor.<br />
<br />
===Restricting root login===<br />
Once [[Sudo|sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability.<br />
<br />
====Allow only certain users====<br />
The [[Wikipedia:Pluggable authentication module|PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit {{ic|/etc/pam.d/su}} and uncomment the line:<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
====Denying console login====<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a user-name that exists on the system and that users password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
====Denying ssh login====<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny_root_login|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control | Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control | discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
===Pathname MAC===<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical | Canonical]]-developed MAC implementation designed as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
===Grsecurity RBAC===<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
*[https://wiki.archlinux.org/index.php/Grsecurity#RBAC RBAC] has a learning mode like AppArmor for easy configureation<br />
*[https://wiki.archlinux.org/index.php/Grsecurity#RBAC RBAC] dose not rely on extra meta-data like SELinux. RBAC is significantly faster then SELinux.<br />
<br />
===Labels MAC===<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA | NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
[[Wikipedia:Access control list | Access control lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
*[[grsecurity]] implements ACL access control, as well as a complete kernel patchset focused on improving security. Its changes extend to control of memory allocation, improved chroot restrictions, and rules involving specific network behavior.<br />
<br />
==Network and Firewalls==<br />
<br />
===Firewalls===<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to install {{Pkg|iptables}} from the [[Official Repositories|official repositories]], enable it, and set up some form of firewall.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
<br />
===Kernel parameters===<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
===SSH===<br />
Avoid using [[Secure Shell]] without [[SSH Keys#Disabling password logins|requiring SSH keys]]. This helps against [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]].<br />
<br />
[[Secure Shell#Deny root login|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
==Authenticating packages==<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
==See also==<br />
* ArchWiki's Current list of security applications: [https://wiki.archlinux.org/index.php/List_of_Applications/Security Lists of Applications: Security]<br />
* [https://wiki.archlinux.org/index.php/Grsecurity_Patchset Grsecurity Patchset]<br />
* [http://www.puschitz.com/SecuringLinux.shtml Securing and Hardening Red Hat Linux Production Systems]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the linux desktop]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the linux server]<br />
* [http://www.faqs.org/docs/securing/index.html Securing and Optimizing Linux]<br />
* [http://www.auscert.org.au/5816 UNIX and Linux Security Checklist v3.0]<br />
* [http://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Security&diff=272424Security2013-08-25T01:47:18Z<p>Hunterthomson: /* Grsecurity RBAC */ compare to SELInux</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[ru:Security]]<br />
{{expansion|<br />
Many of these categories are just links, or lists of links. Some of the language is repetitive or unclear.}}<br />
{{Article summary start}}<br />
{{Article summary text|This article contains recommendations and best practices for hardening an Arch Linux system.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|List of Applications/Security}}<br />
{{Article summary wiki|:Category:Security}}<br />
{{Article summary end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
==Concepts==<br />
*It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
*There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user himself. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
*Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
*The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
==Kernel Hardening==<br />
The Linux Kernel is insecure by default. It allows far more access to sensitive information then is needed and only provides minimal memory exploitation protections. The [https://grsecurity.net/ Grsecurity Patchset] aims to fix this. Grsecurity ships bundled with the PaX memory patches. PaX invented ALSR and provides far more protections then just that. Grsecurity hardens the file system, provides an advanced Role Based Access Control system and, and prevents information leaks which render PaX memory protections useless.<br />
<br />
Grsecurity has it's own Wiki page that can be found [https://wiki.archlinux.org/index.php/Grsecurity_Patchset Grsecurity Patchset Arch Wiki]<br />
<br />
==Passwords==<br />
Passwords are key to a secure linux system. They secure your [[Users and Groups|user accounts]], [[Disk Encryption|encrypted filesystems]], and [[SSH Keys|ssh]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
It is important that your passwords cannot be easily [[Wikipedia:Password cracking|cracked]] or guessed from personal information. For this reason, do not to use a dictionary word or something like your dog's name. A password should be at least eight characters long, with a mix of upper and lower case letters. It should include at least one number and/or one special character. As expected, longer, more complex passwords are generally better.<br />
<br />
Tools like {{Pkg|pwgen}} and {{Pkg|apg}} can help you generate secure passwords.<br />
<br />
Alternately you can make a password using the first characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to “t6!WdtR5”. This approach could make it easier to remember a password. Or, if you do not mind typing you could make it “The girl is walking down the rainy street.”<br />
<br />
===Maintaining passwords===<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. Tools like {{Pkg|pass}}, {{Pkg|keepassx}}, and {{Pkg|gnome-keyring}} can help manage large numbers of complex passwords. [[Wikipedia:LastPass Password Manager|Lastpass]] is a service that stores encrypted passwords online for synchronization between devices, but requires that you trust both closed-source code and an external corporation.<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
==Physical security==<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
Physical access to a computer is basically root access, but you can stop an attacker from having access without removing your hard drive (also see [[#Disk encryption]]) or resetting your BIOS settings (both of which involve opening the computer). <br />
<br />
===Locking down BIOS===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
===Bootloaders===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
====Syslinux====<br />
<br />
[[Syslinux]] has two levels of bootloader security: a menu master password, and a per-menu-item password. In {{ic|syslinux.cfg}}, use<br />
{{bc|<br />
MENU MASTER PASSWD passwd <br />
}}<br />
to set a master bootloader password, and<br />
{{bc|<br />
MENU PASSWD passwd <br />
}}<br />
within a {{ic|LABEL}} block to password-protect individual boot items.<br />
<br />
====GRUB====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB#Security]] for details.<br />
<br />
==Partitions==<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
===Mount options===<br />
<br />
Following the principle of least privilege, partitions should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
====Relevant mount options====<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
====Potential usage====<br />
<br />
{{Note|Data partitions should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}.}}<br />
<br />
{|<br />
| align="center" style="background:#f0f0f0;"|'''Partition'''<br />
| align="center" style="background:#f0f0f0;"|{{ic|nodev}}<br />
| align="center" style="background:#f0f0f0;"|{{ic|nosuid}}<br />
| align="center" style="background:#f0f0f0;"|{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1]</sup><br />
|- style="background:#e4e4e4"<br />
| {{ic|/home}}||yes||yes||yes, if you do not code or use wine<br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|- style="background:#e4e4e4"<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{AUR|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
==Filesystem permissions==<br />
The default filesystem permissions allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the http or nobody users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Setting the UMASK]].<br />
<br />
==Disk encryption==<br />
<br />
[[Disk Encryption]], preferably full disk encryption with a [[Disk Encryption#Choosing a strong passphrase|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[TrueCrypt#Encrypting a file as a virtual_volume|TrueCrypt]], allow the user to encrypt a single file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure. [[TrueCrypt#Creating a hidden volume|Hidden volumes]] create another layer of security, introducing [[Wikipedia:TrueCrypt#Plausible deniability|plausible deniability]] for encrypted data.<br />
<br />
==User setup==<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
===Password hashes===<br />
The default Arch hash [[SHA_password_hashes|sha512]] is very strong and there is no need to change it. By default, passwords are hashed in {{ic|/etc/shadow}}, readable only by root, and only user identifiers are stored in {{ic|/etc/passwd}}, therefore, as long as the [[Security#Restricting root|root user is secured]], the file cannot be copied and cracked on an external system.<br />
<br />
=== Automatic logout ===<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}}, so you will never forget an open virtual console shell (where screensavers cannot protect you):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very usefull.<br />
<br />
===Lockout user after three failed login attempts===<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
== Restricting root ==<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
===Use sudo instead of su===<br />
Using [[sudo]] for privileged access is preferable to [[Su|su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command). For example, to give the user ''alice'' access to a particular program:<br />
<br />
{{bc|<br />
# visudo<br />
}}<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|To use {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/nano<br />
}}<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
====Editing files using sudo====<br />
Using a text editor like {{ic|vim}} as root is a security vulnerability as it allows one to execute arbitrary shell commands, and does not log the user who executed the commands. To solve this, add<br />
<br />
{{bc|<br />
EXPORT SUDO_EDITOR&#61;rvim<br />
}}<br />
to your shell's configuration file and use {{ic|sudoedit filename}} or {{ic|sudo -e filename}} to edit files. This will automatically edit {{ic|filename}} with {{ic|rvim}}, disabling shell commands from within your text editor.<br />
<br />
===Restricting root login===<br />
Once [[Sudo|sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability.<br />
<br />
====Allow only certain users====<br />
The [[Wikipedia:Pluggable authentication module|PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit {{ic|/etc/pam.d/su}} and uncomment the line:<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
====Denying console login====<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a user-name that exists on the system and that users password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
====Denying ssh login====<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny_root_login|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control | Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control | discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
===Pathname MAC===<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical | Canonical]]-developed MAC implementation designed as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
===Grsecurity RBAC===<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
*[https://wiki.archlinux.org/index.php/Grsecurity_Patchset#RBAC RBAC] has a learning mode like AppArmor for easy configureation<br />
*[https://wiki.archlinux.org/index.php/Grsecurity_Patchset#RBAC RBAC] dose not rely on extra meta-data like SELinux. RBAC is significantly faster then SELinux.<br />
<br />
===Labels MAC===<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA | NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
[[Wikipedia:Access control list | Access control lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
*[[grsecurity]] implements ACL access control, as well as a complete kernel patchset focused on improving security. Its changes extend to control of memory allocation, improved chroot restrictions, and rules involving specific network behavior.<br />
<br />
==Network and Firewalls==<br />
<br />
===Firewalls===<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to install {{Pkg|iptables}} from the [[Official Repositories|official repositories]], enable it, and set up some form of firewall.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
<br />
===Kernel parameters===<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
===SSH===<br />
Avoid using [[Secure Shell]] without [[SSH Keys#Disabling password logins|requiring SSH keys]]. This helps against [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]].<br />
<br />
[[Secure Shell#Deny root login|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
==Authenticating packages==<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
==See also==<br />
* ArchWiki's Current list of security applications: [https://wiki.archlinux.org/index.php/List_of_Applications/Security Lists of Applications: Security]<br />
* [https://wiki.archlinux.org/index.php/Grsecurity_Patchset Grsecurity Patchset]<br />
* [http://www.puschitz.com/SecuringLinux.shtml Securing and Hardening Red Hat Linux Production Systems]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the linux desktop]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the linux server]<br />
* [http://www.faqs.org/docs/securing/index.html Securing and Optimizing Linux]<br />
* [http://www.auscert.org.au/5816 UNIX and Linux Security Checklist v3.0]<br />
* [http://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Grsecurity&diff=272422Grsecurity2013-08-25T01:41:16Z<p>Hunterthomson: /* Build Options */</p>
<hr />
<div>[[Category:Kernel]][[Category:Security]]<br />
The grsecurity project, hosted on https://grsecurity.net, provides various patches to the Linux kernel which enhance your system's overall security. grsecurity also ships with PaX which provides the most advanced memory protections of any OS. PaX invented ALSR and shows that it is only the tip of the iceberg. The RBAC Mandatory Access Control system of grsecurity was the inspriation for SELinux and AppArmor.<br />
<br />
In short, a Linux kernel hardened with grsecurity is the most hardened kernel you could have. Not even OpenBSD has all the hardening features it provides. A comprehensive list is maintained on the [http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options grsecurity features page] itself. However, the grsecurity Wiki is often out-of-date. The best way is to simply read the help text in the kernel config.<br />
<br />
Arch has all the utilities and kernel packages you need to run a grsecurity hardened Arch Linux system in the AUR. Arch even has a script called [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] which will make using PaX as painless as possible by setting all of the PaX flags for you.<br />
<br />
You can install the kernel either from a binary repository or - if you want more control - manually from the AUR.<br />
<br />
= Build Options =<br />
<br />
There are three ways you can install a Grsecruity hardened kernel in Arch. The first is by adding a repository to install the binary kernel. The second option is to build it from the AUR package. The third option is to patch and build the kernel all by hand.<br />
<br />
Your best bet is probably to use the binary Grsecurity kernel repository. If you have the time, build the AUR package yourself for added security. You would really never want to build and maintain the kernel outside the package management system. That text is just their for completeness and may be removed.<br />
<br />
{{note|Any way you choose to install the Grsecurity kernel you will need to also install [https://aur.archlinux.org/packages/gradm/ gradm], [https://aur.archlinux.org/packages/paxctl/ paxctl], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags]}}<br />
<br />
= Install binary kernel packages =<br />
<br />
Add the [http://arsch.orgizm.net/ Arsch Arch Linux Repository] to your package sources and install the kernel with {{ic|pacman -Sy linux-grsec}} (or the PaX only kernel with {{ic|pacman -Sy linux-pax}}). Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
{{note|Use a startup script to set the sysctl options you want and then disable sysctl support. If you leave sysctl support enabled then an attacker who can run a command as the Root user will be able to turn off all hardening options.}}<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
= Build kernel from AUR =<br />
<br />
To build the AUR package we will follow this general game plan. First, download all needed files and check GPG signatures. Second, configure kernel and compile. Third, copy a backup of these files to the Root users home folder. Forth, install utilities needed for PaX and RBAC. Fifth, install the kernel package. Sixth, run linux-pax-flags to poke security holes in applications that will not run without them. Finally, reboot into your hardened system.<br />
<br />
== Download Files ==<br />
<br />
Download the packages<br />
[https://aur.archlinux.org/packages/linux-grsec/ linux-grsec]<br />
Or<br />
[https://aur.archlinux.org/packages/linux-grsec-lts/ linux-grsec-lts]<br />
<br />
Kernel linux-3.X.tar.xz and current patch-3.X.X.tar.xz also the .sign signature files for each.<br />
[https://www.kernel.org/pub/linux/kernel/v3.x/ kernel.org]<br />
<br />
Download the current grsecurity patch and Signatures<br />
[https://grsecurity.net/test.php grsecurity Test]<br />
Or<br />
[https://grsecurity.net/download_stable.php grsecurity Stable] for LTS kernel<br />
<br />
{{tip|The Grsecurity Test is in fact stable. The Stable Grsecurity version is just for the LTS}}<br />
<br />
=== Verify The GPG Signatures ===<br />
<br />
With the .sign files in the same directory as the file it is a a signature of, verify the signature like so...<br />
<br />
$ gpg2 --verify linux-3.10.tar.sign<br />
<br />
== Setup Build Environment ==<br />
<br />
Unpack the linux-grsec.tar.gz and copy all the files into it<br />
<br />
$ tar xzf linux-grsec.tar.gz<br />
$ cp ~/Downloads/linux-3.10.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/patch-3.10.9.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/grsecurity-2.9.1-3.10.9-201308202015.patch ~/linux-grsec<br />
<br />
Change into the build directory<br />
<br />
$ cd ~/linux-grsec<br />
<br />
== Build the Kernel Package ==<br />
<br />
It is going to take a long time to build the kernel because it is based on the default Arch kernel config with has about ten times as make modules enabled then your system actually needs. However, it is a known working config and to eliminate any more variables it is advisable to just live with the extra build time.<br />
<br />
Build the package<br />
<br />
$ MENUCONFIG=2 makepkg<br />
<br />
You should be dropped into the ncurses GUI now. Navigate to the grsecurity settings to verify the configuration and/or change things as needed. These setting can be found in {{ic|Security options ---> Grsecurity ---> Customize Configuration --->}}<br />
<br />
For both Desktops and Servers after you are sure you will not need to change any of the Grsecurity settings with sysctl, disable {{ic|Sysctl support}} found in {{ic|Sysctl Support}}.<br />
<br />
If this kernel is for a Server also enable {{ic|Disable privileged I/O}} found in {{ic|Memory Protections}}.<br />
<br />
All other setting should be optimal as they are, so now exit out of the ncurses GUI config and Save. Now the package should start to build. If all goes well you will have two .pkg.tar.xz packages one for the kernel and one for the kernel-headers.<br />
<br />
=== Make a Backup ===<br />
<br />
Keep all linux-grsec.tar.gz files along with the grsecruity patch and compiled packages in the Root users home folder. That way you can roll back if needed. Every time a new grsecurity patch is release you will not be able to download outdated patches every again.<br />
<br />
# mkdir /root/3.10.9<br />
# cp -r /home/USER/linux-grsec /root/3.10.9<br />
<br />
== Install PaX and RBAC Utilities ==<br />
<br />
The AUR has three utilities you will need to install. They are [https://aur.archlinux.org/packages/paxctl/ paxctl], [https://aur.archlinux.org/packages/gradm/ gradm], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags].<br />
<br />
For simplicities sake I will assume you are using yaourt to install package form the AUR, however any other way of installing these packages will work as well.<br />
<br />
$ yaourt -S linux-pax-flags paxctl gradm<br />
<br />
== Set PaX Flags ==<br />
<br />
Use the linux-pax-flags program to configure all the PaX flags for troublesome programs.<br />
More information can be found in the Using linux-pax-flags AUR Package section.<br />
<br />
# linux-pax-flags<br />
<br />
== Install Hardened Kernel ==<br />
<br />
Now that all the needed utilities are installed and the system is configured for PaX, install the hardened kernel and headers.<br />
<br />
# pacman -U /root/3.10.9/*.pkg.tar.xz<br />
<br />
Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
You should now be in your hardened system. Just make sure to run {{ic|linux-pax-flags}} after every time you update your system or install a new program and you should have a trouble free experience.<br />
<br />
= Build Kernel without the AUR =<br />
<br />
Throughout this document we will talk about kernel configuration using the kernel variables like CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. These are the variables that the kernel build process uses to determine if a certain feature needs to be compiled.<br />
<br />
When you configure your kernel through make menuconfig or similar, you receive a user interface through which you can select the various kernel options. If you select the Help button at a certain kernel feature you will see at the top that it lists such a kernel variable.<br />
<br />
You can therefore still configure your kernel as you like - with a bit of thinking. And if you can't find a certain option, there's always the possibility to edit /usr/src/linux/.config by hand :)<br />
<br />
Of course, to be able to select the various grsecurity kernel options, you must enable grsecurity in your kernel.<br />
See [[default grsecurity kernel configuration]]<br />
<br />
== PaX ==<br />
<br />
=== Fighting the Exploitation of Software Bugs ===<br />
<br />
PaX introduces a couple of security mechanisms that make it harder for attackers to exploit software bugs that involve memory corruption (so do not treat PaX as if it protects against all possible software bugs). The PaX introduction document talks about three possible exploit techniques:<br />
<br />
# introduce/execute arbitrary code<br />
# execute existing code out of original program order<br />
# execute existing code in original program order with arbitrary data<br />
<br />
One prevention method disallows executable code to be stored in writable memory. When we look at a process, it requires five memory regions:<br />
<br />
# a data section which contains the statically allocated and global data<br />
# a BSS region (Block Started by Symbol) which contains information about the zero-initialized data of the process<br />
# a code region, also called the text segment, which contains the executable instructions<br />
# a heap which contains the dynamically allocated memory<br />
# a stack which contains the local variables<br />
<br />
The first PaX prevention method, called NOEXEC, is meant to give control over the runtime code generation. It marks memory pages that do not contain executable code as non-executable. This means that the heap and the stack, which only contain variable data and shouldn't contain executable code, are marked as non-executable. Exploits that place code in these areas with the intention of running it will fail.<br />
<br />
NOEXEC does more than this actually, interested readers should focus their attention to the [http://pax.grsecurity.net/docs/noexec.txt PaX NOEXEC documentation].<br />
<br />
The second PaX prevention method, called ASLR (Address Space Layout Randomization), randomize the addresses given to memory requests. Where previously memory was assigned contiguously (which means exploits know where the tasks' memory regions are situated) ASLR randomizes this allocation, rendering techniques that rely on this information useless.<br />
<br />
More information about ASLR can be found [http://pax.grsecurity.net/docs/aslr.txt online].<br />
<br />
=== PaX kernel configuration ===<br />
<br />
<br />
The recommended kernel setting for PaX is:<br />
<br />
#<br />
# Security options<br />
#<br />
#<br />
# PaX<br />
#<br />
CONFIG_PAX=y<br />
#<br />
# PaX Control<br />
#<br />
# CONFIG_PAX_SOFTMODE is not set<br />
CONFIG_PAX_EI_PAX=y<br />
CONFIG_PAX_PT_PAX_FLAGS=y<br />
CONFIG_PAX_NO_ACL_FLAGS=y<br />
# CONFIG_PAX_HAVE_ACL_FLAGS is not set<br />
# CONFIG_PAX_HOOK_ACL_FLAGS is not set<br />
#<br />
# Non-executable pages<br />
#<br />
CONFIG_PAX_NOEXEC=y<br />
CONFIG_PAX_PAGEEXEC=y<br />
CONFIG_PAX_SEGMEXEC=y<br />
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set<br />
CONFIG_PAX_DEFAULT_SEGMEXEC=y<br />
CONFIG_PAX_EMUTRAMP=y<br />
CONFIG_PAX_MPROTECT=y<br />
# CONFIG_PAX_NOELFRELOCS is not set<br />
#<br />
# Address Space Layout Randomization<br />
#<br />
CONFIG_PAX_ASLR=y<br />
CONFIG_PAX_RANDKSTACK=y<br />
CONFIG_PAX_RANDUSTACK=y<br />
CONFIG_PAX_RANDMMAP=y<br />
#<br />
# Miscellaneous hardening features<br />
#<br />
CONFIG_PAX_MEMORY_SANITIZE=y<br />
CONFIG_PAX_MEMORY_UDEREF=y<br />
CONFIG_KEYS=y<br />
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_NETWORK_XFRM=y<br />
CONFIG_SECURITY_CAPABILITIES=m<br />
CONFIG_SECURITY_ROOTPLUG=m<br />
<br />
If you are running a non-x86 system you will observe that there is no CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC instead as it is the only non-exec implementation around.<br />
<br />
=== Controlling PaX ===<br />
<br />
Not all Linux applications are happy with the PaX security restrictions. These tools include xorg-x11, java, mplayer, xmms and others. If you plan on using them you can elevate the protections for these applications using chpax and paxctl. You can find they on AUR.<br />
<br />
You can also use pax-utils, which is a small toolbox which contains useful applications to administrate a PaX aware server. Find it on AUR.<br />
<br />
Interesting tools include scanelf and pspax:<br />
<br />
* With scanelf you can scan over library and binary directories and list the various permissions and ELF types that pertain to running an ideal pax/grsec setup<br />
* With pspax you can display PaX flags/capabilities/xattr from the kernel's perspective<br />
<br />
=== Verifying the PaX Settings ===<br />
<br />
Peter Busser has written a regression test suite called paxtest. This tool will check various cases of possible attack vectors and inform you of the result. When you run it, it will leave a logfile called paxtest.log in the current working directory.<br />
<br />
# paxtest<br />
Executable anonymous mapping : Killed<br />
Executable bss : Killed<br />
Executable data : Killed<br />
Executable heap : Killed<br />
Executable stack : Killed<br />
Executable anonymous mapping (mprotect) : Killed<br />
Executable bss (mprotect) : Killed<br />
Executable data (mprotect) : Killed<br />
Executable heap (mprotect) : Killed<br />
Executable stack (mprotect) : Killed<br />
Executable shared library bss (mprotect) : Killed<br />
Executable shared library data (mprotect): Killed<br />
Writable text segments : Killed<br />
Anonymous mapping randomisation test : 16 bits (guessed)<br />
Heap randomisation test (ET_EXEC) : 13 bits (guessed)<br />
Heap randomisation test (ET_DYN) : 25 bits (guessed)<br />
Main executable randomisation (ET_EXEC) : 16 bits (guessed)<br />
Main executable randomisation (ET_DYN) : 17 bits (guessed)<br />
Shared library randomisation test : 16 bits (guessed)<br />
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)<br />
Stack randomisation test (PAGEEXEC) : No randomisation<br />
Return to function (strcpy) : Vulnerable<br />
Return to function (memcpy) : Vulnerable<br />
Return to function (strcpy, RANDEXEC) : Killed<br />
Return to function (memcpy, RANDEXEC) : Killed<br />
Executable shared library bss : Killed<br />
Executable shared library data : Killed<br />
<br />
In the above example run you notice that:<br />
<br />
* strcpy and memcpy are listed as Vulnerable. This is expected and normal - it is simply showing the need for a technology such as ProPolice/SSP<br />
* there is no randomization for PAGEEXEC. This is normal since our recommended x86 kernel configuration didn't activate the PAGEEXEC setting. However, on arches that support a true NX (non-executable) bit (most of them do, including x86_64), PAGEEXEC is the only method available for NOEXEC and has no performance hit.<br />
<br />
== Filesystem Protection ==<br />
<br />
=== Fighting Chroot and Filesystem Abuse ===<br />
<br />
Grsecurity2 includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on /proc usage, chrooting, linking, etc.<br />
<br />
=== Kernel Configuration ===<br />
<br />
We recommend the following grsecurity kernel configuration for filesystem protection:<br />
<br />
#<br />
# Filesystem Protections<br />
#<br />
CONFIG_GRKERNSEC_PROC=y<br />
# CONFIG_GRKERNSEC_PROC_USER is not set<br />
CONFIG_GRKERNSEC_PROC_USERGROUP=y<br />
CONFIG_GRKERNSEC_PROC_GID=3<br />
CONFIG_GRKERNSEC_PROC_ADD=y<br />
CONFIG_GRKERNSEC_LINK=y<br />
CONFIG_GRKERNSEC_FIFO=y<br />
CONFIG_GRKERNSEC_CHROOT=y<br />
CONFIG_GRKERNSEC_CHROOT_MOUNT=y<br />
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y<br />
CONFIG_GRKERNSEC_CHROOT_PIVOT=y<br />
CONFIG_GRKERNSEC_CHROOT_CHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_CHMOD=y<br />
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_MKNOD=y<br />
CONFIG_GRKERNSEC_CHROOT_SHMAT=y<br />
CONFIG_GRKERNSEC_CHROOT_UNIX=y<br />
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y<br />
CONFIG_GRKERNSEC_CHROOT_NICE=y<br />
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y<br />
CONFIG_GRKERNSEC_CHROOT_CAPS=y<br />
<br />
=== Triggering the Security Mechanism ===<br />
<br />
When you're using a kernel compiled with the above (or similar) settings, you will get the option to enable/disable many of the options through the /proc filesystem or via sysctl.<br />
<br />
The example below shows an excerpt of a typical /etc/sysctl.conf:<br />
<br />
kernel.grsecurity.chroot_deny_sysctl = 1<br />
kernel.grsecurity.chroot_caps = 1<br />
kernel.grsecurity.chroot_execlog = 0<br />
kernel.grsecurity.chroot_restrict_nice = 1<br />
kernel.grsecurity.chroot_deny_mknod = 1<br />
kernel.grsecurity.chroot_deny_chmod = 1<br />
kernel.grsecurity.chroot_enforce_chdir = 1<br />
kernel.grsecurity.chroot_deny_pivot = 1<br />
kernel.grsecurity.chroot_deny_chroot = 1<br />
kernel.grsecurity.chroot_deny_fchdir = 1<br />
kernel.grsecurity.chroot_deny_mount = 1<br />
kernel.grsecurity.chroot_deny_unix = 1<br />
kernel.grsecurity.chroot_deny_shmat = 1<br />
<br />
You can enable or disable settings at will using the sysctl command:<br />
<br />
(Toggling the exec_logging feature ON)<br />
# sysctl -w kernel.grsecurity.exec_logging = 1<br />
(Toggling the exec_logging feature OFF)<br />
# sysctl -w kernel.grsecurity.exec_logging = 0<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
== Kernel Auditing ==<br />
<br />
=== Extend your System's Logging Facilities ===<br />
<br />
grsecurity adds extra functionality to the kernel pertaining the logging. With grsecurity's Kernel Auditing the kernel informs you when applications are started, devices (un)mounted, etc.<br />
<br />
=== The various Kernel Audit Settings ===<br />
<br />
The following kernel configuration section can be used to enable grsecurity's Kernel Audit Settings:<br />
<br />
#<br />
# Kernel Auditing<br />
#<br />
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set<br />
CONFIG_GRKERNSEC_EXECLOG=y<br />
CONFIG_GRKERNSEC_RESLOG=y<br />
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y<br />
CONFIG_GRKERNSEC_AUDIT_CHDIR=y<br />
CONFIG_GRKERNSEC_AUDIT_MOUNT=y<br />
CONFIG_GRKERNSEC_AUDIT_IPC=y<br />
CONFIG_GRKERNSEC_SIGNAL=y<br />
CONFIG_GRKERNSEC_FORKFAIL=y<br />
CONFIG_GRKERNSEC_TIME=y<br />
CONFIG_GRKERNSEC_PROC_IPADDR=y<br />
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y<br />
<br />
== Process Restrictions ==<br />
<br />
=== Executable Protection ===<br />
<br />
With grsecurity you can restrict executables. Since most exploits work through one or more running processes this protection can save your system's health.<br />
<br />
=== Network Protection ===<br />
<br />
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity includes randomization patches to counter these attacks. Apart from these you can also enable socket restrictions, disallowing certain groups network access alltogether.<br />
<br />
=== Kernel Settings ===<br />
<br />
The following kernel settings enable various executable and network protections:<br />
<br />
#<br />
# Executable Protections<br />
#<br />
CONFIG_GRKERNSEC_EXECVE=y<br />
CONFIG_GRKERNSEC_DMESG=y<br />
CONFIG_GRKERNSEC_RANDPID=y<br />
CONFIG_GRKERNSEC_TPE=y<br />
CONFIG_GRKERNSEC_TPE_ALL=y<br />
CONFIG_GRKERNSEC_TPE_GID=100<br />
<br />
#<br />
# Network Protections<br />
#<br />
CONFIG_GRKERNSEC_RANDNET=y<br />
CONFIG_GRKERNSEC_RANDISN=y<br />
CONFIG_GRKERNSEC_RANDID=y<br />
CONFIG_GRKERNSEC_RANDSRC=y<br />
CONFIG_GRKERNSEC_RANDRPC=y<br />
# CONFIG_GRKERNSEC_SOCKET is not set<br />
<br />
= RBAC =<br />
<br />
Role Based Access Control<br />
<br />
There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.<br />
<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
== Configuring the Kernel ==<br />
<br />
The recommended kernel setting for RBAC is:<br />
<br />
#<br />
# Role Based Access Control Options<br />
#<br />
CONFIG_GRKERNSEC_ACL_HIDEKERN=y<br />
CONFIG_GRKERNSEC_ACL_MAXTRIES=3<br />
CONFIG_GRKERNSEC_ACL_TIMEOUT=30<br />
<br />
== Working with gradm ==<br />
<br />
gradm is a tool which allows you to administer and maintain a policy for your system. With it, you can enable or disable the RBAC system, reload the RBAC roles, change your role, set a password for admin mode, etc.<br />
<br />
When you install gradm a default policy will be installed in /etc/grsec/policy. Please see in AUR for gradm package.<br />
<br />
By default, the RBAC policies are not activated. It is the sysadmin's job to determine when the system should have an RBAC policy enforced. Before activating the RBAC system you should set an admin password.<br />
<br />
# gradm -P admin<br />
Setting up grsecurity RBAC password<br />
Password: (Enter a well-chosen password)<br />
Re-enter Password: (Enter the same password for confirmation)<br />
Password written in /etc/grsec/pw<br />
# gradm -E<br />
<br />
To disable the RBAC system, run gradm -D. If you are not allowed to, you first need to switch to the admin role:<br />
<br />
# gradm -a admin<br />
Password: (Enter your admin role password)<br />
# gradm -D<br />
<br />
If you want to leave the admin role, run gradm -u admin:<br />
<br />
# gradm -u admin<br />
<br />
== Generating a Policy ==<br />
<br />
The RBAC system comes with a great feature called "learning mode". The learning mode can generate an anticipatory least privilege policy for your system. This allows for time and money savings by being able to rapidly deploy multiple secure servers.<br />
<br />
To use the learning mode, activate it using gradm:<br />
<br />
# gradm -F -L /etc/grsec/learning.log<br />
<br />
Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate or any other heavy file i/o operation as this can really slow down the processing time.<br />
<br />
When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under {{ic|/etc/grsec/learning.roles}}:<br />
<br />
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles<br />
<br />
Audit the {{ic|/etc/grsec/learning.roles}} and save it as {{ic|/etc/grsec/policy}} (mode {{ic|0600}}) when you are finished.<br />
<br />
# mv /etc/grsec/learning.roles /etc/grsec/policy<br />
# chmod 0600 /etc/grsec/policy<br />
<br />
You will now be able to enable the RBAC system with your new learned policy.<br />
<br />
== Tweaking your Policy ==<br />
<br />
An interesting feature of grsecurity 2.x is Set Operation Support for the configuration file. Currently it supports unions, intersections and differences of sets (of objects in this case).<br />
<br />
define objset1 {<br />
/root/blah rw<br />
/root/blah2 r<br />
/root/blah3 x<br />
}<br />
<br />
define somename2 {<br />
/root/test1 rw<br />
/root/blah2 rw<br />
/root/test3 h<br />
}<br />
<br />
Here is an example of its use, and the resulting objects that will be added to your subject:<br />
<br />
subject /somebinary o<br />
$objset1 & $somename2<br />
<br />
The above would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah2 r<br />
<br />
This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.<br />
<br />
subject /somebinary o<br />
$objset1 | $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 rw<br />
/root/blah3 x<br />
/root/test1 rw<br />
/root/test3 h<br />
<br />
This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.<br />
<br />
subject /somebinary o<br />
$objset1 - $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 h<br />
/root/blah3 x<br />
<br />
This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.<br />
<br />
In some obscure pseudo-language you could see this as:<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained /tmp/blah r) )<br />
then<br />
$objset1 - $objset2 would contain /tmp/blah w<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained / rwx) )<br />
then <br />
$objset1 - $objset2 would contain /tmp/blah h<br />
<br />
As for order of precedence (from highest to lowest): "-, & |".<br />
<br />
If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:<br />
<br />
(($set1 - $set2) | $set3) & $set4<br />
<br />
= Using linux-pax-flags AUR Package =<br />
<br />
The linux-pax-flags program is what makes using PaX on Arch Linux easy as pie. When you run this program it will set the PaX flags for all the problematic programs for you. However, if you use some uncommon program it may have problems forcing you to set the paxctl flags yourself. You will most likely see something like {{ic|Denied RWX}} in journalctl. That means you will need to disable MPROTECT for the program {{ic|paxctl -cPEmRXS /usr/bin/bla}}<br />
<br />
After you find what PaX flags need to be set post a comment on the linux-pax-flags AUR package so it can be added.<br />
<br />
More extensive documentation of the linux-pax-flags utility is to be found on it's man page.<br />
<br />
= Tips and Tricks =<br />
<br />
Because you will not be able to change the PaX flags for a running program, and that the vast majority of programs which would need them are graphical, it is strongly advisable to not use a Graphical Login like GDM or KDM. Instead simply have the system drop you to a console to log in and use {{ic|startx}}. Then you will have a chance to set the PaX flags before anything starts. For the same reasons it is strongly advisable to update your system and run {{ic|linux-pax-flags}} right after boot, before running {{ic|startx}}.<br />
<br />
Grsecurity will harden /proc and /sys so your normal user will no longer be able to see the network status, becuase of this non of your desktop network monitors will work. Instead just install terminal based monitoring programs, such as [https://www.archlinux.org/packages/community/x86_64/nmon/ nmon] or [https://www.archlinux.org/packages/community/x86_64/nload/ nload] and run them as root, or as a user in the proc-trusted group.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Grsecurity&diff=272420Grsecurity2013-08-25T01:40:13Z<p>Hunterthomson: /* Install binary kernel packages */ Added note and instructions to disable sysctl suport</p>
<hr />
<div>[[Category:Kernel]][[Category:Security]]<br />
The grsecurity project, hosted on https://grsecurity.net, provides various patches to the Linux kernel which enhance your system's overall security. grsecurity also ships with PaX which provides the most advanced memory protections of any OS. PaX invented ALSR and shows that it is only the tip of the iceberg. The RBAC Mandatory Access Control system of grsecurity was the inspriation for SELinux and AppArmor.<br />
<br />
In short, a Linux kernel hardened with grsecurity is the most hardened kernel you could have. Not even OpenBSD has all the hardening features it provides. A comprehensive list is maintained on the [http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options grsecurity features page] itself. However, the grsecurity Wiki is often out-of-date. The best way is to simply read the help text in the kernel config.<br />
<br />
Arch has all the utilities and kernel packages you need to run a grsecurity hardened Arch Linux system in the AUR. Arch even has a script called [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] which will make using PaX as painless as possible by setting all of the PaX flags for you.<br />
<br />
You can install the kernel either from a binary repository or - if you want more control - manually from the AUR.<br />
<br />
= Build Options =<br />
<br />
There are three ways you can install a Grsecruity hardened kernel in Arch. The first is by adding a repository to install the binary kernel. The second option is to build it from the AUR package. The third option is to patch and build the kernel all by hand.<br />
<br />
Your best bet is probably to first use the binary Grsecurity kernel repository. If you have the time, build the AUR package yourself for added security. You would really never want to build and maintain the kernel outside the package management system. That text is just their for completeness and may be removed.<br />
<br />
{{note|Any way you choose to install the Grsecurity kernel you will need to also install [https://aur.archlinux.org/packages/gradm/ gradm], [https://aur.archlinux.org/packages/paxctl/ paxctl], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags]}}<br />
<br />
= Install binary kernel packages =<br />
<br />
Add the [http://arsch.orgizm.net/ Arsch Arch Linux Repository] to your package sources and install the kernel with {{ic|pacman -Sy linux-grsec}} (or the PaX only kernel with {{ic|pacman -Sy linux-pax}}). Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
{{note|Use a startup script to set the sysctl options you want and then disable sysctl support. If you leave sysctl support enabled then an attacker who can run a command as the Root user will be able to turn off all hardening options.}}<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
= Build kernel from AUR =<br />
<br />
To build the AUR package we will follow this general game plan. First, download all needed files and check GPG signatures. Second, configure kernel and compile. Third, copy a backup of these files to the Root users home folder. Forth, install utilities needed for PaX and RBAC. Fifth, install the kernel package. Sixth, run linux-pax-flags to poke security holes in applications that will not run without them. Finally, reboot into your hardened system.<br />
<br />
== Download Files ==<br />
<br />
Download the packages<br />
[https://aur.archlinux.org/packages/linux-grsec/ linux-grsec]<br />
Or<br />
[https://aur.archlinux.org/packages/linux-grsec-lts/ linux-grsec-lts]<br />
<br />
Kernel linux-3.X.tar.xz and current patch-3.X.X.tar.xz also the .sign signature files for each.<br />
[https://www.kernel.org/pub/linux/kernel/v3.x/ kernel.org]<br />
<br />
Download the current grsecurity patch and Signatures<br />
[https://grsecurity.net/test.php grsecurity Test]<br />
Or<br />
[https://grsecurity.net/download_stable.php grsecurity Stable] for LTS kernel<br />
<br />
{{tip|The Grsecurity Test is in fact stable. The Stable Grsecurity version is just for the LTS}}<br />
<br />
=== Verify The GPG Signatures ===<br />
<br />
With the .sign files in the same directory as the file it is a a signature of, verify the signature like so...<br />
<br />
$ gpg2 --verify linux-3.10.tar.sign<br />
<br />
== Setup Build Environment ==<br />
<br />
Unpack the linux-grsec.tar.gz and copy all the files into it<br />
<br />
$ tar xzf linux-grsec.tar.gz<br />
$ cp ~/Downloads/linux-3.10.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/patch-3.10.9.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/grsecurity-2.9.1-3.10.9-201308202015.patch ~/linux-grsec<br />
<br />
Change into the build directory<br />
<br />
$ cd ~/linux-grsec<br />
<br />
== Build the Kernel Package ==<br />
<br />
It is going to take a long time to build the kernel because it is based on the default Arch kernel config with has about ten times as make modules enabled then your system actually needs. However, it is a known working config and to eliminate any more variables it is advisable to just live with the extra build time.<br />
<br />
Build the package<br />
<br />
$ MENUCONFIG=2 makepkg<br />
<br />
You should be dropped into the ncurses GUI now. Navigate to the grsecurity settings to verify the configuration and/or change things as needed. These setting can be found in {{ic|Security options ---> Grsecurity ---> Customize Configuration --->}}<br />
<br />
For both Desktops and Servers after you are sure you will not need to change any of the Grsecurity settings with sysctl, disable {{ic|Sysctl support}} found in {{ic|Sysctl Support}}.<br />
<br />
If this kernel is for a Server also enable {{ic|Disable privileged I/O}} found in {{ic|Memory Protections}}.<br />
<br />
All other setting should be optimal as they are, so now exit out of the ncurses GUI config and Save. Now the package should start to build. If all goes well you will have two .pkg.tar.xz packages one for the kernel and one for the kernel-headers.<br />
<br />
=== Make a Backup ===<br />
<br />
Keep all linux-grsec.tar.gz files along with the grsecruity patch and compiled packages in the Root users home folder. That way you can roll back if needed. Every time a new grsecurity patch is release you will not be able to download outdated patches every again.<br />
<br />
# mkdir /root/3.10.9<br />
# cp -r /home/USER/linux-grsec /root/3.10.9<br />
<br />
== Install PaX and RBAC Utilities ==<br />
<br />
The AUR has three utilities you will need to install. They are [https://aur.archlinux.org/packages/paxctl/ paxctl], [https://aur.archlinux.org/packages/gradm/ gradm], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags].<br />
<br />
For simplicities sake I will assume you are using yaourt to install package form the AUR, however any other way of installing these packages will work as well.<br />
<br />
$ yaourt -S linux-pax-flags paxctl gradm<br />
<br />
== Set PaX Flags ==<br />
<br />
Use the linux-pax-flags program to configure all the PaX flags for troublesome programs.<br />
More information can be found in the Using linux-pax-flags AUR Package section.<br />
<br />
# linux-pax-flags<br />
<br />
== Install Hardened Kernel ==<br />
<br />
Now that all the needed utilities are installed and the system is configured for PaX, install the hardened kernel and headers.<br />
<br />
# pacman -U /root/3.10.9/*.pkg.tar.xz<br />
<br />
Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
You should now be in your hardened system. Just make sure to run {{ic|linux-pax-flags}} after every time you update your system or install a new program and you should have a trouble free experience.<br />
<br />
= Build Kernel without the AUR =<br />
<br />
Throughout this document we will talk about kernel configuration using the kernel variables like CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. These are the variables that the kernel build process uses to determine if a certain feature needs to be compiled.<br />
<br />
When you configure your kernel through make menuconfig or similar, you receive a user interface through which you can select the various kernel options. If you select the Help button at a certain kernel feature you will see at the top that it lists such a kernel variable.<br />
<br />
You can therefore still configure your kernel as you like - with a bit of thinking. And if you can't find a certain option, there's always the possibility to edit /usr/src/linux/.config by hand :)<br />
<br />
Of course, to be able to select the various grsecurity kernel options, you must enable grsecurity in your kernel.<br />
See [[default grsecurity kernel configuration]]<br />
<br />
== PaX ==<br />
<br />
=== Fighting the Exploitation of Software Bugs ===<br />
<br />
PaX introduces a couple of security mechanisms that make it harder for attackers to exploit software bugs that involve memory corruption (so do not treat PaX as if it protects against all possible software bugs). The PaX introduction document talks about three possible exploit techniques:<br />
<br />
# introduce/execute arbitrary code<br />
# execute existing code out of original program order<br />
# execute existing code in original program order with arbitrary data<br />
<br />
One prevention method disallows executable code to be stored in writable memory. When we look at a process, it requires five memory regions:<br />
<br />
# a data section which contains the statically allocated and global data<br />
# a BSS region (Block Started by Symbol) which contains information about the zero-initialized data of the process<br />
# a code region, also called the text segment, which contains the executable instructions<br />
# a heap which contains the dynamically allocated memory<br />
# a stack which contains the local variables<br />
<br />
The first PaX prevention method, called NOEXEC, is meant to give control over the runtime code generation. It marks memory pages that do not contain executable code as non-executable. This means that the heap and the stack, which only contain variable data and shouldn't contain executable code, are marked as non-executable. Exploits that place code in these areas with the intention of running it will fail.<br />
<br />
NOEXEC does more than this actually, interested readers should focus their attention to the [http://pax.grsecurity.net/docs/noexec.txt PaX NOEXEC documentation].<br />
<br />
The second PaX prevention method, called ASLR (Address Space Layout Randomization), randomize the addresses given to memory requests. Where previously memory was assigned contiguously (which means exploits know where the tasks' memory regions are situated) ASLR randomizes this allocation, rendering techniques that rely on this information useless.<br />
<br />
More information about ASLR can be found [http://pax.grsecurity.net/docs/aslr.txt online].<br />
<br />
=== PaX kernel configuration ===<br />
<br />
<br />
The recommended kernel setting for PaX is:<br />
<br />
#<br />
# Security options<br />
#<br />
#<br />
# PaX<br />
#<br />
CONFIG_PAX=y<br />
#<br />
# PaX Control<br />
#<br />
# CONFIG_PAX_SOFTMODE is not set<br />
CONFIG_PAX_EI_PAX=y<br />
CONFIG_PAX_PT_PAX_FLAGS=y<br />
CONFIG_PAX_NO_ACL_FLAGS=y<br />
# CONFIG_PAX_HAVE_ACL_FLAGS is not set<br />
# CONFIG_PAX_HOOK_ACL_FLAGS is not set<br />
#<br />
# Non-executable pages<br />
#<br />
CONFIG_PAX_NOEXEC=y<br />
CONFIG_PAX_PAGEEXEC=y<br />
CONFIG_PAX_SEGMEXEC=y<br />
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set<br />
CONFIG_PAX_DEFAULT_SEGMEXEC=y<br />
CONFIG_PAX_EMUTRAMP=y<br />
CONFIG_PAX_MPROTECT=y<br />
# CONFIG_PAX_NOELFRELOCS is not set<br />
#<br />
# Address Space Layout Randomization<br />
#<br />
CONFIG_PAX_ASLR=y<br />
CONFIG_PAX_RANDKSTACK=y<br />
CONFIG_PAX_RANDUSTACK=y<br />
CONFIG_PAX_RANDMMAP=y<br />
#<br />
# Miscellaneous hardening features<br />
#<br />
CONFIG_PAX_MEMORY_SANITIZE=y<br />
CONFIG_PAX_MEMORY_UDEREF=y<br />
CONFIG_KEYS=y<br />
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_NETWORK_XFRM=y<br />
CONFIG_SECURITY_CAPABILITIES=m<br />
CONFIG_SECURITY_ROOTPLUG=m<br />
<br />
If you are running a non-x86 system you will observe that there is no CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC instead as it is the only non-exec implementation around.<br />
<br />
=== Controlling PaX ===<br />
<br />
Not all Linux applications are happy with the PaX security restrictions. These tools include xorg-x11, java, mplayer, xmms and others. If you plan on using them you can elevate the protections for these applications using chpax and paxctl. You can find they on AUR.<br />
<br />
You can also use pax-utils, which is a small toolbox which contains useful applications to administrate a PaX aware server. Find it on AUR.<br />
<br />
Interesting tools include scanelf and pspax:<br />
<br />
* With scanelf you can scan over library and binary directories and list the various permissions and ELF types that pertain to running an ideal pax/grsec setup<br />
* With pspax you can display PaX flags/capabilities/xattr from the kernel's perspective<br />
<br />
=== Verifying the PaX Settings ===<br />
<br />
Peter Busser has written a regression test suite called paxtest. This tool will check various cases of possible attack vectors and inform you of the result. When you run it, it will leave a logfile called paxtest.log in the current working directory.<br />
<br />
# paxtest<br />
Executable anonymous mapping : Killed<br />
Executable bss : Killed<br />
Executable data : Killed<br />
Executable heap : Killed<br />
Executable stack : Killed<br />
Executable anonymous mapping (mprotect) : Killed<br />
Executable bss (mprotect) : Killed<br />
Executable data (mprotect) : Killed<br />
Executable heap (mprotect) : Killed<br />
Executable stack (mprotect) : Killed<br />
Executable shared library bss (mprotect) : Killed<br />
Executable shared library data (mprotect): Killed<br />
Writable text segments : Killed<br />
Anonymous mapping randomisation test : 16 bits (guessed)<br />
Heap randomisation test (ET_EXEC) : 13 bits (guessed)<br />
Heap randomisation test (ET_DYN) : 25 bits (guessed)<br />
Main executable randomisation (ET_EXEC) : 16 bits (guessed)<br />
Main executable randomisation (ET_DYN) : 17 bits (guessed)<br />
Shared library randomisation test : 16 bits (guessed)<br />
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)<br />
Stack randomisation test (PAGEEXEC) : No randomisation<br />
Return to function (strcpy) : Vulnerable<br />
Return to function (memcpy) : Vulnerable<br />
Return to function (strcpy, RANDEXEC) : Killed<br />
Return to function (memcpy, RANDEXEC) : Killed<br />
Executable shared library bss : Killed<br />
Executable shared library data : Killed<br />
<br />
In the above example run you notice that:<br />
<br />
* strcpy and memcpy are listed as Vulnerable. This is expected and normal - it is simply showing the need for a technology such as ProPolice/SSP<br />
* there is no randomization for PAGEEXEC. This is normal since our recommended x86 kernel configuration didn't activate the PAGEEXEC setting. However, on arches that support a true NX (non-executable) bit (most of them do, including x86_64), PAGEEXEC is the only method available for NOEXEC and has no performance hit.<br />
<br />
== Filesystem Protection ==<br />
<br />
=== Fighting Chroot and Filesystem Abuse ===<br />
<br />
Grsecurity2 includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on /proc usage, chrooting, linking, etc.<br />
<br />
=== Kernel Configuration ===<br />
<br />
We recommend the following grsecurity kernel configuration for filesystem protection:<br />
<br />
#<br />
# Filesystem Protections<br />
#<br />
CONFIG_GRKERNSEC_PROC=y<br />
# CONFIG_GRKERNSEC_PROC_USER is not set<br />
CONFIG_GRKERNSEC_PROC_USERGROUP=y<br />
CONFIG_GRKERNSEC_PROC_GID=3<br />
CONFIG_GRKERNSEC_PROC_ADD=y<br />
CONFIG_GRKERNSEC_LINK=y<br />
CONFIG_GRKERNSEC_FIFO=y<br />
CONFIG_GRKERNSEC_CHROOT=y<br />
CONFIG_GRKERNSEC_CHROOT_MOUNT=y<br />
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y<br />
CONFIG_GRKERNSEC_CHROOT_PIVOT=y<br />
CONFIG_GRKERNSEC_CHROOT_CHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_CHMOD=y<br />
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_MKNOD=y<br />
CONFIG_GRKERNSEC_CHROOT_SHMAT=y<br />
CONFIG_GRKERNSEC_CHROOT_UNIX=y<br />
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y<br />
CONFIG_GRKERNSEC_CHROOT_NICE=y<br />
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y<br />
CONFIG_GRKERNSEC_CHROOT_CAPS=y<br />
<br />
=== Triggering the Security Mechanism ===<br />
<br />
When you're using a kernel compiled with the above (or similar) settings, you will get the option to enable/disable many of the options through the /proc filesystem or via sysctl.<br />
<br />
The example below shows an excerpt of a typical /etc/sysctl.conf:<br />
<br />
kernel.grsecurity.chroot_deny_sysctl = 1<br />
kernel.grsecurity.chroot_caps = 1<br />
kernel.grsecurity.chroot_execlog = 0<br />
kernel.grsecurity.chroot_restrict_nice = 1<br />
kernel.grsecurity.chroot_deny_mknod = 1<br />
kernel.grsecurity.chroot_deny_chmod = 1<br />
kernel.grsecurity.chroot_enforce_chdir = 1<br />
kernel.grsecurity.chroot_deny_pivot = 1<br />
kernel.grsecurity.chroot_deny_chroot = 1<br />
kernel.grsecurity.chroot_deny_fchdir = 1<br />
kernel.grsecurity.chroot_deny_mount = 1<br />
kernel.grsecurity.chroot_deny_unix = 1<br />
kernel.grsecurity.chroot_deny_shmat = 1<br />
<br />
You can enable or disable settings at will using the sysctl command:<br />
<br />
(Toggling the exec_logging feature ON)<br />
# sysctl -w kernel.grsecurity.exec_logging = 1<br />
(Toggling the exec_logging feature OFF)<br />
# sysctl -w kernel.grsecurity.exec_logging = 0<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
== Kernel Auditing ==<br />
<br />
=== Extend your System's Logging Facilities ===<br />
<br />
grsecurity adds extra functionality to the kernel pertaining the logging. With grsecurity's Kernel Auditing the kernel informs you when applications are started, devices (un)mounted, etc.<br />
<br />
=== The various Kernel Audit Settings ===<br />
<br />
The following kernel configuration section can be used to enable grsecurity's Kernel Audit Settings:<br />
<br />
#<br />
# Kernel Auditing<br />
#<br />
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set<br />
CONFIG_GRKERNSEC_EXECLOG=y<br />
CONFIG_GRKERNSEC_RESLOG=y<br />
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y<br />
CONFIG_GRKERNSEC_AUDIT_CHDIR=y<br />
CONFIG_GRKERNSEC_AUDIT_MOUNT=y<br />
CONFIG_GRKERNSEC_AUDIT_IPC=y<br />
CONFIG_GRKERNSEC_SIGNAL=y<br />
CONFIG_GRKERNSEC_FORKFAIL=y<br />
CONFIG_GRKERNSEC_TIME=y<br />
CONFIG_GRKERNSEC_PROC_IPADDR=y<br />
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y<br />
<br />
== Process Restrictions ==<br />
<br />
=== Executable Protection ===<br />
<br />
With grsecurity you can restrict executables. Since most exploits work through one or more running processes this protection can save your system's health.<br />
<br />
=== Network Protection ===<br />
<br />
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity includes randomization patches to counter these attacks. Apart from these you can also enable socket restrictions, disallowing certain groups network access alltogether.<br />
<br />
=== Kernel Settings ===<br />
<br />
The following kernel settings enable various executable and network protections:<br />
<br />
#<br />
# Executable Protections<br />
#<br />
CONFIG_GRKERNSEC_EXECVE=y<br />
CONFIG_GRKERNSEC_DMESG=y<br />
CONFIG_GRKERNSEC_RANDPID=y<br />
CONFIG_GRKERNSEC_TPE=y<br />
CONFIG_GRKERNSEC_TPE_ALL=y<br />
CONFIG_GRKERNSEC_TPE_GID=100<br />
<br />
#<br />
# Network Protections<br />
#<br />
CONFIG_GRKERNSEC_RANDNET=y<br />
CONFIG_GRKERNSEC_RANDISN=y<br />
CONFIG_GRKERNSEC_RANDID=y<br />
CONFIG_GRKERNSEC_RANDSRC=y<br />
CONFIG_GRKERNSEC_RANDRPC=y<br />
# CONFIG_GRKERNSEC_SOCKET is not set<br />
<br />
= RBAC =<br />
<br />
Role Based Access Control<br />
<br />
There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.<br />
<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
== Configuring the Kernel ==<br />
<br />
The recommended kernel setting for RBAC is:<br />
<br />
#<br />
# Role Based Access Control Options<br />
#<br />
CONFIG_GRKERNSEC_ACL_HIDEKERN=y<br />
CONFIG_GRKERNSEC_ACL_MAXTRIES=3<br />
CONFIG_GRKERNSEC_ACL_TIMEOUT=30<br />
<br />
== Working with gradm ==<br />
<br />
gradm is a tool which allows you to administer and maintain a policy for your system. With it, you can enable or disable the RBAC system, reload the RBAC roles, change your role, set a password for admin mode, etc.<br />
<br />
When you install gradm a default policy will be installed in /etc/grsec/policy. Please see in AUR for gradm package.<br />
<br />
By default, the RBAC policies are not activated. It is the sysadmin's job to determine when the system should have an RBAC policy enforced. Before activating the RBAC system you should set an admin password.<br />
<br />
# gradm -P admin<br />
Setting up grsecurity RBAC password<br />
Password: (Enter a well-chosen password)<br />
Re-enter Password: (Enter the same password for confirmation)<br />
Password written in /etc/grsec/pw<br />
# gradm -E<br />
<br />
To disable the RBAC system, run gradm -D. If you are not allowed to, you first need to switch to the admin role:<br />
<br />
# gradm -a admin<br />
Password: (Enter your admin role password)<br />
# gradm -D<br />
<br />
If you want to leave the admin role, run gradm -u admin:<br />
<br />
# gradm -u admin<br />
<br />
== Generating a Policy ==<br />
<br />
The RBAC system comes with a great feature called "learning mode". The learning mode can generate an anticipatory least privilege policy for your system. This allows for time and money savings by being able to rapidly deploy multiple secure servers.<br />
<br />
To use the learning mode, activate it using gradm:<br />
<br />
# gradm -F -L /etc/grsec/learning.log<br />
<br />
Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate or any other heavy file i/o operation as this can really slow down the processing time.<br />
<br />
When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under {{ic|/etc/grsec/learning.roles}}:<br />
<br />
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles<br />
<br />
Audit the {{ic|/etc/grsec/learning.roles}} and save it as {{ic|/etc/grsec/policy}} (mode {{ic|0600}}) when you are finished.<br />
<br />
# mv /etc/grsec/learning.roles /etc/grsec/policy<br />
# chmod 0600 /etc/grsec/policy<br />
<br />
You will now be able to enable the RBAC system with your new learned policy.<br />
<br />
== Tweaking your Policy ==<br />
<br />
An interesting feature of grsecurity 2.x is Set Operation Support for the configuration file. Currently it supports unions, intersections and differences of sets (of objects in this case).<br />
<br />
define objset1 {<br />
/root/blah rw<br />
/root/blah2 r<br />
/root/blah3 x<br />
}<br />
<br />
define somename2 {<br />
/root/test1 rw<br />
/root/blah2 rw<br />
/root/test3 h<br />
}<br />
<br />
Here is an example of its use, and the resulting objects that will be added to your subject:<br />
<br />
subject /somebinary o<br />
$objset1 & $somename2<br />
<br />
The above would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah2 r<br />
<br />
This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.<br />
<br />
subject /somebinary o<br />
$objset1 | $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 rw<br />
/root/blah3 x<br />
/root/test1 rw<br />
/root/test3 h<br />
<br />
This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.<br />
<br />
subject /somebinary o<br />
$objset1 - $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 h<br />
/root/blah3 x<br />
<br />
This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.<br />
<br />
In some obscure pseudo-language you could see this as:<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained /tmp/blah r) )<br />
then<br />
$objset1 - $objset2 would contain /tmp/blah w<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained / rwx) )<br />
then <br />
$objset1 - $objset2 would contain /tmp/blah h<br />
<br />
As for order of precedence (from highest to lowest): "-, & |".<br />
<br />
If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:<br />
<br />
(($set1 - $set2) | $set3) & $set4<br />
<br />
= Using linux-pax-flags AUR Package =<br />
<br />
The linux-pax-flags program is what makes using PaX on Arch Linux easy as pie. When you run this program it will set the PaX flags for all the problematic programs for you. However, if you use some uncommon program it may have problems forcing you to set the paxctl flags yourself. You will most likely see something like {{ic|Denied RWX}} in journalctl. That means you will need to disable MPROTECT for the program {{ic|paxctl -cPEmRXS /usr/bin/bla}}<br />
<br />
After you find what PaX flags need to be set post a comment on the linux-pax-flags AUR package so it can be added.<br />
<br />
More extensive documentation of the linux-pax-flags utility is to be found on it's man page.<br />
<br />
= Tips and Tricks =<br />
<br />
Because you will not be able to change the PaX flags for a running program, and that the vast majority of programs which would need them are graphical, it is strongly advisable to not use a Graphical Login like GDM or KDM. Instead simply have the system drop you to a console to log in and use {{ic|startx}}. Then you will have a chance to set the PaX flags before anything starts. For the same reasons it is strongly advisable to update your system and run {{ic|linux-pax-flags}} right after boot, before running {{ic|startx}}.<br />
<br />
Grsecurity will harden /proc and /sys so your normal user will no longer be able to see the network status, becuase of this non of your desktop network monitors will work. Instead just install terminal based monitoring programs, such as [https://www.archlinux.org/packages/community/x86_64/nmon/ nmon] or [https://www.archlinux.org/packages/community/x86_64/nload/ nload] and run them as root, or as a user in the proc-trusted group.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Grsecurity&diff=272419Grsecurity2013-08-25T01:36:01Z<p>Hunterthomson: /* Install PaX and RBAC Utilities */ wording</p>
<hr />
<div>[[Category:Kernel]][[Category:Security]]<br />
The grsecurity project, hosted on https://grsecurity.net, provides various patches to the Linux kernel which enhance your system's overall security. grsecurity also ships with PaX which provides the most advanced memory protections of any OS. PaX invented ALSR and shows that it is only the tip of the iceberg. The RBAC Mandatory Access Control system of grsecurity was the inspriation for SELinux and AppArmor.<br />
<br />
In short, a Linux kernel hardened with grsecurity is the most hardened kernel you could have. Not even OpenBSD has all the hardening features it provides. A comprehensive list is maintained on the [http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options grsecurity features page] itself. However, the grsecurity Wiki is often out-of-date. The best way is to simply read the help text in the kernel config.<br />
<br />
Arch has all the utilities and kernel packages you need to run a grsecurity hardened Arch Linux system in the AUR. Arch even has a script called [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] which will make using PaX as painless as possible by setting all of the PaX flags for you.<br />
<br />
You can install the kernel either from a binary repository or - if you want more control - manually from the AUR.<br />
<br />
= Build Options =<br />
<br />
There are three ways you can install a Grsecruity hardened kernel in Arch. The first is by adding a repository to install the binary kernel. The second option is to build it from the AUR package. The third option is to patch and build the kernel all by hand.<br />
<br />
Your best bet is probably to first use the binary Grsecurity kernel repository. If you have the time, build the AUR package yourself for added security. You would really never want to build and maintain the kernel outside the package management system. That text is just their for completeness and may be removed.<br />
<br />
{{note|Any way you choose to install the Grsecurity kernel you will need to also install [https://aur.archlinux.org/packages/gradm/ gradm], [https://aur.archlinux.org/packages/paxctl/ paxctl], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags]}}<br />
<br />
= Install binary kernel packages =<br />
<br />
Add the [http://arsch.orgizm.net/ Arsch Arch Linux Repository] to your package sources and install the kernel with {{ic|pacman -Sy linux-grsec}} (or the PaX only kernel with {{ic|pacman -Sy linux-pax}}). Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
{{note|Use a startup script to set the sysctl options you want and then disable sysctl support. If you leave sysctl support enabled then an attacker who can run a command as the Root user will be able to turn off all hardening options.}}<br />
<br />
= Build kernel from AUR =<br />
<br />
To build the AUR package we will follow this general game plan. First, download all needed files and check GPG signatures. Second, configure kernel and compile. Third, copy a backup of these files to the Root users home folder. Forth, install utilities needed for PaX and RBAC. Fifth, install the kernel package. Sixth, run linux-pax-flags to poke security holes in applications that will not run without them. Finally, reboot into your hardened system.<br />
<br />
== Download Files ==<br />
<br />
Download the packages<br />
[https://aur.archlinux.org/packages/linux-grsec/ linux-grsec]<br />
Or<br />
[https://aur.archlinux.org/packages/linux-grsec-lts/ linux-grsec-lts]<br />
<br />
Kernel linux-3.X.tar.xz and current patch-3.X.X.tar.xz also the .sign signature files for each.<br />
[https://www.kernel.org/pub/linux/kernel/v3.x/ kernel.org]<br />
<br />
Download the current grsecurity patch and Signatures<br />
[https://grsecurity.net/test.php grsecurity Test]<br />
Or<br />
[https://grsecurity.net/download_stable.php grsecurity Stable] for LTS kernel<br />
<br />
{{tip|The Grsecurity Test is in fact stable. The Stable Grsecurity version is just for the LTS}}<br />
<br />
=== Verify The GPG Signatures ===<br />
<br />
With the .sign files in the same directory as the file it is a a signature of, verify the signature like so...<br />
<br />
$ gpg2 --verify linux-3.10.tar.sign<br />
<br />
== Setup Build Environment ==<br />
<br />
Unpack the linux-grsec.tar.gz and copy all the files into it<br />
<br />
$ tar xzf linux-grsec.tar.gz<br />
$ cp ~/Downloads/linux-3.10.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/patch-3.10.9.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/grsecurity-2.9.1-3.10.9-201308202015.patch ~/linux-grsec<br />
<br />
Change into the build directory<br />
<br />
$ cd ~/linux-grsec<br />
<br />
== Build the Kernel Package ==<br />
<br />
It is going to take a long time to build the kernel because it is based on the default Arch kernel config with has about ten times as make modules enabled then your system actually needs. However, it is a known working config and to eliminate any more variables it is advisable to just live with the extra build time.<br />
<br />
Build the package<br />
<br />
$ MENUCONFIG=2 makepkg<br />
<br />
You should be dropped into the ncurses GUI now. Navigate to the grsecurity settings to verify the configuration and/or change things as needed. These setting can be found in {{ic|Security options ---> Grsecurity ---> Customize Configuration --->}}<br />
<br />
For both Desktops and Servers after you are sure you will not need to change any of the Grsecurity settings with sysctl, disable {{ic|Sysctl support}} found in {{ic|Sysctl Support}}.<br />
<br />
If this kernel is for a Server also enable {{ic|Disable privileged I/O}} found in {{ic|Memory Protections}}.<br />
<br />
All other setting should be optimal as they are, so now exit out of the ncurses GUI config and Save. Now the package should start to build. If all goes well you will have two .pkg.tar.xz packages one for the kernel and one for the kernel-headers.<br />
<br />
=== Make a Backup ===<br />
<br />
Keep all linux-grsec.tar.gz files along with the grsecruity patch and compiled packages in the Root users home folder. That way you can roll back if needed. Every time a new grsecurity patch is release you will not be able to download outdated patches every again.<br />
<br />
# mkdir /root/3.10.9<br />
# cp -r /home/USER/linux-grsec /root/3.10.9<br />
<br />
== Install PaX and RBAC Utilities ==<br />
<br />
The AUR has three utilities you will need to install. They are [https://aur.archlinux.org/packages/paxctl/ paxctl], [https://aur.archlinux.org/packages/gradm/ gradm], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags].<br />
<br />
For simplicities sake I will assume you are using yaourt to install package form the AUR, however any other way of installing these packages will work as well.<br />
<br />
$ yaourt -S linux-pax-flags paxctl gradm<br />
<br />
== Set PaX Flags ==<br />
<br />
Use the linux-pax-flags program to configure all the PaX flags for troublesome programs.<br />
More information can be found in the Using linux-pax-flags AUR Package section.<br />
<br />
# linux-pax-flags<br />
<br />
== Install Hardened Kernel ==<br />
<br />
Now that all the needed utilities are installed and the system is configured for PaX, install the hardened kernel and headers.<br />
<br />
# pacman -U /root/3.10.9/*.pkg.tar.xz<br />
<br />
Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
You should now be in your hardened system. Just make sure to run {{ic|linux-pax-flags}} after every time you update your system or install a new program and you should have a trouble free experience.<br />
<br />
= Build Kernel without the AUR =<br />
<br />
Throughout this document we will talk about kernel configuration using the kernel variables like CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. These are the variables that the kernel build process uses to determine if a certain feature needs to be compiled.<br />
<br />
When you configure your kernel through make menuconfig or similar, you receive a user interface through which you can select the various kernel options. If you select the Help button at a certain kernel feature you will see at the top that it lists such a kernel variable.<br />
<br />
You can therefore still configure your kernel as you like - with a bit of thinking. And if you can't find a certain option, there's always the possibility to edit /usr/src/linux/.config by hand :)<br />
<br />
Of course, to be able to select the various grsecurity kernel options, you must enable grsecurity in your kernel.<br />
See [[default grsecurity kernel configuration]]<br />
<br />
== PaX ==<br />
<br />
=== Fighting the Exploitation of Software Bugs ===<br />
<br />
PaX introduces a couple of security mechanisms that make it harder for attackers to exploit software bugs that involve memory corruption (so do not treat PaX as if it protects against all possible software bugs). The PaX introduction document talks about three possible exploit techniques:<br />
<br />
# introduce/execute arbitrary code<br />
# execute existing code out of original program order<br />
# execute existing code in original program order with arbitrary data<br />
<br />
One prevention method disallows executable code to be stored in writable memory. When we look at a process, it requires five memory regions:<br />
<br />
# a data section which contains the statically allocated and global data<br />
# a BSS region (Block Started by Symbol) which contains information about the zero-initialized data of the process<br />
# a code region, also called the text segment, which contains the executable instructions<br />
# a heap which contains the dynamically allocated memory<br />
# a stack which contains the local variables<br />
<br />
The first PaX prevention method, called NOEXEC, is meant to give control over the runtime code generation. It marks memory pages that do not contain executable code as non-executable. This means that the heap and the stack, which only contain variable data and shouldn't contain executable code, are marked as non-executable. Exploits that place code in these areas with the intention of running it will fail.<br />
<br />
NOEXEC does more than this actually, interested readers should focus their attention to the [http://pax.grsecurity.net/docs/noexec.txt PaX NOEXEC documentation].<br />
<br />
The second PaX prevention method, called ASLR (Address Space Layout Randomization), randomize the addresses given to memory requests. Where previously memory was assigned contiguously (which means exploits know where the tasks' memory regions are situated) ASLR randomizes this allocation, rendering techniques that rely on this information useless.<br />
<br />
More information about ASLR can be found [http://pax.grsecurity.net/docs/aslr.txt online].<br />
<br />
=== PaX kernel configuration ===<br />
<br />
<br />
The recommended kernel setting for PaX is:<br />
<br />
#<br />
# Security options<br />
#<br />
#<br />
# PaX<br />
#<br />
CONFIG_PAX=y<br />
#<br />
# PaX Control<br />
#<br />
# CONFIG_PAX_SOFTMODE is not set<br />
CONFIG_PAX_EI_PAX=y<br />
CONFIG_PAX_PT_PAX_FLAGS=y<br />
CONFIG_PAX_NO_ACL_FLAGS=y<br />
# CONFIG_PAX_HAVE_ACL_FLAGS is not set<br />
# CONFIG_PAX_HOOK_ACL_FLAGS is not set<br />
#<br />
# Non-executable pages<br />
#<br />
CONFIG_PAX_NOEXEC=y<br />
CONFIG_PAX_PAGEEXEC=y<br />
CONFIG_PAX_SEGMEXEC=y<br />
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set<br />
CONFIG_PAX_DEFAULT_SEGMEXEC=y<br />
CONFIG_PAX_EMUTRAMP=y<br />
CONFIG_PAX_MPROTECT=y<br />
# CONFIG_PAX_NOELFRELOCS is not set<br />
#<br />
# Address Space Layout Randomization<br />
#<br />
CONFIG_PAX_ASLR=y<br />
CONFIG_PAX_RANDKSTACK=y<br />
CONFIG_PAX_RANDUSTACK=y<br />
CONFIG_PAX_RANDMMAP=y<br />
#<br />
# Miscellaneous hardening features<br />
#<br />
CONFIG_PAX_MEMORY_SANITIZE=y<br />
CONFIG_PAX_MEMORY_UDEREF=y<br />
CONFIG_KEYS=y<br />
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_NETWORK_XFRM=y<br />
CONFIG_SECURITY_CAPABILITIES=m<br />
CONFIG_SECURITY_ROOTPLUG=m<br />
<br />
If you are running a non-x86 system you will observe that there is no CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC instead as it is the only non-exec implementation around.<br />
<br />
=== Controlling PaX ===<br />
<br />
Not all Linux applications are happy with the PaX security restrictions. These tools include xorg-x11, java, mplayer, xmms and others. If you plan on using them you can elevate the protections for these applications using chpax and paxctl. You can find they on AUR.<br />
<br />
You can also use pax-utils, which is a small toolbox which contains useful applications to administrate a PaX aware server. Find it on AUR.<br />
<br />
Interesting tools include scanelf and pspax:<br />
<br />
* With scanelf you can scan over library and binary directories and list the various permissions and ELF types that pertain to running an ideal pax/grsec setup<br />
* With pspax you can display PaX flags/capabilities/xattr from the kernel's perspective<br />
<br />
=== Verifying the PaX Settings ===<br />
<br />
Peter Busser has written a regression test suite called paxtest. This tool will check various cases of possible attack vectors and inform you of the result. When you run it, it will leave a logfile called paxtest.log in the current working directory.<br />
<br />
# paxtest<br />
Executable anonymous mapping : Killed<br />
Executable bss : Killed<br />
Executable data : Killed<br />
Executable heap : Killed<br />
Executable stack : Killed<br />
Executable anonymous mapping (mprotect) : Killed<br />
Executable bss (mprotect) : Killed<br />
Executable data (mprotect) : Killed<br />
Executable heap (mprotect) : Killed<br />
Executable stack (mprotect) : Killed<br />
Executable shared library bss (mprotect) : Killed<br />
Executable shared library data (mprotect): Killed<br />
Writable text segments : Killed<br />
Anonymous mapping randomisation test : 16 bits (guessed)<br />
Heap randomisation test (ET_EXEC) : 13 bits (guessed)<br />
Heap randomisation test (ET_DYN) : 25 bits (guessed)<br />
Main executable randomisation (ET_EXEC) : 16 bits (guessed)<br />
Main executable randomisation (ET_DYN) : 17 bits (guessed)<br />
Shared library randomisation test : 16 bits (guessed)<br />
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)<br />
Stack randomisation test (PAGEEXEC) : No randomisation<br />
Return to function (strcpy) : Vulnerable<br />
Return to function (memcpy) : Vulnerable<br />
Return to function (strcpy, RANDEXEC) : Killed<br />
Return to function (memcpy, RANDEXEC) : Killed<br />
Executable shared library bss : Killed<br />
Executable shared library data : Killed<br />
<br />
In the above example run you notice that:<br />
<br />
* strcpy and memcpy are listed as Vulnerable. This is expected and normal - it is simply showing the need for a technology such as ProPolice/SSP<br />
* there is no randomization for PAGEEXEC. This is normal since our recommended x86 kernel configuration didn't activate the PAGEEXEC setting. However, on arches that support a true NX (non-executable) bit (most of them do, including x86_64), PAGEEXEC is the only method available for NOEXEC and has no performance hit.<br />
<br />
== Filesystem Protection ==<br />
<br />
=== Fighting Chroot and Filesystem Abuse ===<br />
<br />
Grsecurity2 includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on /proc usage, chrooting, linking, etc.<br />
<br />
=== Kernel Configuration ===<br />
<br />
We recommend the following grsecurity kernel configuration for filesystem protection:<br />
<br />
#<br />
# Filesystem Protections<br />
#<br />
CONFIG_GRKERNSEC_PROC=y<br />
# CONFIG_GRKERNSEC_PROC_USER is not set<br />
CONFIG_GRKERNSEC_PROC_USERGROUP=y<br />
CONFIG_GRKERNSEC_PROC_GID=3<br />
CONFIG_GRKERNSEC_PROC_ADD=y<br />
CONFIG_GRKERNSEC_LINK=y<br />
CONFIG_GRKERNSEC_FIFO=y<br />
CONFIG_GRKERNSEC_CHROOT=y<br />
CONFIG_GRKERNSEC_CHROOT_MOUNT=y<br />
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y<br />
CONFIG_GRKERNSEC_CHROOT_PIVOT=y<br />
CONFIG_GRKERNSEC_CHROOT_CHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_CHMOD=y<br />
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_MKNOD=y<br />
CONFIG_GRKERNSEC_CHROOT_SHMAT=y<br />
CONFIG_GRKERNSEC_CHROOT_UNIX=y<br />
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y<br />
CONFIG_GRKERNSEC_CHROOT_NICE=y<br />
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y<br />
CONFIG_GRKERNSEC_CHROOT_CAPS=y<br />
<br />
=== Triggering the Security Mechanism ===<br />
<br />
When you're using a kernel compiled with the above (or similar) settings, you will get the option to enable/disable many of the options through the /proc filesystem or via sysctl.<br />
<br />
The example below shows an excerpt of a typical /etc/sysctl.conf:<br />
<br />
kernel.grsecurity.chroot_deny_sysctl = 1<br />
kernel.grsecurity.chroot_caps = 1<br />
kernel.grsecurity.chroot_execlog = 0<br />
kernel.grsecurity.chroot_restrict_nice = 1<br />
kernel.grsecurity.chroot_deny_mknod = 1<br />
kernel.grsecurity.chroot_deny_chmod = 1<br />
kernel.grsecurity.chroot_enforce_chdir = 1<br />
kernel.grsecurity.chroot_deny_pivot = 1<br />
kernel.grsecurity.chroot_deny_chroot = 1<br />
kernel.grsecurity.chroot_deny_fchdir = 1<br />
kernel.grsecurity.chroot_deny_mount = 1<br />
kernel.grsecurity.chroot_deny_unix = 1<br />
kernel.grsecurity.chroot_deny_shmat = 1<br />
<br />
You can enable or disable settings at will using the sysctl command:<br />
<br />
(Toggling the exec_logging feature ON)<br />
# sysctl -w kernel.grsecurity.exec_logging = 1<br />
(Toggling the exec_logging feature OFF)<br />
# sysctl -w kernel.grsecurity.exec_logging = 0<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
== Kernel Auditing ==<br />
<br />
=== Extend your System's Logging Facilities ===<br />
<br />
grsecurity adds extra functionality to the kernel pertaining the logging. With grsecurity's Kernel Auditing the kernel informs you when applications are started, devices (un)mounted, etc.<br />
<br />
=== The various Kernel Audit Settings ===<br />
<br />
The following kernel configuration section can be used to enable grsecurity's Kernel Audit Settings:<br />
<br />
#<br />
# Kernel Auditing<br />
#<br />
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set<br />
CONFIG_GRKERNSEC_EXECLOG=y<br />
CONFIG_GRKERNSEC_RESLOG=y<br />
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y<br />
CONFIG_GRKERNSEC_AUDIT_CHDIR=y<br />
CONFIG_GRKERNSEC_AUDIT_MOUNT=y<br />
CONFIG_GRKERNSEC_AUDIT_IPC=y<br />
CONFIG_GRKERNSEC_SIGNAL=y<br />
CONFIG_GRKERNSEC_FORKFAIL=y<br />
CONFIG_GRKERNSEC_TIME=y<br />
CONFIG_GRKERNSEC_PROC_IPADDR=y<br />
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y<br />
<br />
== Process Restrictions ==<br />
<br />
=== Executable Protection ===<br />
<br />
With grsecurity you can restrict executables. Since most exploits work through one or more running processes this protection can save your system's health.<br />
<br />
=== Network Protection ===<br />
<br />
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity includes randomization patches to counter these attacks. Apart from these you can also enable socket restrictions, disallowing certain groups network access alltogether.<br />
<br />
=== Kernel Settings ===<br />
<br />
The following kernel settings enable various executable and network protections:<br />
<br />
#<br />
# Executable Protections<br />
#<br />
CONFIG_GRKERNSEC_EXECVE=y<br />
CONFIG_GRKERNSEC_DMESG=y<br />
CONFIG_GRKERNSEC_RANDPID=y<br />
CONFIG_GRKERNSEC_TPE=y<br />
CONFIG_GRKERNSEC_TPE_ALL=y<br />
CONFIG_GRKERNSEC_TPE_GID=100<br />
<br />
#<br />
# Network Protections<br />
#<br />
CONFIG_GRKERNSEC_RANDNET=y<br />
CONFIG_GRKERNSEC_RANDISN=y<br />
CONFIG_GRKERNSEC_RANDID=y<br />
CONFIG_GRKERNSEC_RANDSRC=y<br />
CONFIG_GRKERNSEC_RANDRPC=y<br />
# CONFIG_GRKERNSEC_SOCKET is not set<br />
<br />
= RBAC =<br />
<br />
Role Based Access Control<br />
<br />
There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.<br />
<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
== Configuring the Kernel ==<br />
<br />
The recommended kernel setting for RBAC is:<br />
<br />
#<br />
# Role Based Access Control Options<br />
#<br />
CONFIG_GRKERNSEC_ACL_HIDEKERN=y<br />
CONFIG_GRKERNSEC_ACL_MAXTRIES=3<br />
CONFIG_GRKERNSEC_ACL_TIMEOUT=30<br />
<br />
== Working with gradm ==<br />
<br />
gradm is a tool which allows you to administer and maintain a policy for your system. With it, you can enable or disable the RBAC system, reload the RBAC roles, change your role, set a password for admin mode, etc.<br />
<br />
When you install gradm a default policy will be installed in /etc/grsec/policy. Please see in AUR for gradm package.<br />
<br />
By default, the RBAC policies are not activated. It is the sysadmin's job to determine when the system should have an RBAC policy enforced. Before activating the RBAC system you should set an admin password.<br />
<br />
# gradm -P admin<br />
Setting up grsecurity RBAC password<br />
Password: (Enter a well-chosen password)<br />
Re-enter Password: (Enter the same password for confirmation)<br />
Password written in /etc/grsec/pw<br />
# gradm -E<br />
<br />
To disable the RBAC system, run gradm -D. If you are not allowed to, you first need to switch to the admin role:<br />
<br />
# gradm -a admin<br />
Password: (Enter your admin role password)<br />
# gradm -D<br />
<br />
If you want to leave the admin role, run gradm -u admin:<br />
<br />
# gradm -u admin<br />
<br />
== Generating a Policy ==<br />
<br />
The RBAC system comes with a great feature called "learning mode". The learning mode can generate an anticipatory least privilege policy for your system. This allows for time and money savings by being able to rapidly deploy multiple secure servers.<br />
<br />
To use the learning mode, activate it using gradm:<br />
<br />
# gradm -F -L /etc/grsec/learning.log<br />
<br />
Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate or any other heavy file i/o operation as this can really slow down the processing time.<br />
<br />
When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under {{ic|/etc/grsec/learning.roles}}:<br />
<br />
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles<br />
<br />
Audit the {{ic|/etc/grsec/learning.roles}} and save it as {{ic|/etc/grsec/policy}} (mode {{ic|0600}}) when you are finished.<br />
<br />
# mv /etc/grsec/learning.roles /etc/grsec/policy<br />
# chmod 0600 /etc/grsec/policy<br />
<br />
You will now be able to enable the RBAC system with your new learned policy.<br />
<br />
== Tweaking your Policy ==<br />
<br />
An interesting feature of grsecurity 2.x is Set Operation Support for the configuration file. Currently it supports unions, intersections and differences of sets (of objects in this case).<br />
<br />
define objset1 {<br />
/root/blah rw<br />
/root/blah2 r<br />
/root/blah3 x<br />
}<br />
<br />
define somename2 {<br />
/root/test1 rw<br />
/root/blah2 rw<br />
/root/test3 h<br />
}<br />
<br />
Here is an example of its use, and the resulting objects that will be added to your subject:<br />
<br />
subject /somebinary o<br />
$objset1 & $somename2<br />
<br />
The above would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah2 r<br />
<br />
This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.<br />
<br />
subject /somebinary o<br />
$objset1 | $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 rw<br />
/root/blah3 x<br />
/root/test1 rw<br />
/root/test3 h<br />
<br />
This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.<br />
<br />
subject /somebinary o<br />
$objset1 - $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 h<br />
/root/blah3 x<br />
<br />
This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.<br />
<br />
In some obscure pseudo-language you could see this as:<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained /tmp/blah r) )<br />
then<br />
$objset1 - $objset2 would contain /tmp/blah w<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained / rwx) )<br />
then <br />
$objset1 - $objset2 would contain /tmp/blah h<br />
<br />
As for order of precedence (from highest to lowest): "-, & |".<br />
<br />
If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:<br />
<br />
(($set1 - $set2) | $set3) & $set4<br />
<br />
= Using linux-pax-flags AUR Package =<br />
<br />
The linux-pax-flags program is what makes using PaX on Arch Linux easy as pie. When you run this program it will set the PaX flags for all the problematic programs for you. However, if you use some uncommon program it may have problems forcing you to set the paxctl flags yourself. You will most likely see something like {{ic|Denied RWX}} in journalctl. That means you will need to disable MPROTECT for the program {{ic|paxctl -cPEmRXS /usr/bin/bla}}<br />
<br />
After you find what PaX flags need to be set post a comment on the linux-pax-flags AUR package so it can be added.<br />
<br />
More extensive documentation of the linux-pax-flags utility is to be found on it's man page.<br />
<br />
= Tips and Tricks =<br />
<br />
Because you will not be able to change the PaX flags for a running program, and that the vast majority of programs which would need them are graphical, it is strongly advisable to not use a Graphical Login like GDM or KDM. Instead simply have the system drop you to a console to log in and use {{ic|startx}}. Then you will have a chance to set the PaX flags before anything starts. For the same reasons it is strongly advisable to update your system and run {{ic|linux-pax-flags}} right after boot, before running {{ic|startx}}.<br />
<br />
Grsecurity will harden /proc and /sys so your normal user will no longer be able to see the network status, becuase of this non of your desktop network monitors will work. Instead just install terminal based monitoring programs, such as [https://www.archlinux.org/packages/community/x86_64/nmon/ nmon] or [https://www.archlinux.org/packages/community/x86_64/nload/ nload] and run them as root, or as a user in the proc-trusted group.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Grsecurity&diff=272418Grsecurity2013-08-25T01:34:38Z<p>Hunterthomson: Title changes</p>
<hr />
<div>[[Category:Kernel]][[Category:Security]]<br />
The grsecurity project, hosted on https://grsecurity.net, provides various patches to the Linux kernel which enhance your system's overall security. grsecurity also ships with PaX which provides the most advanced memory protections of any OS. PaX invented ALSR and shows that it is only the tip of the iceberg. The RBAC Mandatory Access Control system of grsecurity was the inspriation for SELinux and AppArmor.<br />
<br />
In short, a Linux kernel hardened with grsecurity is the most hardened kernel you could have. Not even OpenBSD has all the hardening features it provides. A comprehensive list is maintained on the [http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options grsecurity features page] itself. However, the grsecurity Wiki is often out-of-date. The best way is to simply read the help text in the kernel config.<br />
<br />
Arch has all the utilities and kernel packages you need to run a grsecurity hardened Arch Linux system in the AUR. Arch even has a script called [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] which will make using PaX as painless as possible by setting all of the PaX flags for you.<br />
<br />
You can install the kernel either from a binary repository or - if you want more control - manually from the AUR.<br />
<br />
= Build Options =<br />
<br />
There are three ways you can install a Grsecruity hardened kernel in Arch. The first is by adding a repository to install the binary kernel. The second option is to build it from the AUR package. The third option is to patch and build the kernel all by hand.<br />
<br />
Your best bet is probably to first use the binary Grsecurity kernel repository. If you have the time, build the AUR package yourself for added security. You would really never want to build and maintain the kernel outside the package management system. That text is just their for completeness and may be removed.<br />
<br />
{{note|Any way you choose to install the Grsecurity kernel you will need to also install [https://aur.archlinux.org/packages/gradm/ gradm], [https://aur.archlinux.org/packages/paxctl/ paxctl], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags]}}<br />
<br />
= Install binary kernel packages =<br />
<br />
Add the [http://arsch.orgizm.net/ Arsch Arch Linux Repository] to your package sources and install the kernel with {{ic|pacman -Sy linux-grsec}} (or the PaX only kernel with {{ic|pacman -Sy linux-pax}}). Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
{{note|Use a startup script to set the sysctl options you want and then disable sysctl support. If you leave sysctl support enabled then an attacker who can run a command as the Root user will be able to turn off all hardening options.}}<br />
<br />
= Build kernel from AUR =<br />
<br />
To build the AUR package we will follow this general game plan. First, download all needed files and check GPG signatures. Second, configure kernel and compile. Third, copy a backup of these files to the Root users home folder. Forth, install utilities needed for PaX and RBAC. Fifth, install the kernel package. Sixth, run linux-pax-flags to poke security holes in applications that will not run without them. Finally, reboot into your hardened system.<br />
<br />
== Download Files ==<br />
<br />
Download the packages<br />
[https://aur.archlinux.org/packages/linux-grsec/ linux-grsec]<br />
Or<br />
[https://aur.archlinux.org/packages/linux-grsec-lts/ linux-grsec-lts]<br />
<br />
Kernel linux-3.X.tar.xz and current patch-3.X.X.tar.xz also the .sign signature files for each.<br />
[https://www.kernel.org/pub/linux/kernel/v3.x/ kernel.org]<br />
<br />
Download the current grsecurity patch and Signatures<br />
[https://grsecurity.net/test.php grsecurity Test]<br />
Or<br />
[https://grsecurity.net/download_stable.php grsecurity Stable] for LTS kernel<br />
<br />
{{tip|The Grsecurity Test is in fact stable. The Stable Grsecurity version is just for the LTS}}<br />
<br />
=== Verify The GPG Signatures ===<br />
<br />
With the .sign files in the same directory as the file it is a a signature of, verify the signature like so...<br />
<br />
$ gpg2 --verify linux-3.10.tar.sign<br />
<br />
== Setup Build Environment ==<br />
<br />
Unpack the linux-grsec.tar.gz and copy all the files into it<br />
<br />
$ tar xzf linux-grsec.tar.gz<br />
$ cp ~/Downloads/linux-3.10.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/patch-3.10.9.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/grsecurity-2.9.1-3.10.9-201308202015.patch ~/linux-grsec<br />
<br />
Change into the build directory<br />
<br />
$ cd ~/linux-grsec<br />
<br />
== Build the Kernel Package ==<br />
<br />
It is going to take a long time to build the kernel because it is based on the default Arch kernel config with has about ten times as make modules enabled then your system actually needs. However, it is a known working config and to eliminate any more variables it is advisable to just live with the extra build time.<br />
<br />
Build the package<br />
<br />
$ MENUCONFIG=2 makepkg<br />
<br />
You should be dropped into the ncurses GUI now. Navigate to the grsecurity settings to verify the configuration and/or change things as needed. These setting can be found in {{ic|Security options ---> Grsecurity ---> Customize Configuration --->}}<br />
<br />
For both Desktops and Servers after you are sure you will not need to change any of the Grsecurity settings with sysctl, disable {{ic|Sysctl support}} found in {{ic|Sysctl Support}}.<br />
<br />
If this kernel is for a Server also enable {{ic|Disable privileged I/O}} found in {{ic|Memory Protections}}.<br />
<br />
All other setting should be optimal as they are, so now exit out of the ncurses GUI config and Save. Now the package should start to build. If all goes well you will have two .pkg.tar.xz packages one for the kernel and one for the kernel-headers.<br />
<br />
=== Make a Backup ===<br />
<br />
Keep all linux-grsec.tar.gz files along with the grsecruity patch and compiled packages in the Root users home folder. That way you can roll back if needed. Every time a new grsecurity patch is release you will not be able to download outdated patches every again.<br />
<br />
# mkdir /root/3.10.9<br />
# cp -r /home/USER/linux-grsec /root/3.10.9<br />
<br />
== Install PaX and RBAC Utilities ==<br />
<br />
The AUR also has [https://aur.archlinux.org/packages/paxctl/ paxctl], [https://aur.archlinux.org/packages/gradm/ gradm], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] packages that you will need.<br />
<br />
For simplicities sake I will assume you are using yaourt to install package form the AUR, however any other way of installing these packages will work as well.<br />
<br />
$ yaourt -S linux-pax-flags paxctl gradm<br />
<br />
== Set PaX Flags ==<br />
<br />
Use the linux-pax-flags program to configure all the PaX flags for troublesome programs.<br />
More information can be found in the Using linux-pax-flags AUR Package section.<br />
<br />
# linux-pax-flags<br />
<br />
== Install Hardened Kernel ==<br />
<br />
Now that all the needed utilities are installed and the system is configured for PaX, install the hardened kernel and headers.<br />
<br />
# pacman -U /root/3.10.9/*.pkg.tar.xz<br />
<br />
Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
You should now be in your hardened system. Just make sure to run {{ic|linux-pax-flags}} after every time you update your system or install a new program and you should have a trouble free experience.<br />
<br />
= Build Kernel without the AUR =<br />
<br />
Throughout this document we will talk about kernel configuration using the kernel variables like CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. These are the variables that the kernel build process uses to determine if a certain feature needs to be compiled.<br />
<br />
When you configure your kernel through make menuconfig or similar, you receive a user interface through which you can select the various kernel options. If you select the Help button at a certain kernel feature you will see at the top that it lists such a kernel variable.<br />
<br />
You can therefore still configure your kernel as you like - with a bit of thinking. And if you can't find a certain option, there's always the possibility to edit /usr/src/linux/.config by hand :)<br />
<br />
Of course, to be able to select the various grsecurity kernel options, you must enable grsecurity in your kernel.<br />
See [[default grsecurity kernel configuration]]<br />
<br />
== PaX ==<br />
<br />
=== Fighting the Exploitation of Software Bugs ===<br />
<br />
PaX introduces a couple of security mechanisms that make it harder for attackers to exploit software bugs that involve memory corruption (so do not treat PaX as if it protects against all possible software bugs). The PaX introduction document talks about three possible exploit techniques:<br />
<br />
# introduce/execute arbitrary code<br />
# execute existing code out of original program order<br />
# execute existing code in original program order with arbitrary data<br />
<br />
One prevention method disallows executable code to be stored in writable memory. When we look at a process, it requires five memory regions:<br />
<br />
# a data section which contains the statically allocated and global data<br />
# a BSS region (Block Started by Symbol) which contains information about the zero-initialized data of the process<br />
# a code region, also called the text segment, which contains the executable instructions<br />
# a heap which contains the dynamically allocated memory<br />
# a stack which contains the local variables<br />
<br />
The first PaX prevention method, called NOEXEC, is meant to give control over the runtime code generation. It marks memory pages that do not contain executable code as non-executable. This means that the heap and the stack, which only contain variable data and shouldn't contain executable code, are marked as non-executable. Exploits that place code in these areas with the intention of running it will fail.<br />
<br />
NOEXEC does more than this actually, interested readers should focus their attention to the [http://pax.grsecurity.net/docs/noexec.txt PaX NOEXEC documentation].<br />
<br />
The second PaX prevention method, called ASLR (Address Space Layout Randomization), randomize the addresses given to memory requests. Where previously memory was assigned contiguously (which means exploits know where the tasks' memory regions are situated) ASLR randomizes this allocation, rendering techniques that rely on this information useless.<br />
<br />
More information about ASLR can be found [http://pax.grsecurity.net/docs/aslr.txt online].<br />
<br />
=== PaX kernel configuration ===<br />
<br />
<br />
The recommended kernel setting for PaX is:<br />
<br />
#<br />
# Security options<br />
#<br />
#<br />
# PaX<br />
#<br />
CONFIG_PAX=y<br />
#<br />
# PaX Control<br />
#<br />
# CONFIG_PAX_SOFTMODE is not set<br />
CONFIG_PAX_EI_PAX=y<br />
CONFIG_PAX_PT_PAX_FLAGS=y<br />
CONFIG_PAX_NO_ACL_FLAGS=y<br />
# CONFIG_PAX_HAVE_ACL_FLAGS is not set<br />
# CONFIG_PAX_HOOK_ACL_FLAGS is not set<br />
#<br />
# Non-executable pages<br />
#<br />
CONFIG_PAX_NOEXEC=y<br />
CONFIG_PAX_PAGEEXEC=y<br />
CONFIG_PAX_SEGMEXEC=y<br />
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set<br />
CONFIG_PAX_DEFAULT_SEGMEXEC=y<br />
CONFIG_PAX_EMUTRAMP=y<br />
CONFIG_PAX_MPROTECT=y<br />
# CONFIG_PAX_NOELFRELOCS is not set<br />
#<br />
# Address Space Layout Randomization<br />
#<br />
CONFIG_PAX_ASLR=y<br />
CONFIG_PAX_RANDKSTACK=y<br />
CONFIG_PAX_RANDUSTACK=y<br />
CONFIG_PAX_RANDMMAP=y<br />
#<br />
# Miscellaneous hardening features<br />
#<br />
CONFIG_PAX_MEMORY_SANITIZE=y<br />
CONFIG_PAX_MEMORY_UDEREF=y<br />
CONFIG_KEYS=y<br />
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_NETWORK_XFRM=y<br />
CONFIG_SECURITY_CAPABILITIES=m<br />
CONFIG_SECURITY_ROOTPLUG=m<br />
<br />
If you are running a non-x86 system you will observe that there is no CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC instead as it is the only non-exec implementation around.<br />
<br />
=== Controlling PaX ===<br />
<br />
Not all Linux applications are happy with the PaX security restrictions. These tools include xorg-x11, java, mplayer, xmms and others. If you plan on using them you can elevate the protections for these applications using chpax and paxctl. You can find they on AUR.<br />
<br />
You can also use pax-utils, which is a small toolbox which contains useful applications to administrate a PaX aware server. Find it on AUR.<br />
<br />
Interesting tools include scanelf and pspax:<br />
<br />
* With scanelf you can scan over library and binary directories and list the various permissions and ELF types that pertain to running an ideal pax/grsec setup<br />
* With pspax you can display PaX flags/capabilities/xattr from the kernel's perspective<br />
<br />
=== Verifying the PaX Settings ===<br />
<br />
Peter Busser has written a regression test suite called paxtest. This tool will check various cases of possible attack vectors and inform you of the result. When you run it, it will leave a logfile called paxtest.log in the current working directory.<br />
<br />
# paxtest<br />
Executable anonymous mapping : Killed<br />
Executable bss : Killed<br />
Executable data : Killed<br />
Executable heap : Killed<br />
Executable stack : Killed<br />
Executable anonymous mapping (mprotect) : Killed<br />
Executable bss (mprotect) : Killed<br />
Executable data (mprotect) : Killed<br />
Executable heap (mprotect) : Killed<br />
Executable stack (mprotect) : Killed<br />
Executable shared library bss (mprotect) : Killed<br />
Executable shared library data (mprotect): Killed<br />
Writable text segments : Killed<br />
Anonymous mapping randomisation test : 16 bits (guessed)<br />
Heap randomisation test (ET_EXEC) : 13 bits (guessed)<br />
Heap randomisation test (ET_DYN) : 25 bits (guessed)<br />
Main executable randomisation (ET_EXEC) : 16 bits (guessed)<br />
Main executable randomisation (ET_DYN) : 17 bits (guessed)<br />
Shared library randomisation test : 16 bits (guessed)<br />
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)<br />
Stack randomisation test (PAGEEXEC) : No randomisation<br />
Return to function (strcpy) : Vulnerable<br />
Return to function (memcpy) : Vulnerable<br />
Return to function (strcpy, RANDEXEC) : Killed<br />
Return to function (memcpy, RANDEXEC) : Killed<br />
Executable shared library bss : Killed<br />
Executable shared library data : Killed<br />
<br />
In the above example run you notice that:<br />
<br />
* strcpy and memcpy are listed as Vulnerable. This is expected and normal - it is simply showing the need for a technology such as ProPolice/SSP<br />
* there is no randomization for PAGEEXEC. This is normal since our recommended x86 kernel configuration didn't activate the PAGEEXEC setting. However, on arches that support a true NX (non-executable) bit (most of them do, including x86_64), PAGEEXEC is the only method available for NOEXEC and has no performance hit.<br />
<br />
== Filesystem Protection ==<br />
<br />
=== Fighting Chroot and Filesystem Abuse ===<br />
<br />
Grsecurity2 includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on /proc usage, chrooting, linking, etc.<br />
<br />
=== Kernel Configuration ===<br />
<br />
We recommend the following grsecurity kernel configuration for filesystem protection:<br />
<br />
#<br />
# Filesystem Protections<br />
#<br />
CONFIG_GRKERNSEC_PROC=y<br />
# CONFIG_GRKERNSEC_PROC_USER is not set<br />
CONFIG_GRKERNSEC_PROC_USERGROUP=y<br />
CONFIG_GRKERNSEC_PROC_GID=3<br />
CONFIG_GRKERNSEC_PROC_ADD=y<br />
CONFIG_GRKERNSEC_LINK=y<br />
CONFIG_GRKERNSEC_FIFO=y<br />
CONFIG_GRKERNSEC_CHROOT=y<br />
CONFIG_GRKERNSEC_CHROOT_MOUNT=y<br />
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y<br />
CONFIG_GRKERNSEC_CHROOT_PIVOT=y<br />
CONFIG_GRKERNSEC_CHROOT_CHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_CHMOD=y<br />
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_MKNOD=y<br />
CONFIG_GRKERNSEC_CHROOT_SHMAT=y<br />
CONFIG_GRKERNSEC_CHROOT_UNIX=y<br />
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y<br />
CONFIG_GRKERNSEC_CHROOT_NICE=y<br />
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y<br />
CONFIG_GRKERNSEC_CHROOT_CAPS=y<br />
<br />
=== Triggering the Security Mechanism ===<br />
<br />
When you're using a kernel compiled with the above (or similar) settings, you will get the option to enable/disable many of the options through the /proc filesystem or via sysctl.<br />
<br />
The example below shows an excerpt of a typical /etc/sysctl.conf:<br />
<br />
kernel.grsecurity.chroot_deny_sysctl = 1<br />
kernel.grsecurity.chroot_caps = 1<br />
kernel.grsecurity.chroot_execlog = 0<br />
kernel.grsecurity.chroot_restrict_nice = 1<br />
kernel.grsecurity.chroot_deny_mknod = 1<br />
kernel.grsecurity.chroot_deny_chmod = 1<br />
kernel.grsecurity.chroot_enforce_chdir = 1<br />
kernel.grsecurity.chroot_deny_pivot = 1<br />
kernel.grsecurity.chroot_deny_chroot = 1<br />
kernel.grsecurity.chroot_deny_fchdir = 1<br />
kernel.grsecurity.chroot_deny_mount = 1<br />
kernel.grsecurity.chroot_deny_unix = 1<br />
kernel.grsecurity.chroot_deny_shmat = 1<br />
<br />
You can enable or disable settings at will using the sysctl command:<br />
<br />
(Toggling the exec_logging feature ON)<br />
# sysctl -w kernel.grsecurity.exec_logging = 1<br />
(Toggling the exec_logging feature OFF)<br />
# sysctl -w kernel.grsecurity.exec_logging = 0<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
== Kernel Auditing ==<br />
<br />
=== Extend your System's Logging Facilities ===<br />
<br />
grsecurity adds extra functionality to the kernel pertaining the logging. With grsecurity's Kernel Auditing the kernel informs you when applications are started, devices (un)mounted, etc.<br />
<br />
=== The various Kernel Audit Settings ===<br />
<br />
The following kernel configuration section can be used to enable grsecurity's Kernel Audit Settings:<br />
<br />
#<br />
# Kernel Auditing<br />
#<br />
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set<br />
CONFIG_GRKERNSEC_EXECLOG=y<br />
CONFIG_GRKERNSEC_RESLOG=y<br />
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y<br />
CONFIG_GRKERNSEC_AUDIT_CHDIR=y<br />
CONFIG_GRKERNSEC_AUDIT_MOUNT=y<br />
CONFIG_GRKERNSEC_AUDIT_IPC=y<br />
CONFIG_GRKERNSEC_SIGNAL=y<br />
CONFIG_GRKERNSEC_FORKFAIL=y<br />
CONFIG_GRKERNSEC_TIME=y<br />
CONFIG_GRKERNSEC_PROC_IPADDR=y<br />
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y<br />
<br />
== Process Restrictions ==<br />
<br />
=== Executable Protection ===<br />
<br />
With grsecurity you can restrict executables. Since most exploits work through one or more running processes this protection can save your system's health.<br />
<br />
=== Network Protection ===<br />
<br />
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity includes randomization patches to counter these attacks. Apart from these you can also enable socket restrictions, disallowing certain groups network access alltogether.<br />
<br />
=== Kernel Settings ===<br />
<br />
The following kernel settings enable various executable and network protections:<br />
<br />
#<br />
# Executable Protections<br />
#<br />
CONFIG_GRKERNSEC_EXECVE=y<br />
CONFIG_GRKERNSEC_DMESG=y<br />
CONFIG_GRKERNSEC_RANDPID=y<br />
CONFIG_GRKERNSEC_TPE=y<br />
CONFIG_GRKERNSEC_TPE_ALL=y<br />
CONFIG_GRKERNSEC_TPE_GID=100<br />
<br />
#<br />
# Network Protections<br />
#<br />
CONFIG_GRKERNSEC_RANDNET=y<br />
CONFIG_GRKERNSEC_RANDISN=y<br />
CONFIG_GRKERNSEC_RANDID=y<br />
CONFIG_GRKERNSEC_RANDSRC=y<br />
CONFIG_GRKERNSEC_RANDRPC=y<br />
# CONFIG_GRKERNSEC_SOCKET is not set<br />
<br />
= RBAC =<br />
<br />
Role Based Access Control<br />
<br />
There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.<br />
<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
== Configuring the Kernel ==<br />
<br />
The recommended kernel setting for RBAC is:<br />
<br />
#<br />
# Role Based Access Control Options<br />
#<br />
CONFIG_GRKERNSEC_ACL_HIDEKERN=y<br />
CONFIG_GRKERNSEC_ACL_MAXTRIES=3<br />
CONFIG_GRKERNSEC_ACL_TIMEOUT=30<br />
<br />
== Working with gradm ==<br />
<br />
gradm is a tool which allows you to administer and maintain a policy for your system. With it, you can enable or disable the RBAC system, reload the RBAC roles, change your role, set a password for admin mode, etc.<br />
<br />
When you install gradm a default policy will be installed in /etc/grsec/policy. Please see in AUR for gradm package.<br />
<br />
By default, the RBAC policies are not activated. It is the sysadmin's job to determine when the system should have an RBAC policy enforced. Before activating the RBAC system you should set an admin password.<br />
<br />
# gradm -P admin<br />
Setting up grsecurity RBAC password<br />
Password: (Enter a well-chosen password)<br />
Re-enter Password: (Enter the same password for confirmation)<br />
Password written in /etc/grsec/pw<br />
# gradm -E<br />
<br />
To disable the RBAC system, run gradm -D. If you are not allowed to, you first need to switch to the admin role:<br />
<br />
# gradm -a admin<br />
Password: (Enter your admin role password)<br />
# gradm -D<br />
<br />
If you want to leave the admin role, run gradm -u admin:<br />
<br />
# gradm -u admin<br />
<br />
== Generating a Policy ==<br />
<br />
The RBAC system comes with a great feature called "learning mode". The learning mode can generate an anticipatory least privilege policy for your system. This allows for time and money savings by being able to rapidly deploy multiple secure servers.<br />
<br />
To use the learning mode, activate it using gradm:<br />
<br />
# gradm -F -L /etc/grsec/learning.log<br />
<br />
Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate or any other heavy file i/o operation as this can really slow down the processing time.<br />
<br />
When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under {{ic|/etc/grsec/learning.roles}}:<br />
<br />
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles<br />
<br />
Audit the {{ic|/etc/grsec/learning.roles}} and save it as {{ic|/etc/grsec/policy}} (mode {{ic|0600}}) when you are finished.<br />
<br />
# mv /etc/grsec/learning.roles /etc/grsec/policy<br />
# chmod 0600 /etc/grsec/policy<br />
<br />
You will now be able to enable the RBAC system with your new learned policy.<br />
<br />
== Tweaking your Policy ==<br />
<br />
An interesting feature of grsecurity 2.x is Set Operation Support for the configuration file. Currently it supports unions, intersections and differences of sets (of objects in this case).<br />
<br />
define objset1 {<br />
/root/blah rw<br />
/root/blah2 r<br />
/root/blah3 x<br />
}<br />
<br />
define somename2 {<br />
/root/test1 rw<br />
/root/blah2 rw<br />
/root/test3 h<br />
}<br />
<br />
Here is an example of its use, and the resulting objects that will be added to your subject:<br />
<br />
subject /somebinary o<br />
$objset1 & $somename2<br />
<br />
The above would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah2 r<br />
<br />
This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.<br />
<br />
subject /somebinary o<br />
$objset1 | $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 rw<br />
/root/blah3 x<br />
/root/test1 rw<br />
/root/test3 h<br />
<br />
This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.<br />
<br />
subject /somebinary o<br />
$objset1 - $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 h<br />
/root/blah3 x<br />
<br />
This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.<br />
<br />
In some obscure pseudo-language you could see this as:<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained /tmp/blah r) )<br />
then<br />
$objset1 - $objset2 would contain /tmp/blah w<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained / rwx) )<br />
then <br />
$objset1 - $objset2 would contain /tmp/blah h<br />
<br />
As for order of precedence (from highest to lowest): "-, & |".<br />
<br />
If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:<br />
<br />
(($set1 - $set2) | $set3) & $set4<br />
<br />
= Using linux-pax-flags AUR Package =<br />
<br />
The linux-pax-flags program is what makes using PaX on Arch Linux easy as pie. When you run this program it will set the PaX flags for all the problematic programs for you. However, if you use some uncommon program it may have problems forcing you to set the paxctl flags yourself. You will most likely see something like {{ic|Denied RWX}} in journalctl. That means you will need to disable MPROTECT for the program {{ic|paxctl -cPEmRXS /usr/bin/bla}}<br />
<br />
After you find what PaX flags need to be set post a comment on the linux-pax-flags AUR package so it can be added.<br />
<br />
More extensive documentation of the linux-pax-flags utility is to be found on it's man page.<br />
<br />
= Tips and Tricks =<br />
<br />
Because you will not be able to change the PaX flags for a running program, and that the vast majority of programs which would need them are graphical, it is strongly advisable to not use a Graphical Login like GDM or KDM. Instead simply have the system drop you to a console to log in and use {{ic|startx}}. Then you will have a chance to set the PaX flags before anything starts. For the same reasons it is strongly advisable to update your system and run {{ic|linux-pax-flags}} right after boot, before running {{ic|startx}}.<br />
<br />
Grsecurity will harden /proc and /sys so your normal user will no longer be able to see the network status, becuase of this non of your desktop network monitors will work. Instead just install terminal based monitoring programs, such as [https://www.archlinux.org/packages/community/x86_64/nmon/ nmon] or [https://www.archlinux.org/packages/community/x86_64/nload/ nload] and run them as root, or as a user in the proc-trusted group.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Grsecurity&diff=272417Grsecurity2013-08-25T01:33:04Z<p>Hunterthomson: Added Build Options section</p>
<hr />
<div>[[Category:Kernel]][[Category:Security]]<br />
The grsecurity project, hosted on https://grsecurity.net, provides various patches to the Linux kernel which enhance your system's overall security. grsecurity also ships with PaX which provides the most advanced memory protections of any OS. PaX invented ALSR and shows that it is only the tip of the iceberg. The RBAC Mandatory Access Control system of grsecurity was the inspriation for SELinux and AppArmor.<br />
<br />
In short, a Linux kernel hardened with grsecurity is the most hardened kernel you could have. Not even OpenBSD has all the hardening features it provides. A comprehensive list is maintained on the [http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options grsecurity features page] itself. However, the grsecurity Wiki is often out-of-date. The best way is to simply read the help text in the kernel config.<br />
<br />
Arch has all the utilities and kernel packages you need to run a grsecurity hardened Arch Linux system in the AUR. Arch even has a script called [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] which will make using PaX as painless as possible by setting all of the PaX flags for you.<br />
<br />
You can install the kernel either from a binary repository or - if you want more control - manually from the AUR.<br />
<br />
= Build Options =<br />
<br />
There are three ways you can install a Grsecruity hardened kernel in Arch. The first is by adding a repository to install the binary kernel. The second option is to build it from the AUR package. The third option is to patch and build the kernel all by hand.<br />
<br />
Your best bet is probably to first use the binary Grsecurity kernel repository. If you have the time, build the AUR package yourself for added security. You would really never want to build and maintain the kernel outside the package management system. That text is just their for completeness and may be removed.<br />
<br />
{{note|Any way you choose to install the Grsecurity kernel you will need to also install [https://aur.archlinux.org/packages/gradm/ gradm], [https://aur.archlinux.org/packages/paxctl/ paxctl], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags]}}<br />
<br />
= Install from binary packages =<br />
<br />
Add the [http://arsch.orgizm.net/ Arsch Arch Linux Repository] to your package sources and install the kernel with {{ic|pacman -Sy linux-grsec}} (or the PaX only kernel with {{ic|pacman -Sy linux-pax}}). Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
{{note|Use a startup script to set the sysctl options you want and then disable sysctl support. If you leave sysctl support enabled then an attacker who can run a command as the Root user will be able to turn off all hardening options.}}<br />
<br />
= Setup and Install from AUR =<br />
<br />
To build the AUR package we will follow this general game plan. First, download all needed files and check GPG signatures. Second, configure kernel and compile. Third, copy a backup of these files to the Root users home folder. Forth, install utilities needed for PaX and RBAC. Fifth, install the kernel package. Sixth, run linux-pax-flags to poke security holes in applications that will not run without them. Finally, reboot into your hardened system.<br />
<br />
== Download Files ==<br />
<br />
Download the packages<br />
[https://aur.archlinux.org/packages/linux-grsec/ linux-grsec]<br />
Or<br />
[https://aur.archlinux.org/packages/linux-grsec-lts/ linux-grsec-lts]<br />
<br />
Kernel linux-3.X.tar.xz and current patch-3.X.X.tar.xz also the .sign signature files for each.<br />
[https://www.kernel.org/pub/linux/kernel/v3.x/ kernel.org]<br />
<br />
Download the current grsecurity patch and Signatures<br />
[https://grsecurity.net/test.php grsecurity Test]<br />
Or<br />
[https://grsecurity.net/download_stable.php grsecurity Stable] for LTS kernel<br />
<br />
{{tip|The Grsecurity Test is in fact stable. The Stable Grsecurity version is just for the LTS}}<br />
<br />
=== Verify The GPG Signatures ===<br />
<br />
With the .sign files in the same directory as the file it is a a signature of, verify the signature like so...<br />
<br />
$ gpg2 --verify linux-3.10.tar.sign<br />
<br />
== Setup Build Environment ==<br />
<br />
Unpack the linux-grsec.tar.gz and copy all the files into it<br />
<br />
$ tar xzf linux-grsec.tar.gz<br />
$ cp ~/Downloads/linux-3.10.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/patch-3.10.9.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/grsecurity-2.9.1-3.10.9-201308202015.patch ~/linux-grsec<br />
<br />
Change into the build directory<br />
<br />
$ cd ~/linux-grsec<br />
<br />
== Build the Kernel Package ==<br />
<br />
It is going to take a long time to build the kernel because it is based on the default Arch kernel config with has about ten times as make modules enabled then your system actually needs. However, it is a known working config and to eliminate any more variables it is advisable to just live with the extra build time.<br />
<br />
Build the package<br />
<br />
$ MENUCONFIG=2 makepkg<br />
<br />
You should be dropped into the ncurses GUI now. Navigate to the grsecurity settings to verify the configuration and/or change things as needed. These setting can be found in {{ic|Security options ---> Grsecurity ---> Customize Configuration --->}}<br />
<br />
For both Desktops and Servers after you are sure you will not need to change any of the Grsecurity settings with sysctl, disable {{ic|Sysctl support}} found in {{ic|Sysctl Support}}.<br />
<br />
If this kernel is for a Server also enable {{ic|Disable privileged I/O}} found in {{ic|Memory Protections}}.<br />
<br />
All other setting should be optimal as they are, so now exit out of the ncurses GUI config and Save. Now the package should start to build. If all goes well you will have two .pkg.tar.xz packages one for the kernel and one for the kernel-headers.<br />
<br />
=== Make a Backup ===<br />
<br />
Keep all linux-grsec.tar.gz files along with the grsecruity patch and compiled packages in the Root users home folder. That way you can roll back if needed. Every time a new grsecurity patch is release you will not be able to download outdated patches every again.<br />
<br />
# mkdir /root/3.10.9<br />
# cp -r /home/USER/linux-grsec /root/3.10.9<br />
<br />
== Install PaX and RBAC Utilities ==<br />
<br />
The AUR also has [https://aur.archlinux.org/packages/paxctl/ paxctl], [https://aur.archlinux.org/packages/gradm/ gradm], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] packages that you will need.<br />
<br />
For simplicities sake I will assume you are using yaourt to install package form the AUR, however any other way of installing these packages will work as well.<br />
<br />
$ yaourt -S linux-pax-flags paxctl gradm<br />
<br />
== Set PaX Flags ==<br />
<br />
Use the linux-pax-flags program to configure all the PaX flags for troublesome programs.<br />
More information can be found in the Using linux-pax-flags AUR Package section.<br />
<br />
# linux-pax-flags<br />
<br />
== Install Hardened Kernel ==<br />
<br />
Now that all the needed utilities are installed and the system is configured for PaX, install the hardened kernel and headers.<br />
<br />
# pacman -U /root/3.10.9/*.pkg.tar.xz<br />
<br />
Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
You should now be in your hardened system. Just make sure to run {{ic|linux-pax-flags}} after every time you update your system or install a new program and you should have a trouble free experience.<br />
<br />
= Build Kernel without the AUR =<br />
<br />
Throughout this document we will talk about kernel configuration using the kernel variables like CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. These are the variables that the kernel build process uses to determine if a certain feature needs to be compiled.<br />
<br />
When you configure your kernel through make menuconfig or similar, you receive a user interface through which you can select the various kernel options. If you select the Help button at a certain kernel feature you will see at the top that it lists such a kernel variable.<br />
<br />
You can therefore still configure your kernel as you like - with a bit of thinking. And if you can't find a certain option, there's always the possibility to edit /usr/src/linux/.config by hand :)<br />
<br />
Of course, to be able to select the various grsecurity kernel options, you must enable grsecurity in your kernel.<br />
See [[default grsecurity kernel configuration]]<br />
<br />
== PaX ==<br />
<br />
=== Fighting the Exploitation of Software Bugs ===<br />
<br />
PaX introduces a couple of security mechanisms that make it harder for attackers to exploit software bugs that involve memory corruption (so do not treat PaX as if it protects against all possible software bugs). The PaX introduction document talks about three possible exploit techniques:<br />
<br />
# introduce/execute arbitrary code<br />
# execute existing code out of original program order<br />
# execute existing code in original program order with arbitrary data<br />
<br />
One prevention method disallows executable code to be stored in writable memory. When we look at a process, it requires five memory regions:<br />
<br />
# a data section which contains the statically allocated and global data<br />
# a BSS region (Block Started by Symbol) which contains information about the zero-initialized data of the process<br />
# a code region, also called the text segment, which contains the executable instructions<br />
# a heap which contains the dynamically allocated memory<br />
# a stack which contains the local variables<br />
<br />
The first PaX prevention method, called NOEXEC, is meant to give control over the runtime code generation. It marks memory pages that do not contain executable code as non-executable. This means that the heap and the stack, which only contain variable data and shouldn't contain executable code, are marked as non-executable. Exploits that place code in these areas with the intention of running it will fail.<br />
<br />
NOEXEC does more than this actually, interested readers should focus their attention to the [http://pax.grsecurity.net/docs/noexec.txt PaX NOEXEC documentation].<br />
<br />
The second PaX prevention method, called ASLR (Address Space Layout Randomization), randomize the addresses given to memory requests. Where previously memory was assigned contiguously (which means exploits know where the tasks' memory regions are situated) ASLR randomizes this allocation, rendering techniques that rely on this information useless.<br />
<br />
More information about ASLR can be found [http://pax.grsecurity.net/docs/aslr.txt online].<br />
<br />
=== PaX kernel configuration ===<br />
<br />
<br />
The recommended kernel setting for PaX is:<br />
<br />
#<br />
# Security options<br />
#<br />
#<br />
# PaX<br />
#<br />
CONFIG_PAX=y<br />
#<br />
# PaX Control<br />
#<br />
# CONFIG_PAX_SOFTMODE is not set<br />
CONFIG_PAX_EI_PAX=y<br />
CONFIG_PAX_PT_PAX_FLAGS=y<br />
CONFIG_PAX_NO_ACL_FLAGS=y<br />
# CONFIG_PAX_HAVE_ACL_FLAGS is not set<br />
# CONFIG_PAX_HOOK_ACL_FLAGS is not set<br />
#<br />
# Non-executable pages<br />
#<br />
CONFIG_PAX_NOEXEC=y<br />
CONFIG_PAX_PAGEEXEC=y<br />
CONFIG_PAX_SEGMEXEC=y<br />
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set<br />
CONFIG_PAX_DEFAULT_SEGMEXEC=y<br />
CONFIG_PAX_EMUTRAMP=y<br />
CONFIG_PAX_MPROTECT=y<br />
# CONFIG_PAX_NOELFRELOCS is not set<br />
#<br />
# Address Space Layout Randomization<br />
#<br />
CONFIG_PAX_ASLR=y<br />
CONFIG_PAX_RANDKSTACK=y<br />
CONFIG_PAX_RANDUSTACK=y<br />
CONFIG_PAX_RANDMMAP=y<br />
#<br />
# Miscellaneous hardening features<br />
#<br />
CONFIG_PAX_MEMORY_SANITIZE=y<br />
CONFIG_PAX_MEMORY_UDEREF=y<br />
CONFIG_KEYS=y<br />
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_NETWORK_XFRM=y<br />
CONFIG_SECURITY_CAPABILITIES=m<br />
CONFIG_SECURITY_ROOTPLUG=m<br />
<br />
If you are running a non-x86 system you will observe that there is no CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC instead as it is the only non-exec implementation around.<br />
<br />
=== Controlling PaX ===<br />
<br />
Not all Linux applications are happy with the PaX security restrictions. These tools include xorg-x11, java, mplayer, xmms and others. If you plan on using them you can elevate the protections for these applications using chpax and paxctl. You can find they on AUR.<br />
<br />
You can also use pax-utils, which is a small toolbox which contains useful applications to administrate a PaX aware server. Find it on AUR.<br />
<br />
Interesting tools include scanelf and pspax:<br />
<br />
* With scanelf you can scan over library and binary directories and list the various permissions and ELF types that pertain to running an ideal pax/grsec setup<br />
* With pspax you can display PaX flags/capabilities/xattr from the kernel's perspective<br />
<br />
=== Verifying the PaX Settings ===<br />
<br />
Peter Busser has written a regression test suite called paxtest. This tool will check various cases of possible attack vectors and inform you of the result. When you run it, it will leave a logfile called paxtest.log in the current working directory.<br />
<br />
# paxtest<br />
Executable anonymous mapping : Killed<br />
Executable bss : Killed<br />
Executable data : Killed<br />
Executable heap : Killed<br />
Executable stack : Killed<br />
Executable anonymous mapping (mprotect) : Killed<br />
Executable bss (mprotect) : Killed<br />
Executable data (mprotect) : Killed<br />
Executable heap (mprotect) : Killed<br />
Executable stack (mprotect) : Killed<br />
Executable shared library bss (mprotect) : Killed<br />
Executable shared library data (mprotect): Killed<br />
Writable text segments : Killed<br />
Anonymous mapping randomisation test : 16 bits (guessed)<br />
Heap randomisation test (ET_EXEC) : 13 bits (guessed)<br />
Heap randomisation test (ET_DYN) : 25 bits (guessed)<br />
Main executable randomisation (ET_EXEC) : 16 bits (guessed)<br />
Main executable randomisation (ET_DYN) : 17 bits (guessed)<br />
Shared library randomisation test : 16 bits (guessed)<br />
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)<br />
Stack randomisation test (PAGEEXEC) : No randomisation<br />
Return to function (strcpy) : Vulnerable<br />
Return to function (memcpy) : Vulnerable<br />
Return to function (strcpy, RANDEXEC) : Killed<br />
Return to function (memcpy, RANDEXEC) : Killed<br />
Executable shared library bss : Killed<br />
Executable shared library data : Killed<br />
<br />
In the above example run you notice that:<br />
<br />
* strcpy and memcpy are listed as Vulnerable. This is expected and normal - it is simply showing the need for a technology such as ProPolice/SSP<br />
* there is no randomization for PAGEEXEC. This is normal since our recommended x86 kernel configuration didn't activate the PAGEEXEC setting. However, on arches that support a true NX (non-executable) bit (most of them do, including x86_64), PAGEEXEC is the only method available for NOEXEC and has no performance hit.<br />
<br />
== Filesystem Protection ==<br />
<br />
=== Fighting Chroot and Filesystem Abuse ===<br />
<br />
Grsecurity2 includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on /proc usage, chrooting, linking, etc.<br />
<br />
=== Kernel Configuration ===<br />
<br />
We recommend the following grsecurity kernel configuration for filesystem protection:<br />
<br />
#<br />
# Filesystem Protections<br />
#<br />
CONFIG_GRKERNSEC_PROC=y<br />
# CONFIG_GRKERNSEC_PROC_USER is not set<br />
CONFIG_GRKERNSEC_PROC_USERGROUP=y<br />
CONFIG_GRKERNSEC_PROC_GID=3<br />
CONFIG_GRKERNSEC_PROC_ADD=y<br />
CONFIG_GRKERNSEC_LINK=y<br />
CONFIG_GRKERNSEC_FIFO=y<br />
CONFIG_GRKERNSEC_CHROOT=y<br />
CONFIG_GRKERNSEC_CHROOT_MOUNT=y<br />
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y<br />
CONFIG_GRKERNSEC_CHROOT_PIVOT=y<br />
CONFIG_GRKERNSEC_CHROOT_CHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_CHMOD=y<br />
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_MKNOD=y<br />
CONFIG_GRKERNSEC_CHROOT_SHMAT=y<br />
CONFIG_GRKERNSEC_CHROOT_UNIX=y<br />
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y<br />
CONFIG_GRKERNSEC_CHROOT_NICE=y<br />
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y<br />
CONFIG_GRKERNSEC_CHROOT_CAPS=y<br />
<br />
=== Triggering the Security Mechanism ===<br />
<br />
When you're using a kernel compiled with the above (or similar) settings, you will get the option to enable/disable many of the options through the /proc filesystem or via sysctl.<br />
<br />
The example below shows an excerpt of a typical /etc/sysctl.conf:<br />
<br />
kernel.grsecurity.chroot_deny_sysctl = 1<br />
kernel.grsecurity.chroot_caps = 1<br />
kernel.grsecurity.chroot_execlog = 0<br />
kernel.grsecurity.chroot_restrict_nice = 1<br />
kernel.grsecurity.chroot_deny_mknod = 1<br />
kernel.grsecurity.chroot_deny_chmod = 1<br />
kernel.grsecurity.chroot_enforce_chdir = 1<br />
kernel.grsecurity.chroot_deny_pivot = 1<br />
kernel.grsecurity.chroot_deny_chroot = 1<br />
kernel.grsecurity.chroot_deny_fchdir = 1<br />
kernel.grsecurity.chroot_deny_mount = 1<br />
kernel.grsecurity.chroot_deny_unix = 1<br />
kernel.grsecurity.chroot_deny_shmat = 1<br />
<br />
You can enable or disable settings at will using the sysctl command:<br />
<br />
(Toggling the exec_logging feature ON)<br />
# sysctl -w kernel.grsecurity.exec_logging = 1<br />
(Toggling the exec_logging feature OFF)<br />
# sysctl -w kernel.grsecurity.exec_logging = 0<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
== Kernel Auditing ==<br />
<br />
=== Extend your System's Logging Facilities ===<br />
<br />
grsecurity adds extra functionality to the kernel pertaining the logging. With grsecurity's Kernel Auditing the kernel informs you when applications are started, devices (un)mounted, etc.<br />
<br />
=== The various Kernel Audit Settings ===<br />
<br />
The following kernel configuration section can be used to enable grsecurity's Kernel Audit Settings:<br />
<br />
#<br />
# Kernel Auditing<br />
#<br />
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set<br />
CONFIG_GRKERNSEC_EXECLOG=y<br />
CONFIG_GRKERNSEC_RESLOG=y<br />
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y<br />
CONFIG_GRKERNSEC_AUDIT_CHDIR=y<br />
CONFIG_GRKERNSEC_AUDIT_MOUNT=y<br />
CONFIG_GRKERNSEC_AUDIT_IPC=y<br />
CONFIG_GRKERNSEC_SIGNAL=y<br />
CONFIG_GRKERNSEC_FORKFAIL=y<br />
CONFIG_GRKERNSEC_TIME=y<br />
CONFIG_GRKERNSEC_PROC_IPADDR=y<br />
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y<br />
<br />
== Process Restrictions ==<br />
<br />
=== Executable Protection ===<br />
<br />
With grsecurity you can restrict executables. Since most exploits work through one or more running processes this protection can save your system's health.<br />
<br />
=== Network Protection ===<br />
<br />
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity includes randomization patches to counter these attacks. Apart from these you can also enable socket restrictions, disallowing certain groups network access alltogether.<br />
<br />
=== Kernel Settings ===<br />
<br />
The following kernel settings enable various executable and network protections:<br />
<br />
#<br />
# Executable Protections<br />
#<br />
CONFIG_GRKERNSEC_EXECVE=y<br />
CONFIG_GRKERNSEC_DMESG=y<br />
CONFIG_GRKERNSEC_RANDPID=y<br />
CONFIG_GRKERNSEC_TPE=y<br />
CONFIG_GRKERNSEC_TPE_ALL=y<br />
CONFIG_GRKERNSEC_TPE_GID=100<br />
<br />
#<br />
# Network Protections<br />
#<br />
CONFIG_GRKERNSEC_RANDNET=y<br />
CONFIG_GRKERNSEC_RANDISN=y<br />
CONFIG_GRKERNSEC_RANDID=y<br />
CONFIG_GRKERNSEC_RANDSRC=y<br />
CONFIG_GRKERNSEC_RANDRPC=y<br />
# CONFIG_GRKERNSEC_SOCKET is not set<br />
<br />
= RBAC =<br />
<br />
Role Based Access Control<br />
<br />
There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.<br />
<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
== Configuring the Kernel ==<br />
<br />
The recommended kernel setting for RBAC is:<br />
<br />
#<br />
# Role Based Access Control Options<br />
#<br />
CONFIG_GRKERNSEC_ACL_HIDEKERN=y<br />
CONFIG_GRKERNSEC_ACL_MAXTRIES=3<br />
CONFIG_GRKERNSEC_ACL_TIMEOUT=30<br />
<br />
== Working with gradm ==<br />
<br />
gradm is a tool which allows you to administer and maintain a policy for your system. With it, you can enable or disable the RBAC system, reload the RBAC roles, change your role, set a password for admin mode, etc.<br />
<br />
When you install gradm a default policy will be installed in /etc/grsec/policy. Please see in AUR for gradm package.<br />
<br />
By default, the RBAC policies are not activated. It is the sysadmin's job to determine when the system should have an RBAC policy enforced. Before activating the RBAC system you should set an admin password.<br />
<br />
# gradm -P admin<br />
Setting up grsecurity RBAC password<br />
Password: (Enter a well-chosen password)<br />
Re-enter Password: (Enter the same password for confirmation)<br />
Password written in /etc/grsec/pw<br />
# gradm -E<br />
<br />
To disable the RBAC system, run gradm -D. If you are not allowed to, you first need to switch to the admin role:<br />
<br />
# gradm -a admin<br />
Password: (Enter your admin role password)<br />
# gradm -D<br />
<br />
If you want to leave the admin role, run gradm -u admin:<br />
<br />
# gradm -u admin<br />
<br />
== Generating a Policy ==<br />
<br />
The RBAC system comes with a great feature called "learning mode". The learning mode can generate an anticipatory least privilege policy for your system. This allows for time and money savings by being able to rapidly deploy multiple secure servers.<br />
<br />
To use the learning mode, activate it using gradm:<br />
<br />
# gradm -F -L /etc/grsec/learning.log<br />
<br />
Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate or any other heavy file i/o operation as this can really slow down the processing time.<br />
<br />
When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under {{ic|/etc/grsec/learning.roles}}:<br />
<br />
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles<br />
<br />
Audit the {{ic|/etc/grsec/learning.roles}} and save it as {{ic|/etc/grsec/policy}} (mode {{ic|0600}}) when you are finished.<br />
<br />
# mv /etc/grsec/learning.roles /etc/grsec/policy<br />
# chmod 0600 /etc/grsec/policy<br />
<br />
You will now be able to enable the RBAC system with your new learned policy.<br />
<br />
== Tweaking your Policy ==<br />
<br />
An interesting feature of grsecurity 2.x is Set Operation Support for the configuration file. Currently it supports unions, intersections and differences of sets (of objects in this case).<br />
<br />
define objset1 {<br />
/root/blah rw<br />
/root/blah2 r<br />
/root/blah3 x<br />
}<br />
<br />
define somename2 {<br />
/root/test1 rw<br />
/root/blah2 rw<br />
/root/test3 h<br />
}<br />
<br />
Here is an example of its use, and the resulting objects that will be added to your subject:<br />
<br />
subject /somebinary o<br />
$objset1 & $somename2<br />
<br />
The above would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah2 r<br />
<br />
This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.<br />
<br />
subject /somebinary o<br />
$objset1 | $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 rw<br />
/root/blah3 x<br />
/root/test1 rw<br />
/root/test3 h<br />
<br />
This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.<br />
<br />
subject /somebinary o<br />
$objset1 - $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 h<br />
/root/blah3 x<br />
<br />
This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.<br />
<br />
In some obscure pseudo-language you could see this as:<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained /tmp/blah r) )<br />
then<br />
$objset1 - $objset2 would contain /tmp/blah w<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained / rwx) )<br />
then <br />
$objset1 - $objset2 would contain /tmp/blah h<br />
<br />
As for order of precedence (from highest to lowest): "-, & |".<br />
<br />
If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:<br />
<br />
(($set1 - $set2) | $set3) & $set4<br />
<br />
= Using linux-pax-flags AUR Package =<br />
<br />
The linux-pax-flags program is what makes using PaX on Arch Linux easy as pie. When you run this program it will set the PaX flags for all the problematic programs for you. However, if you use some uncommon program it may have problems forcing you to set the paxctl flags yourself. You will most likely see something like {{ic|Denied RWX}} in journalctl. That means you will need to disable MPROTECT for the program {{ic|paxctl -cPEmRXS /usr/bin/bla}}<br />
<br />
After you find what PaX flags need to be set post a comment on the linux-pax-flags AUR package so it can be added.<br />
<br />
More extensive documentation of the linux-pax-flags utility is to be found on it's man page.<br />
<br />
= Tips and Tricks =<br />
<br />
Because you will not be able to change the PaX flags for a running program, and that the vast majority of programs which would need them are graphical, it is strongly advisable to not use a Graphical Login like GDM or KDM. Instead simply have the system drop you to a console to log in and use {{ic|startx}}. Then you will have a chance to set the PaX flags before anything starts. For the same reasons it is strongly advisable to update your system and run {{ic|linux-pax-flags}} right after boot, before running {{ic|startx}}.<br />
<br />
Grsecurity will harden /proc and /sys so your normal user will no longer be able to see the network status, becuase of this non of your desktop network monitors will work. Instead just install terminal based monitoring programs, such as [https://www.archlinux.org/packages/community/x86_64/nmon/ nmon] or [https://www.archlinux.org/packages/community/x86_64/nload/ nload] and run them as root, or as a user in the proc-trusted group.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Grsecurity&diff=272416Grsecurity2013-08-25T01:21:26Z<p>Hunterthomson: /* Setup and Build Kernel without the AUR */</p>
<hr />
<div>[[Category:Kernel]][[Category:Security]]<br />
The grsecurity project, hosted on https://grsecurity.net, provides various patches to the Linux kernel which enhance your system's overall security. grsecurity also ships with PaX which provides the most advanced memory protections of any OS. PaX invented ALSR and shows that it is only the tip of the iceberg. The RBAC Mandatory Access Control system of grsecurity was the inspriation for SELinux and AppArmor.<br />
<br />
In short, a Linux kernel hardened with grsecurity is the most hardened kernel you could have. Not even OpenBSD has all the hardening features it provides. A comprehensive list is maintained on the [http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options grsecurity features page] itself. However, the grsecurity Wiki is often out-of-date. The best way is to simply read the help text in the kernel config.<br />
<br />
Arch has all the utilities and kernel packages you need to run a grsecurity hardened Arch Linux system in the AUR. Arch even has a script called [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] which will make using PaX as painless as possible by setting all of the PaX flags for you.<br />
<br />
You can install the kernel either from a binary repository or - if you want more control - manually from the AUR.<br />
<br />
= Install from binary packages =<br />
<br />
Add the [http://arsch.orgizm.net/ Arsch Arch Linux Repository] to your package sources and install the kernel with {{ic|pacman -Sy linux-grsec}} (or the PaX only kernel with {{ic|pacman -Sy linux-pax}}). Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
= Setup and Install from AUR =<br />
<br />
To build the AUR package we will follow this general game plan. First, download all needed files and check GPG signatures. Second, configure kernel and compile. Third, copy a backup of these files to the Root users home folder. Forth, install utilities needed for PaX and RBAC. Fifth, install the kernel package. Sixth, run linux-pax-flags to poke security holes in applications that will not run without them. Finally, reboot into your hardened system.<br />
<br />
== Download Files ==<br />
<br />
Download the packages<br />
[https://aur.archlinux.org/packages/linux-grsec/ linux-grsec]<br />
Or<br />
[https://aur.archlinux.org/packages/linux-grsec-lts/ linux-grsec-lts]<br />
<br />
Kernel linux-3.X.tar.xz and current patch-3.X.X.tar.xz also the .sign signature files for each.<br />
[https://www.kernel.org/pub/linux/kernel/v3.x/ kernel.org]<br />
<br />
Download the current grsecurity patch and Signatures<br />
[https://grsecurity.net/test.php grsecurity Test]<br />
Or<br />
[https://grsecurity.net/download_stable.php grsecurity Stable] for LTS kernel<br />
<br />
{{tip|The Grsecurity Test is in fact stable. The Stable Grsecurity version is just for the LTS}}<br />
<br />
=== Verify The GPG Signatures ===<br />
<br />
With the .sign files in the same directory as the file it is a a signature of, verify the signature like so...<br />
<br />
$ gpg2 --verify linux-3.10.tar.sign<br />
<br />
== Setup Build Environment ==<br />
<br />
Unpack the linux-grsec.tar.gz and copy all the files into it<br />
<br />
$ tar xzf linux-grsec.tar.gz<br />
$ cp ~/Downloads/linux-3.10.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/patch-3.10.9.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/grsecurity-2.9.1-3.10.9-201308202015.patch ~/linux-grsec<br />
<br />
Change into the build directory<br />
<br />
$ cd ~/linux-grsec<br />
<br />
== Build the Kernel Package ==<br />
<br />
It is going to take a long time to build the kernel because it is based on the default Arch kernel config with has about ten times as make modules enabled then your system actually needs. However, it is a known working config and to eliminate any more variables it is advisable to just live with the extra build time.<br />
<br />
Build the package<br />
<br />
$ MENUCONFIG=2 makepkg<br />
<br />
You should be dropped into the ncurses GUI now. Navigate to the grsecurity settings to verify the configuration and/or change things as needed. These setting can be found in {{ic|Security options ---> Grsecurity ---> Customize Configuration --->}}<br />
<br />
For both Desktops and Servers after you are sure you will not need to change any of the Grsecurity settings with sysctl, disable {{ic|Sysctl support}} found in {{ic|Sysctl Support}}.<br />
<br />
If this kernel is for a Server also enable {{ic|Disable privileged I/O}} found in {{ic|Memory Protections}}.<br />
<br />
All other setting should be optimal as they are, so now exit out of the ncurses GUI config and Save. Now the package should start to build. If all goes well you will have two .pkg.tar.xz packages one for the kernel and one for the kernel-headers.<br />
<br />
=== Make a Backup ===<br />
<br />
Keep all linux-grsec.tar.gz files along with the grsecruity patch and compiled packages in the Root users home folder. That way you can roll back if needed. Every time a new grsecurity patch is release you will not be able to download outdated patches every again.<br />
<br />
# mkdir /root/3.10.9<br />
# cp -r /home/USER/linux-grsec /root/3.10.9<br />
<br />
== Install PaX and RBAC Utilities ==<br />
<br />
The AUR also has [https://aur.archlinux.org/packages/paxctl/ paxctl], [https://aur.archlinux.org/packages/gradm/ gradm], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] packages that you will need.<br />
<br />
For simplicities sake I will assume you are using yaourt to install package form the AUR, however any other way of installing these packages will work as well.<br />
<br />
$ yaourt -S linux-pax-flags paxctl gradm<br />
<br />
== Set PaX Flags ==<br />
<br />
Use the linux-pax-flags program to configure all the PaX flags for troublesome programs.<br />
More information can be found in the Using linux-pax-flags AUR Package section.<br />
<br />
# linux-pax-flags<br />
<br />
== Install Hardened Kernel ==<br />
<br />
Now that all the needed utilities are installed and the system is configured for PaX, install the hardened kernel and headers.<br />
<br />
# pacman -U /root/3.10.9/*.pkg.tar.xz<br />
<br />
Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
You should now be in your hardened system. Just make sure to run {{ic|linux-pax-flags}} after every time you update your system or install a new program and you should have a trouble free experience.<br />
<br />
= Build Kernel without the AUR =<br />
<br />
Throughout this document we will talk about kernel configuration using the kernel variables like CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. These are the variables that the kernel build process uses to determine if a certain feature needs to be compiled.<br />
<br />
When you configure your kernel through make menuconfig or similar, you receive a user interface through which you can select the various kernel options. If you select the Help button at a certain kernel feature you will see at the top that it lists such a kernel variable.<br />
<br />
You can therefore still configure your kernel as you like - with a bit of thinking. And if you can't find a certain option, there's always the possibility to edit /usr/src/linux/.config by hand :)<br />
<br />
Of course, to be able to select the various grsecurity kernel options, you must enable grsecurity in your kernel.<br />
See [[default grsecurity kernel configuration]]<br />
<br />
== PaX ==<br />
<br />
=== Fighting the Exploitation of Software Bugs ===<br />
<br />
PaX introduces a couple of security mechanisms that make it harder for attackers to exploit software bugs that involve memory corruption (so do not treat PaX as if it protects against all possible software bugs). The PaX introduction document talks about three possible exploit techniques:<br />
<br />
# introduce/execute arbitrary code<br />
# execute existing code out of original program order<br />
# execute existing code in original program order with arbitrary data<br />
<br />
One prevention method disallows executable code to be stored in writable memory. When we look at a process, it requires five memory regions:<br />
<br />
# a data section which contains the statically allocated and global data<br />
# a BSS region (Block Started by Symbol) which contains information about the zero-initialized data of the process<br />
# a code region, also called the text segment, which contains the executable instructions<br />
# a heap which contains the dynamically allocated memory<br />
# a stack which contains the local variables<br />
<br />
The first PaX prevention method, called NOEXEC, is meant to give control over the runtime code generation. It marks memory pages that do not contain executable code as non-executable. This means that the heap and the stack, which only contain variable data and shouldn't contain executable code, are marked as non-executable. Exploits that place code in these areas with the intention of running it will fail.<br />
<br />
NOEXEC does more than this actually, interested readers should focus their attention to the [http://pax.grsecurity.net/docs/noexec.txt PaX NOEXEC documentation].<br />
<br />
The second PaX prevention method, called ASLR (Address Space Layout Randomization), randomize the addresses given to memory requests. Where previously memory was assigned contiguously (which means exploits know where the tasks' memory regions are situated) ASLR randomizes this allocation, rendering techniques that rely on this information useless.<br />
<br />
More information about ASLR can be found [http://pax.grsecurity.net/docs/aslr.txt online].<br />
<br />
=== PaX kernel configuration ===<br />
<br />
<br />
The recommended kernel setting for PaX is:<br />
<br />
#<br />
# Security options<br />
#<br />
#<br />
# PaX<br />
#<br />
CONFIG_PAX=y<br />
#<br />
# PaX Control<br />
#<br />
# CONFIG_PAX_SOFTMODE is not set<br />
CONFIG_PAX_EI_PAX=y<br />
CONFIG_PAX_PT_PAX_FLAGS=y<br />
CONFIG_PAX_NO_ACL_FLAGS=y<br />
# CONFIG_PAX_HAVE_ACL_FLAGS is not set<br />
# CONFIG_PAX_HOOK_ACL_FLAGS is not set<br />
#<br />
# Non-executable pages<br />
#<br />
CONFIG_PAX_NOEXEC=y<br />
CONFIG_PAX_PAGEEXEC=y<br />
CONFIG_PAX_SEGMEXEC=y<br />
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set<br />
CONFIG_PAX_DEFAULT_SEGMEXEC=y<br />
CONFIG_PAX_EMUTRAMP=y<br />
CONFIG_PAX_MPROTECT=y<br />
# CONFIG_PAX_NOELFRELOCS is not set<br />
#<br />
# Address Space Layout Randomization<br />
#<br />
CONFIG_PAX_ASLR=y<br />
CONFIG_PAX_RANDKSTACK=y<br />
CONFIG_PAX_RANDUSTACK=y<br />
CONFIG_PAX_RANDMMAP=y<br />
#<br />
# Miscellaneous hardening features<br />
#<br />
CONFIG_PAX_MEMORY_SANITIZE=y<br />
CONFIG_PAX_MEMORY_UDEREF=y<br />
CONFIG_KEYS=y<br />
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_NETWORK_XFRM=y<br />
CONFIG_SECURITY_CAPABILITIES=m<br />
CONFIG_SECURITY_ROOTPLUG=m<br />
<br />
If you are running a non-x86 system you will observe that there is no CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC instead as it is the only non-exec implementation around.<br />
<br />
=== Controlling PaX ===<br />
<br />
Not all Linux applications are happy with the PaX security restrictions. These tools include xorg-x11, java, mplayer, xmms and others. If you plan on using them you can elevate the protections for these applications using chpax and paxctl. You can find they on AUR.<br />
<br />
You can also use pax-utils, which is a small toolbox which contains useful applications to administrate a PaX aware server. Find it on AUR.<br />
<br />
Interesting tools include scanelf and pspax:<br />
<br />
* With scanelf you can scan over library and binary directories and list the various permissions and ELF types that pertain to running an ideal pax/grsec setup<br />
* With pspax you can display PaX flags/capabilities/xattr from the kernel's perspective<br />
<br />
=== Verifying the PaX Settings ===<br />
<br />
Peter Busser has written a regression test suite called paxtest. This tool will check various cases of possible attack vectors and inform you of the result. When you run it, it will leave a logfile called paxtest.log in the current working directory.<br />
<br />
# paxtest<br />
Executable anonymous mapping : Killed<br />
Executable bss : Killed<br />
Executable data : Killed<br />
Executable heap : Killed<br />
Executable stack : Killed<br />
Executable anonymous mapping (mprotect) : Killed<br />
Executable bss (mprotect) : Killed<br />
Executable data (mprotect) : Killed<br />
Executable heap (mprotect) : Killed<br />
Executable stack (mprotect) : Killed<br />
Executable shared library bss (mprotect) : Killed<br />
Executable shared library data (mprotect): Killed<br />
Writable text segments : Killed<br />
Anonymous mapping randomisation test : 16 bits (guessed)<br />
Heap randomisation test (ET_EXEC) : 13 bits (guessed)<br />
Heap randomisation test (ET_DYN) : 25 bits (guessed)<br />
Main executable randomisation (ET_EXEC) : 16 bits (guessed)<br />
Main executable randomisation (ET_DYN) : 17 bits (guessed)<br />
Shared library randomisation test : 16 bits (guessed)<br />
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)<br />
Stack randomisation test (PAGEEXEC) : No randomisation<br />
Return to function (strcpy) : Vulnerable<br />
Return to function (memcpy) : Vulnerable<br />
Return to function (strcpy, RANDEXEC) : Killed<br />
Return to function (memcpy, RANDEXEC) : Killed<br />
Executable shared library bss : Killed<br />
Executable shared library data : Killed<br />
<br />
In the above example run you notice that:<br />
<br />
* strcpy and memcpy are listed as Vulnerable. This is expected and normal - it is simply showing the need for a technology such as ProPolice/SSP<br />
* there is no randomization for PAGEEXEC. This is normal since our recommended x86 kernel configuration didn't activate the PAGEEXEC setting. However, on arches that support a true NX (non-executable) bit (most of them do, including x86_64), PAGEEXEC is the only method available for NOEXEC and has no performance hit.<br />
<br />
== Filesystem Protection ==<br />
<br />
=== Fighting Chroot and Filesystem Abuse ===<br />
<br />
Grsecurity2 includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on /proc usage, chrooting, linking, etc.<br />
<br />
=== Kernel Configuration ===<br />
<br />
We recommend the following grsecurity kernel configuration for filesystem protection:<br />
<br />
#<br />
# Filesystem Protections<br />
#<br />
CONFIG_GRKERNSEC_PROC=y<br />
# CONFIG_GRKERNSEC_PROC_USER is not set<br />
CONFIG_GRKERNSEC_PROC_USERGROUP=y<br />
CONFIG_GRKERNSEC_PROC_GID=3<br />
CONFIG_GRKERNSEC_PROC_ADD=y<br />
CONFIG_GRKERNSEC_LINK=y<br />
CONFIG_GRKERNSEC_FIFO=y<br />
CONFIG_GRKERNSEC_CHROOT=y<br />
CONFIG_GRKERNSEC_CHROOT_MOUNT=y<br />
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y<br />
CONFIG_GRKERNSEC_CHROOT_PIVOT=y<br />
CONFIG_GRKERNSEC_CHROOT_CHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_CHMOD=y<br />
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_MKNOD=y<br />
CONFIG_GRKERNSEC_CHROOT_SHMAT=y<br />
CONFIG_GRKERNSEC_CHROOT_UNIX=y<br />
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y<br />
CONFIG_GRKERNSEC_CHROOT_NICE=y<br />
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y<br />
CONFIG_GRKERNSEC_CHROOT_CAPS=y<br />
<br />
=== Triggering the Security Mechanism ===<br />
<br />
When you're using a kernel compiled with the above (or similar) settings, you will get the option to enable/disable many of the options through the /proc filesystem or via sysctl.<br />
<br />
The example below shows an excerpt of a typical /etc/sysctl.conf:<br />
<br />
kernel.grsecurity.chroot_deny_sysctl = 1<br />
kernel.grsecurity.chroot_caps = 1<br />
kernel.grsecurity.chroot_execlog = 0<br />
kernel.grsecurity.chroot_restrict_nice = 1<br />
kernel.grsecurity.chroot_deny_mknod = 1<br />
kernel.grsecurity.chroot_deny_chmod = 1<br />
kernel.grsecurity.chroot_enforce_chdir = 1<br />
kernel.grsecurity.chroot_deny_pivot = 1<br />
kernel.grsecurity.chroot_deny_chroot = 1<br />
kernel.grsecurity.chroot_deny_fchdir = 1<br />
kernel.grsecurity.chroot_deny_mount = 1<br />
kernel.grsecurity.chroot_deny_unix = 1<br />
kernel.grsecurity.chroot_deny_shmat = 1<br />
<br />
You can enable or disable settings at will using the sysctl command:<br />
<br />
(Toggling the exec_logging feature ON)<br />
# sysctl -w kernel.grsecurity.exec_logging = 1<br />
(Toggling the exec_logging feature OFF)<br />
# sysctl -w kernel.grsecurity.exec_logging = 0<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
== Kernel Auditing ==<br />
<br />
=== Extend your System's Logging Facilities ===<br />
<br />
grsecurity adds extra functionality to the kernel pertaining the logging. With grsecurity's Kernel Auditing the kernel informs you when applications are started, devices (un)mounted, etc.<br />
<br />
=== The various Kernel Audit Settings ===<br />
<br />
The following kernel configuration section can be used to enable grsecurity's Kernel Audit Settings:<br />
<br />
#<br />
# Kernel Auditing<br />
#<br />
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set<br />
CONFIG_GRKERNSEC_EXECLOG=y<br />
CONFIG_GRKERNSEC_RESLOG=y<br />
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y<br />
CONFIG_GRKERNSEC_AUDIT_CHDIR=y<br />
CONFIG_GRKERNSEC_AUDIT_MOUNT=y<br />
CONFIG_GRKERNSEC_AUDIT_IPC=y<br />
CONFIG_GRKERNSEC_SIGNAL=y<br />
CONFIG_GRKERNSEC_FORKFAIL=y<br />
CONFIG_GRKERNSEC_TIME=y<br />
CONFIG_GRKERNSEC_PROC_IPADDR=y<br />
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y<br />
<br />
== Process Restrictions ==<br />
<br />
=== Executable Protection ===<br />
<br />
With grsecurity you can restrict executables. Since most exploits work through one or more running processes this protection can save your system's health.<br />
<br />
=== Network Protection ===<br />
<br />
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity includes randomization patches to counter these attacks. Apart from these you can also enable socket restrictions, disallowing certain groups network access alltogether.<br />
<br />
=== Kernel Settings ===<br />
<br />
The following kernel settings enable various executable and network protections:<br />
<br />
#<br />
# Executable Protections<br />
#<br />
CONFIG_GRKERNSEC_EXECVE=y<br />
CONFIG_GRKERNSEC_DMESG=y<br />
CONFIG_GRKERNSEC_RANDPID=y<br />
CONFIG_GRKERNSEC_TPE=y<br />
CONFIG_GRKERNSEC_TPE_ALL=y<br />
CONFIG_GRKERNSEC_TPE_GID=100<br />
<br />
#<br />
# Network Protections<br />
#<br />
CONFIG_GRKERNSEC_RANDNET=y<br />
CONFIG_GRKERNSEC_RANDISN=y<br />
CONFIG_GRKERNSEC_RANDID=y<br />
CONFIG_GRKERNSEC_RANDSRC=y<br />
CONFIG_GRKERNSEC_RANDRPC=y<br />
# CONFIG_GRKERNSEC_SOCKET is not set<br />
<br />
= RBAC =<br />
<br />
Role Based Access Control<br />
<br />
There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.<br />
<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
== Configuring the Kernel ==<br />
<br />
The recommended kernel setting for RBAC is:<br />
<br />
#<br />
# Role Based Access Control Options<br />
#<br />
CONFIG_GRKERNSEC_ACL_HIDEKERN=y<br />
CONFIG_GRKERNSEC_ACL_MAXTRIES=3<br />
CONFIG_GRKERNSEC_ACL_TIMEOUT=30<br />
<br />
== Working with gradm ==<br />
<br />
gradm is a tool which allows you to administer and maintain a policy for your system. With it, you can enable or disable the RBAC system, reload the RBAC roles, change your role, set a password for admin mode, etc.<br />
<br />
When you install gradm a default policy will be installed in /etc/grsec/policy. Please see in AUR for gradm package.<br />
<br />
By default, the RBAC policies are not activated. It is the sysadmin's job to determine when the system should have an RBAC policy enforced. Before activating the RBAC system you should set an admin password.<br />
<br />
# gradm -P admin<br />
Setting up grsecurity RBAC password<br />
Password: (Enter a well-chosen password)<br />
Re-enter Password: (Enter the same password for confirmation)<br />
Password written in /etc/grsec/pw<br />
# gradm -E<br />
<br />
To disable the RBAC system, run gradm -D. If you are not allowed to, you first need to switch to the admin role:<br />
<br />
# gradm -a admin<br />
Password: (Enter your admin role password)<br />
# gradm -D<br />
<br />
If you want to leave the admin role, run gradm -u admin:<br />
<br />
# gradm -u admin<br />
<br />
== Generating a Policy ==<br />
<br />
The RBAC system comes with a great feature called "learning mode". The learning mode can generate an anticipatory least privilege policy for your system. This allows for time and money savings by being able to rapidly deploy multiple secure servers.<br />
<br />
To use the learning mode, activate it using gradm:<br />
<br />
# gradm -F -L /etc/grsec/learning.log<br />
<br />
Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate or any other heavy file i/o operation as this can really slow down the processing time.<br />
<br />
When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under {{ic|/etc/grsec/learning.roles}}:<br />
<br />
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles<br />
<br />
Audit the {{ic|/etc/grsec/learning.roles}} and save it as {{ic|/etc/grsec/policy}} (mode {{ic|0600}}) when you are finished.<br />
<br />
# mv /etc/grsec/learning.roles /etc/grsec/policy<br />
# chmod 0600 /etc/grsec/policy<br />
<br />
You will now be able to enable the RBAC system with your new learned policy.<br />
<br />
== Tweaking your Policy ==<br />
<br />
An interesting feature of grsecurity 2.x is Set Operation Support for the configuration file. Currently it supports unions, intersections and differences of sets (of objects in this case).<br />
<br />
define objset1 {<br />
/root/blah rw<br />
/root/blah2 r<br />
/root/blah3 x<br />
}<br />
<br />
define somename2 {<br />
/root/test1 rw<br />
/root/blah2 rw<br />
/root/test3 h<br />
}<br />
<br />
Here is an example of its use, and the resulting objects that will be added to your subject:<br />
<br />
subject /somebinary o<br />
$objset1 & $somename2<br />
<br />
The above would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah2 r<br />
<br />
This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.<br />
<br />
subject /somebinary o<br />
$objset1 | $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 rw<br />
/root/blah3 x<br />
/root/test1 rw<br />
/root/test3 h<br />
<br />
This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.<br />
<br />
subject /somebinary o<br />
$objset1 - $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 h<br />
/root/blah3 x<br />
<br />
This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.<br />
<br />
In some obscure pseudo-language you could see this as:<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained /tmp/blah r) )<br />
then<br />
$objset1 - $objset2 would contain /tmp/blah w<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained / rwx) )<br />
then <br />
$objset1 - $objset2 would contain /tmp/blah h<br />
<br />
As for order of precedence (from highest to lowest): "-, & |".<br />
<br />
If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:<br />
<br />
(($set1 - $set2) | $set3) & $set4<br />
<br />
= Using linux-pax-flags AUR Package =<br />
<br />
The linux-pax-flags program is what makes using PaX on Arch Linux easy as pie. When you run this program it will set the PaX flags for all the problematic programs for you. However, if you use some uncommon program it may have problems forcing you to set the paxctl flags yourself. You will most likely see something like {{ic|Denied RWX}} in journalctl. That means you will need to disable MPROTECT for the program {{ic|paxctl -cPEmRXS /usr/bin/bla}}<br />
<br />
After you find what PaX flags need to be set post a comment on the linux-pax-flags AUR package so it can be added.<br />
<br />
More extensive documentation of the linux-pax-flags utility is to be found on it's man page.<br />
<br />
= Tips and Tricks =<br />
<br />
Because you will not be able to change the PaX flags for a running program, and that the vast majority of programs which would need them are graphical, it is strongly advisable to not use a Graphical Login like GDM or KDM. Instead simply have the system drop you to a console to log in and use {{ic|startx}}. Then you will have a chance to set the PaX flags before anything starts. For the same reasons it is strongly advisable to update your system and run {{ic|linux-pax-flags}} right after boot, before running {{ic|startx}}.<br />
<br />
Grsecurity will harden /proc and /sys so your normal user will no longer be able to see the network status, becuase of this non of your desktop network monitors will work. Instead just install terminal based monitoring programs, such as [https://www.archlinux.org/packages/community/x86_64/nmon/ nmon] or [https://www.archlinux.org/packages/community/x86_64/nload/ nload] and run them as root, or as a user in the proc-trusted group.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Grsecurity&diff=272415Grsecurity2013-08-25T01:21:12Z<p>Hunterthomson: /* Manual Kernel Configuration */ Changed title to make is more clear</p>
<hr />
<div>[[Category:Kernel]][[Category:Security]]<br />
The grsecurity project, hosted on https://grsecurity.net, provides various patches to the Linux kernel which enhance your system's overall security. grsecurity also ships with PaX which provides the most advanced memory protections of any OS. PaX invented ALSR and shows that it is only the tip of the iceberg. The RBAC Mandatory Access Control system of grsecurity was the inspriation for SELinux and AppArmor.<br />
<br />
In short, a Linux kernel hardened with grsecurity is the most hardened kernel you could have. Not even OpenBSD has all the hardening features it provides. A comprehensive list is maintained on the [http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options grsecurity features page] itself. However, the grsecurity Wiki is often out-of-date. The best way is to simply read the help text in the kernel config.<br />
<br />
Arch has all the utilities and kernel packages you need to run a grsecurity hardened Arch Linux system in the AUR. Arch even has a script called [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] which will make using PaX as painless as possible by setting all of the PaX flags for you.<br />
<br />
You can install the kernel either from a binary repository or - if you want more control - manually from the AUR.<br />
<br />
= Install from binary packages =<br />
<br />
Add the [http://arsch.orgizm.net/ Arsch Arch Linux Repository] to your package sources and install the kernel with {{ic|pacman -Sy linux-grsec}} (or the PaX only kernel with {{ic|pacman -Sy linux-pax}}). Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
= Setup and Install from AUR =<br />
<br />
To build the AUR package we will follow this general game plan. First, download all needed files and check GPG signatures. Second, configure kernel and compile. Third, copy a backup of these files to the Root users home folder. Forth, install utilities needed for PaX and RBAC. Fifth, install the kernel package. Sixth, run linux-pax-flags to poke security holes in applications that will not run without them. Finally, reboot into your hardened system.<br />
<br />
== Download Files ==<br />
<br />
Download the packages<br />
[https://aur.archlinux.org/packages/linux-grsec/ linux-grsec]<br />
Or<br />
[https://aur.archlinux.org/packages/linux-grsec-lts/ linux-grsec-lts]<br />
<br />
Kernel linux-3.X.tar.xz and current patch-3.X.X.tar.xz also the .sign signature files for each.<br />
[https://www.kernel.org/pub/linux/kernel/v3.x/ kernel.org]<br />
<br />
Download the current grsecurity patch and Signatures<br />
[https://grsecurity.net/test.php grsecurity Test]<br />
Or<br />
[https://grsecurity.net/download_stable.php grsecurity Stable] for LTS kernel<br />
<br />
{{tip|The Grsecurity Test is in fact stable. The Stable Grsecurity version is just for the LTS}}<br />
<br />
=== Verify The GPG Signatures ===<br />
<br />
With the .sign files in the same directory as the file it is a a signature of, verify the signature like so...<br />
<br />
$ gpg2 --verify linux-3.10.tar.sign<br />
<br />
== Setup Build Environment ==<br />
<br />
Unpack the linux-grsec.tar.gz and copy all the files into it<br />
<br />
$ tar xzf linux-grsec.tar.gz<br />
$ cp ~/Downloads/linux-3.10.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/patch-3.10.9.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/grsecurity-2.9.1-3.10.9-201308202015.patch ~/linux-grsec<br />
<br />
Change into the build directory<br />
<br />
$ cd ~/linux-grsec<br />
<br />
== Build the Kernel Package ==<br />
<br />
It is going to take a long time to build the kernel because it is based on the default Arch kernel config with has about ten times as make modules enabled then your system actually needs. However, it is a known working config and to eliminate any more variables it is advisable to just live with the extra build time.<br />
<br />
Build the package<br />
<br />
$ MENUCONFIG=2 makepkg<br />
<br />
You should be dropped into the ncurses GUI now. Navigate to the grsecurity settings to verify the configuration and/or change things as needed. These setting can be found in {{ic|Security options ---> Grsecurity ---> Customize Configuration --->}}<br />
<br />
For both Desktops and Servers after you are sure you will not need to change any of the Grsecurity settings with sysctl, disable {{ic|Sysctl support}} found in {{ic|Sysctl Support}}.<br />
<br />
If this kernel is for a Server also enable {{ic|Disable privileged I/O}} found in {{ic|Memory Protections}}.<br />
<br />
All other setting should be optimal as they are, so now exit out of the ncurses GUI config and Save. Now the package should start to build. If all goes well you will have two .pkg.tar.xz packages one for the kernel and one for the kernel-headers.<br />
<br />
=== Make a Backup ===<br />
<br />
Keep all linux-grsec.tar.gz files along with the grsecruity patch and compiled packages in the Root users home folder. That way you can roll back if needed. Every time a new grsecurity patch is release you will not be able to download outdated patches every again.<br />
<br />
# mkdir /root/3.10.9<br />
# cp -r /home/USER/linux-grsec /root/3.10.9<br />
<br />
== Install PaX and RBAC Utilities ==<br />
<br />
The AUR also has [https://aur.archlinux.org/packages/paxctl/ paxctl], [https://aur.archlinux.org/packages/gradm/ gradm], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] packages that you will need.<br />
<br />
For simplicities sake I will assume you are using yaourt to install package form the AUR, however any other way of installing these packages will work as well.<br />
<br />
$ yaourt -S linux-pax-flags paxctl gradm<br />
<br />
== Set PaX Flags ==<br />
<br />
Use the linux-pax-flags program to configure all the PaX flags for troublesome programs.<br />
More information can be found in the Using linux-pax-flags AUR Package section.<br />
<br />
# linux-pax-flags<br />
<br />
== Install Hardened Kernel ==<br />
<br />
Now that all the needed utilities are installed and the system is configured for PaX, install the hardened kernel and headers.<br />
<br />
# pacman -U /root/3.10.9/*.pkg.tar.xz<br />
<br />
Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
You should now be in your hardened system. Just make sure to run {{ic|linux-pax-flags}} after every time you update your system or install a new program and you should have a trouble free experience.<br />
<br />
= Setup and Build Kernel without the AUR =<br />
<br />
Throughout this document we will talk about kernel configuration using the kernel variables like CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. These are the variables that the kernel build process uses to determine if a certain feature needs to be compiled.<br />
<br />
When you configure your kernel through make menuconfig or similar, you receive a user interface through which you can select the various kernel options. If you select the Help button at a certain kernel feature you will see at the top that it lists such a kernel variable.<br />
<br />
You can therefore still configure your kernel as you like - with a bit of thinking. And if you can't find a certain option, there's always the possibility to edit /usr/src/linux/.config by hand :)<br />
<br />
Of course, to be able to select the various grsecurity kernel options, you must enable grsecurity in your kernel.<br />
See [[default grsecurity kernel configuration]]<br />
<br />
== PaX ==<br />
<br />
=== Fighting the Exploitation of Software Bugs ===<br />
<br />
PaX introduces a couple of security mechanisms that make it harder for attackers to exploit software bugs that involve memory corruption (so do not treat PaX as if it protects against all possible software bugs). The PaX introduction document talks about three possible exploit techniques:<br />
<br />
# introduce/execute arbitrary code<br />
# execute existing code out of original program order<br />
# execute existing code in original program order with arbitrary data<br />
<br />
One prevention method disallows executable code to be stored in writable memory. When we look at a process, it requires five memory regions:<br />
<br />
# a data section which contains the statically allocated and global data<br />
# a BSS region (Block Started by Symbol) which contains information about the zero-initialized data of the process<br />
# a code region, also called the text segment, which contains the executable instructions<br />
# a heap which contains the dynamically allocated memory<br />
# a stack which contains the local variables<br />
<br />
The first PaX prevention method, called NOEXEC, is meant to give control over the runtime code generation. It marks memory pages that do not contain executable code as non-executable. This means that the heap and the stack, which only contain variable data and shouldn't contain executable code, are marked as non-executable. Exploits that place code in these areas with the intention of running it will fail.<br />
<br />
NOEXEC does more than this actually, interested readers should focus their attention to the [http://pax.grsecurity.net/docs/noexec.txt PaX NOEXEC documentation].<br />
<br />
The second PaX prevention method, called ASLR (Address Space Layout Randomization), randomize the addresses given to memory requests. Where previously memory was assigned contiguously (which means exploits know where the tasks' memory regions are situated) ASLR randomizes this allocation, rendering techniques that rely on this information useless.<br />
<br />
More information about ASLR can be found [http://pax.grsecurity.net/docs/aslr.txt online].<br />
<br />
=== PaX kernel configuration ===<br />
<br />
<br />
The recommended kernel setting for PaX is:<br />
<br />
#<br />
# Security options<br />
#<br />
#<br />
# PaX<br />
#<br />
CONFIG_PAX=y<br />
#<br />
# PaX Control<br />
#<br />
# CONFIG_PAX_SOFTMODE is not set<br />
CONFIG_PAX_EI_PAX=y<br />
CONFIG_PAX_PT_PAX_FLAGS=y<br />
CONFIG_PAX_NO_ACL_FLAGS=y<br />
# CONFIG_PAX_HAVE_ACL_FLAGS is not set<br />
# CONFIG_PAX_HOOK_ACL_FLAGS is not set<br />
#<br />
# Non-executable pages<br />
#<br />
CONFIG_PAX_NOEXEC=y<br />
CONFIG_PAX_PAGEEXEC=y<br />
CONFIG_PAX_SEGMEXEC=y<br />
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set<br />
CONFIG_PAX_DEFAULT_SEGMEXEC=y<br />
CONFIG_PAX_EMUTRAMP=y<br />
CONFIG_PAX_MPROTECT=y<br />
# CONFIG_PAX_NOELFRELOCS is not set<br />
#<br />
# Address Space Layout Randomization<br />
#<br />
CONFIG_PAX_ASLR=y<br />
CONFIG_PAX_RANDKSTACK=y<br />
CONFIG_PAX_RANDUSTACK=y<br />
CONFIG_PAX_RANDMMAP=y<br />
#<br />
# Miscellaneous hardening features<br />
#<br />
CONFIG_PAX_MEMORY_SANITIZE=y<br />
CONFIG_PAX_MEMORY_UDEREF=y<br />
CONFIG_KEYS=y<br />
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_NETWORK_XFRM=y<br />
CONFIG_SECURITY_CAPABILITIES=m<br />
CONFIG_SECURITY_ROOTPLUG=m<br />
<br />
If you are running a non-x86 system you will observe that there is no CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC instead as it is the only non-exec implementation around.<br />
<br />
=== Controlling PaX ===<br />
<br />
Not all Linux applications are happy with the PaX security restrictions. These tools include xorg-x11, java, mplayer, xmms and others. If you plan on using them you can elevate the protections for these applications using chpax and paxctl. You can find they on AUR.<br />
<br />
You can also use pax-utils, which is a small toolbox which contains useful applications to administrate a PaX aware server. Find it on AUR.<br />
<br />
Interesting tools include scanelf and pspax:<br />
<br />
* With scanelf you can scan over library and binary directories and list the various permissions and ELF types that pertain to running an ideal pax/grsec setup<br />
* With pspax you can display PaX flags/capabilities/xattr from the kernel's perspective<br />
<br />
=== Verifying the PaX Settings ===<br />
<br />
Peter Busser has written a regression test suite called paxtest. This tool will check various cases of possible attack vectors and inform you of the result. When you run it, it will leave a logfile called paxtest.log in the current working directory.<br />
<br />
# paxtest<br />
Executable anonymous mapping : Killed<br />
Executable bss : Killed<br />
Executable data : Killed<br />
Executable heap : Killed<br />
Executable stack : Killed<br />
Executable anonymous mapping (mprotect) : Killed<br />
Executable bss (mprotect) : Killed<br />
Executable data (mprotect) : Killed<br />
Executable heap (mprotect) : Killed<br />
Executable stack (mprotect) : Killed<br />
Executable shared library bss (mprotect) : Killed<br />
Executable shared library data (mprotect): Killed<br />
Writable text segments : Killed<br />
Anonymous mapping randomisation test : 16 bits (guessed)<br />
Heap randomisation test (ET_EXEC) : 13 bits (guessed)<br />
Heap randomisation test (ET_DYN) : 25 bits (guessed)<br />
Main executable randomisation (ET_EXEC) : 16 bits (guessed)<br />
Main executable randomisation (ET_DYN) : 17 bits (guessed)<br />
Shared library randomisation test : 16 bits (guessed)<br />
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)<br />
Stack randomisation test (PAGEEXEC) : No randomisation<br />
Return to function (strcpy) : Vulnerable<br />
Return to function (memcpy) : Vulnerable<br />
Return to function (strcpy, RANDEXEC) : Killed<br />
Return to function (memcpy, RANDEXEC) : Killed<br />
Executable shared library bss : Killed<br />
Executable shared library data : Killed<br />
<br />
In the above example run you notice that:<br />
<br />
* strcpy and memcpy are listed as Vulnerable. This is expected and normal - it is simply showing the need for a technology such as ProPolice/SSP<br />
* there is no randomization for PAGEEXEC. This is normal since our recommended x86 kernel configuration didn't activate the PAGEEXEC setting. However, on arches that support a true NX (non-executable) bit (most of them do, including x86_64), PAGEEXEC is the only method available for NOEXEC and has no performance hit.<br />
<br />
== Filesystem Protection ==<br />
<br />
=== Fighting Chroot and Filesystem Abuse ===<br />
<br />
Grsecurity2 includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on /proc usage, chrooting, linking, etc.<br />
<br />
=== Kernel Configuration ===<br />
<br />
We recommend the following grsecurity kernel configuration for filesystem protection:<br />
<br />
#<br />
# Filesystem Protections<br />
#<br />
CONFIG_GRKERNSEC_PROC=y<br />
# CONFIG_GRKERNSEC_PROC_USER is not set<br />
CONFIG_GRKERNSEC_PROC_USERGROUP=y<br />
CONFIG_GRKERNSEC_PROC_GID=3<br />
CONFIG_GRKERNSEC_PROC_ADD=y<br />
CONFIG_GRKERNSEC_LINK=y<br />
CONFIG_GRKERNSEC_FIFO=y<br />
CONFIG_GRKERNSEC_CHROOT=y<br />
CONFIG_GRKERNSEC_CHROOT_MOUNT=y<br />
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y<br />
CONFIG_GRKERNSEC_CHROOT_PIVOT=y<br />
CONFIG_GRKERNSEC_CHROOT_CHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_CHMOD=y<br />
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_MKNOD=y<br />
CONFIG_GRKERNSEC_CHROOT_SHMAT=y<br />
CONFIG_GRKERNSEC_CHROOT_UNIX=y<br />
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y<br />
CONFIG_GRKERNSEC_CHROOT_NICE=y<br />
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y<br />
CONFIG_GRKERNSEC_CHROOT_CAPS=y<br />
<br />
=== Triggering the Security Mechanism ===<br />
<br />
When you're using a kernel compiled with the above (or similar) settings, you will get the option to enable/disable many of the options through the /proc filesystem or via sysctl.<br />
<br />
The example below shows an excerpt of a typical /etc/sysctl.conf:<br />
<br />
kernel.grsecurity.chroot_deny_sysctl = 1<br />
kernel.grsecurity.chroot_caps = 1<br />
kernel.grsecurity.chroot_execlog = 0<br />
kernel.grsecurity.chroot_restrict_nice = 1<br />
kernel.grsecurity.chroot_deny_mknod = 1<br />
kernel.grsecurity.chroot_deny_chmod = 1<br />
kernel.grsecurity.chroot_enforce_chdir = 1<br />
kernel.grsecurity.chroot_deny_pivot = 1<br />
kernel.grsecurity.chroot_deny_chroot = 1<br />
kernel.grsecurity.chroot_deny_fchdir = 1<br />
kernel.grsecurity.chroot_deny_mount = 1<br />
kernel.grsecurity.chroot_deny_unix = 1<br />
kernel.grsecurity.chroot_deny_shmat = 1<br />
<br />
You can enable or disable settings at will using the sysctl command:<br />
<br />
(Toggling the exec_logging feature ON)<br />
# sysctl -w kernel.grsecurity.exec_logging = 1<br />
(Toggling the exec_logging feature OFF)<br />
# sysctl -w kernel.grsecurity.exec_logging = 0<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
== Kernel Auditing ==<br />
<br />
=== Extend your System's Logging Facilities ===<br />
<br />
grsecurity adds extra functionality to the kernel pertaining the logging. With grsecurity's Kernel Auditing the kernel informs you when applications are started, devices (un)mounted, etc.<br />
<br />
=== The various Kernel Audit Settings ===<br />
<br />
The following kernel configuration section can be used to enable grsecurity's Kernel Audit Settings:<br />
<br />
#<br />
# Kernel Auditing<br />
#<br />
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set<br />
CONFIG_GRKERNSEC_EXECLOG=y<br />
CONFIG_GRKERNSEC_RESLOG=y<br />
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y<br />
CONFIG_GRKERNSEC_AUDIT_CHDIR=y<br />
CONFIG_GRKERNSEC_AUDIT_MOUNT=y<br />
CONFIG_GRKERNSEC_AUDIT_IPC=y<br />
CONFIG_GRKERNSEC_SIGNAL=y<br />
CONFIG_GRKERNSEC_FORKFAIL=y<br />
CONFIG_GRKERNSEC_TIME=y<br />
CONFIG_GRKERNSEC_PROC_IPADDR=y<br />
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y<br />
<br />
== Process Restrictions ==<br />
<br />
=== Executable Protection ===<br />
<br />
With grsecurity you can restrict executables. Since most exploits work through one or more running processes this protection can save your system's health.<br />
<br />
=== Network Protection ===<br />
<br />
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity includes randomization patches to counter these attacks. Apart from these you can also enable socket restrictions, disallowing certain groups network access alltogether.<br />
<br />
=== Kernel Settings ===<br />
<br />
The following kernel settings enable various executable and network protections:<br />
<br />
#<br />
# Executable Protections<br />
#<br />
CONFIG_GRKERNSEC_EXECVE=y<br />
CONFIG_GRKERNSEC_DMESG=y<br />
CONFIG_GRKERNSEC_RANDPID=y<br />
CONFIG_GRKERNSEC_TPE=y<br />
CONFIG_GRKERNSEC_TPE_ALL=y<br />
CONFIG_GRKERNSEC_TPE_GID=100<br />
<br />
#<br />
# Network Protections<br />
#<br />
CONFIG_GRKERNSEC_RANDNET=y<br />
CONFIG_GRKERNSEC_RANDISN=y<br />
CONFIG_GRKERNSEC_RANDID=y<br />
CONFIG_GRKERNSEC_RANDSRC=y<br />
CONFIG_GRKERNSEC_RANDRPC=y<br />
# CONFIG_GRKERNSEC_SOCKET is not set<br />
<br />
= RBAC =<br />
<br />
Role Based Access Control<br />
<br />
There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.<br />
<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
== Configuring the Kernel ==<br />
<br />
The recommended kernel setting for RBAC is:<br />
<br />
#<br />
# Role Based Access Control Options<br />
#<br />
CONFIG_GRKERNSEC_ACL_HIDEKERN=y<br />
CONFIG_GRKERNSEC_ACL_MAXTRIES=3<br />
CONFIG_GRKERNSEC_ACL_TIMEOUT=30<br />
<br />
== Working with gradm ==<br />
<br />
gradm is a tool which allows you to administer and maintain a policy for your system. With it, you can enable or disable the RBAC system, reload the RBAC roles, change your role, set a password for admin mode, etc.<br />
<br />
When you install gradm a default policy will be installed in /etc/grsec/policy. Please see in AUR for gradm package.<br />
<br />
By default, the RBAC policies are not activated. It is the sysadmin's job to determine when the system should have an RBAC policy enforced. Before activating the RBAC system you should set an admin password.<br />
<br />
# gradm -P admin<br />
Setting up grsecurity RBAC password<br />
Password: (Enter a well-chosen password)<br />
Re-enter Password: (Enter the same password for confirmation)<br />
Password written in /etc/grsec/pw<br />
# gradm -E<br />
<br />
To disable the RBAC system, run gradm -D. If you are not allowed to, you first need to switch to the admin role:<br />
<br />
# gradm -a admin<br />
Password: (Enter your admin role password)<br />
# gradm -D<br />
<br />
If you want to leave the admin role, run gradm -u admin:<br />
<br />
# gradm -u admin<br />
<br />
== Generating a Policy ==<br />
<br />
The RBAC system comes with a great feature called "learning mode". The learning mode can generate an anticipatory least privilege policy for your system. This allows for time and money savings by being able to rapidly deploy multiple secure servers.<br />
<br />
To use the learning mode, activate it using gradm:<br />
<br />
# gradm -F -L /etc/grsec/learning.log<br />
<br />
Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate or any other heavy file i/o operation as this can really slow down the processing time.<br />
<br />
When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under {{ic|/etc/grsec/learning.roles}}:<br />
<br />
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles<br />
<br />
Audit the {{ic|/etc/grsec/learning.roles}} and save it as {{ic|/etc/grsec/policy}} (mode {{ic|0600}}) when you are finished.<br />
<br />
# mv /etc/grsec/learning.roles /etc/grsec/policy<br />
# chmod 0600 /etc/grsec/policy<br />
<br />
You will now be able to enable the RBAC system with your new learned policy.<br />
<br />
== Tweaking your Policy ==<br />
<br />
An interesting feature of grsecurity 2.x is Set Operation Support for the configuration file. Currently it supports unions, intersections and differences of sets (of objects in this case).<br />
<br />
define objset1 {<br />
/root/blah rw<br />
/root/blah2 r<br />
/root/blah3 x<br />
}<br />
<br />
define somename2 {<br />
/root/test1 rw<br />
/root/blah2 rw<br />
/root/test3 h<br />
}<br />
<br />
Here is an example of its use, and the resulting objects that will be added to your subject:<br />
<br />
subject /somebinary o<br />
$objset1 & $somename2<br />
<br />
The above would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah2 r<br />
<br />
This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.<br />
<br />
subject /somebinary o<br />
$objset1 | $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 rw<br />
/root/blah3 x<br />
/root/test1 rw<br />
/root/test3 h<br />
<br />
This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.<br />
<br />
subject /somebinary o<br />
$objset1 - $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 h<br />
/root/blah3 x<br />
<br />
This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.<br />
<br />
In some obscure pseudo-language you could see this as:<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained /tmp/blah r) )<br />
then<br />
$objset1 - $objset2 would contain /tmp/blah w<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained / rwx) )<br />
then <br />
$objset1 - $objset2 would contain /tmp/blah h<br />
<br />
As for order of precedence (from highest to lowest): "-, & |".<br />
<br />
If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:<br />
<br />
(($set1 - $set2) | $set3) & $set4<br />
<br />
= Using linux-pax-flags AUR Package =<br />
<br />
The linux-pax-flags program is what makes using PaX on Arch Linux easy as pie. When you run this program it will set the PaX flags for all the problematic programs for you. However, if you use some uncommon program it may have problems forcing you to set the paxctl flags yourself. You will most likely see something like {{ic|Denied RWX}} in journalctl. That means you will need to disable MPROTECT for the program {{ic|paxctl -cPEmRXS /usr/bin/bla}}<br />
<br />
After you find what PaX flags need to be set post a comment on the linux-pax-flags AUR package so it can be added.<br />
<br />
More extensive documentation of the linux-pax-flags utility is to be found on it's man page.<br />
<br />
= Tips and Tricks =<br />
<br />
Because you will not be able to change the PaX flags for a running program, and that the vast majority of programs which would need them are graphical, it is strongly advisable to not use a Graphical Login like GDM or KDM. Instead simply have the system drop you to a console to log in and use {{ic|startx}}. Then you will have a chance to set the PaX flags before anything starts. For the same reasons it is strongly advisable to update your system and run {{ic|linux-pax-flags}} right after boot, before running {{ic|startx}}.<br />
<br />
Grsecurity will harden /proc and /sys so your normal user will no longer be able to see the network status, becuase of this non of your desktop network monitors will work. Instead just install terminal based monitoring programs, such as [https://www.archlinux.org/packages/community/x86_64/nmon/ nmon] or [https://www.archlinux.org/packages/community/x86_64/nload/ nload] and run them as root, or as a user in the proc-trusted group.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Grsecurity&diff=272414Grsecurity2013-08-25T01:20:10Z<p>Hunterthomson: /* Install binary packages */ Changed title to make it more noticeable that it is a different option then building the AUR</p>
<hr />
<div>[[Category:Kernel]][[Category:Security]]<br />
The grsecurity project, hosted on https://grsecurity.net, provides various patches to the Linux kernel which enhance your system's overall security. grsecurity also ships with PaX which provides the most advanced memory protections of any OS. PaX invented ALSR and shows that it is only the tip of the iceberg. The RBAC Mandatory Access Control system of grsecurity was the inspriation for SELinux and AppArmor.<br />
<br />
In short, a Linux kernel hardened with grsecurity is the most hardened kernel you could have. Not even OpenBSD has all the hardening features it provides. A comprehensive list is maintained on the [http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options grsecurity features page] itself. However, the grsecurity Wiki is often out-of-date. The best way is to simply read the help text in the kernel config.<br />
<br />
Arch has all the utilities and kernel packages you need to run a grsecurity hardened Arch Linux system in the AUR. Arch even has a script called [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] which will make using PaX as painless as possible by setting all of the PaX flags for you.<br />
<br />
You can install the kernel either from a binary repository or - if you want more control - manually from the AUR.<br />
<br />
= Install from binary packages =<br />
<br />
Add the [http://arsch.orgizm.net/ Arsch Arch Linux Repository] to your package sources and install the kernel with {{ic|pacman -Sy linux-grsec}} (or the PaX only kernel with {{ic|pacman -Sy linux-pax}}). Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
= Setup and Install from AUR =<br />
<br />
To build the AUR package we will follow this general game plan. First, download all needed files and check GPG signatures. Second, configure kernel and compile. Third, copy a backup of these files to the Root users home folder. Forth, install utilities needed for PaX and RBAC. Fifth, install the kernel package. Sixth, run linux-pax-flags to poke security holes in applications that will not run without them. Finally, reboot into your hardened system.<br />
<br />
== Download Files ==<br />
<br />
Download the packages<br />
[https://aur.archlinux.org/packages/linux-grsec/ linux-grsec]<br />
Or<br />
[https://aur.archlinux.org/packages/linux-grsec-lts/ linux-grsec-lts]<br />
<br />
Kernel linux-3.X.tar.xz and current patch-3.X.X.tar.xz also the .sign signature files for each.<br />
[https://www.kernel.org/pub/linux/kernel/v3.x/ kernel.org]<br />
<br />
Download the current grsecurity patch and Signatures<br />
[https://grsecurity.net/test.php grsecurity Test]<br />
Or<br />
[https://grsecurity.net/download_stable.php grsecurity Stable] for LTS kernel<br />
<br />
{{tip|The Grsecurity Test is in fact stable. The Stable Grsecurity version is just for the LTS}}<br />
<br />
=== Verify The GPG Signatures ===<br />
<br />
With the .sign files in the same directory as the file it is a a signature of, verify the signature like so...<br />
<br />
$ gpg2 --verify linux-3.10.tar.sign<br />
<br />
== Setup Build Environment ==<br />
<br />
Unpack the linux-grsec.tar.gz and copy all the files into it<br />
<br />
$ tar xzf linux-grsec.tar.gz<br />
$ cp ~/Downloads/linux-3.10.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/patch-3.10.9.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/grsecurity-2.9.1-3.10.9-201308202015.patch ~/linux-grsec<br />
<br />
Change into the build directory<br />
<br />
$ cd ~/linux-grsec<br />
<br />
== Build the Kernel Package ==<br />
<br />
It is going to take a long time to build the kernel because it is based on the default Arch kernel config with has about ten times as make modules enabled then your system actually needs. However, it is a known working config and to eliminate any more variables it is advisable to just live with the extra build time.<br />
<br />
Build the package<br />
<br />
$ MENUCONFIG=2 makepkg<br />
<br />
You should be dropped into the ncurses GUI now. Navigate to the grsecurity settings to verify the configuration and/or change things as needed. These setting can be found in {{ic|Security options ---> Grsecurity ---> Customize Configuration --->}}<br />
<br />
For both Desktops and Servers after you are sure you will not need to change any of the Grsecurity settings with sysctl, disable {{ic|Sysctl support}} found in {{ic|Sysctl Support}}.<br />
<br />
If this kernel is for a Server also enable {{ic|Disable privileged I/O}} found in {{ic|Memory Protections}}.<br />
<br />
All other setting should be optimal as they are, so now exit out of the ncurses GUI config and Save. Now the package should start to build. If all goes well you will have two .pkg.tar.xz packages one for the kernel and one for the kernel-headers.<br />
<br />
=== Make a Backup ===<br />
<br />
Keep all linux-grsec.tar.gz files along with the grsecruity patch and compiled packages in the Root users home folder. That way you can roll back if needed. Every time a new grsecurity patch is release you will not be able to download outdated patches every again.<br />
<br />
# mkdir /root/3.10.9<br />
# cp -r /home/USER/linux-grsec /root/3.10.9<br />
<br />
== Install PaX and RBAC Utilities ==<br />
<br />
The AUR also has [https://aur.archlinux.org/packages/paxctl/ paxctl], [https://aur.archlinux.org/packages/gradm/ gradm], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] packages that you will need.<br />
<br />
For simplicities sake I will assume you are using yaourt to install package form the AUR, however any other way of installing these packages will work as well.<br />
<br />
$ yaourt -S linux-pax-flags paxctl gradm<br />
<br />
== Set PaX Flags ==<br />
<br />
Use the linux-pax-flags program to configure all the PaX flags for troublesome programs.<br />
More information can be found in the Using linux-pax-flags AUR Package section.<br />
<br />
# linux-pax-flags<br />
<br />
== Install Hardened Kernel ==<br />
<br />
Now that all the needed utilities are installed and the system is configured for PaX, install the hardened kernel and headers.<br />
<br />
# pacman -U /root/3.10.9/*.pkg.tar.xz<br />
<br />
Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
You should now be in your hardened system. Just make sure to run {{ic|linux-pax-flags}} after every time you update your system or install a new program and you should have a trouble free experience.<br />
<br />
= Manual Kernel Configuration =<br />
<br />
Throughout this document we will talk about kernel configuration using the kernel variables like CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. These are the variables that the kernel build process uses to determine if a certain feature needs to be compiled.<br />
<br />
When you configure your kernel through make menuconfig or similar, you receive a user interface through which you can select the various kernel options. If you select the Help button at a certain kernel feature you will see at the top that it lists such a kernel variable.<br />
<br />
You can therefore still configure your kernel as you like - with a bit of thinking. And if you can't find a certain option, there's always the possibility to edit /usr/src/linux/.config by hand :)<br />
<br />
Of course, to be able to select the various grsecurity kernel options, you must enable grsecurity in your kernel.<br />
See [[default grsecurity kernel configuration]]<br />
<br />
== PaX ==<br />
<br />
=== Fighting the Exploitation of Software Bugs ===<br />
<br />
PaX introduces a couple of security mechanisms that make it harder for attackers to exploit software bugs that involve memory corruption (so do not treat PaX as if it protects against all possible software bugs). The PaX introduction document talks about three possible exploit techniques:<br />
<br />
# introduce/execute arbitrary code<br />
# execute existing code out of original program order<br />
# execute existing code in original program order with arbitrary data<br />
<br />
One prevention method disallows executable code to be stored in writable memory. When we look at a process, it requires five memory regions:<br />
<br />
# a data section which contains the statically allocated and global data<br />
# a BSS region (Block Started by Symbol) which contains information about the zero-initialized data of the process<br />
# a code region, also called the text segment, which contains the executable instructions<br />
# a heap which contains the dynamically allocated memory<br />
# a stack which contains the local variables<br />
<br />
The first PaX prevention method, called NOEXEC, is meant to give control over the runtime code generation. It marks memory pages that do not contain executable code as non-executable. This means that the heap and the stack, which only contain variable data and shouldn't contain executable code, are marked as non-executable. Exploits that place code in these areas with the intention of running it will fail.<br />
<br />
NOEXEC does more than this actually, interested readers should focus their attention to the [http://pax.grsecurity.net/docs/noexec.txt PaX NOEXEC documentation].<br />
<br />
The second PaX prevention method, called ASLR (Address Space Layout Randomization), randomize the addresses given to memory requests. Where previously memory was assigned contiguously (which means exploits know where the tasks' memory regions are situated) ASLR randomizes this allocation, rendering techniques that rely on this information useless.<br />
<br />
More information about ASLR can be found [http://pax.grsecurity.net/docs/aslr.txt online].<br />
<br />
=== PaX kernel configuration ===<br />
<br />
<br />
The recommended kernel setting for PaX is:<br />
<br />
#<br />
# Security options<br />
#<br />
#<br />
# PaX<br />
#<br />
CONFIG_PAX=y<br />
#<br />
# PaX Control<br />
#<br />
# CONFIG_PAX_SOFTMODE is not set<br />
CONFIG_PAX_EI_PAX=y<br />
CONFIG_PAX_PT_PAX_FLAGS=y<br />
CONFIG_PAX_NO_ACL_FLAGS=y<br />
# CONFIG_PAX_HAVE_ACL_FLAGS is not set<br />
# CONFIG_PAX_HOOK_ACL_FLAGS is not set<br />
#<br />
# Non-executable pages<br />
#<br />
CONFIG_PAX_NOEXEC=y<br />
CONFIG_PAX_PAGEEXEC=y<br />
CONFIG_PAX_SEGMEXEC=y<br />
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set<br />
CONFIG_PAX_DEFAULT_SEGMEXEC=y<br />
CONFIG_PAX_EMUTRAMP=y<br />
CONFIG_PAX_MPROTECT=y<br />
# CONFIG_PAX_NOELFRELOCS is not set<br />
#<br />
# Address Space Layout Randomization<br />
#<br />
CONFIG_PAX_ASLR=y<br />
CONFIG_PAX_RANDKSTACK=y<br />
CONFIG_PAX_RANDUSTACK=y<br />
CONFIG_PAX_RANDMMAP=y<br />
#<br />
# Miscellaneous hardening features<br />
#<br />
CONFIG_PAX_MEMORY_SANITIZE=y<br />
CONFIG_PAX_MEMORY_UDEREF=y<br />
CONFIG_KEYS=y<br />
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_NETWORK_XFRM=y<br />
CONFIG_SECURITY_CAPABILITIES=m<br />
CONFIG_SECURITY_ROOTPLUG=m<br />
<br />
If you are running a non-x86 system you will observe that there is no CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC instead as it is the only non-exec implementation around.<br />
<br />
=== Controlling PaX ===<br />
<br />
Not all Linux applications are happy with the PaX security restrictions. These tools include xorg-x11, java, mplayer, xmms and others. If you plan on using them you can elevate the protections for these applications using chpax and paxctl. You can find they on AUR.<br />
<br />
You can also use pax-utils, which is a small toolbox which contains useful applications to administrate a PaX aware server. Find it on AUR.<br />
<br />
Interesting tools include scanelf and pspax:<br />
<br />
* With scanelf you can scan over library and binary directories and list the various permissions and ELF types that pertain to running an ideal pax/grsec setup<br />
* With pspax you can display PaX flags/capabilities/xattr from the kernel's perspective<br />
<br />
=== Verifying the PaX Settings ===<br />
<br />
Peter Busser has written a regression test suite called paxtest. This tool will check various cases of possible attack vectors and inform you of the result. When you run it, it will leave a logfile called paxtest.log in the current working directory.<br />
<br />
# paxtest<br />
Executable anonymous mapping : Killed<br />
Executable bss : Killed<br />
Executable data : Killed<br />
Executable heap : Killed<br />
Executable stack : Killed<br />
Executable anonymous mapping (mprotect) : Killed<br />
Executable bss (mprotect) : Killed<br />
Executable data (mprotect) : Killed<br />
Executable heap (mprotect) : Killed<br />
Executable stack (mprotect) : Killed<br />
Executable shared library bss (mprotect) : Killed<br />
Executable shared library data (mprotect): Killed<br />
Writable text segments : Killed<br />
Anonymous mapping randomisation test : 16 bits (guessed)<br />
Heap randomisation test (ET_EXEC) : 13 bits (guessed)<br />
Heap randomisation test (ET_DYN) : 25 bits (guessed)<br />
Main executable randomisation (ET_EXEC) : 16 bits (guessed)<br />
Main executable randomisation (ET_DYN) : 17 bits (guessed)<br />
Shared library randomisation test : 16 bits (guessed)<br />
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)<br />
Stack randomisation test (PAGEEXEC) : No randomisation<br />
Return to function (strcpy) : Vulnerable<br />
Return to function (memcpy) : Vulnerable<br />
Return to function (strcpy, RANDEXEC) : Killed<br />
Return to function (memcpy, RANDEXEC) : Killed<br />
Executable shared library bss : Killed<br />
Executable shared library data : Killed<br />
<br />
In the above example run you notice that:<br />
<br />
* strcpy and memcpy are listed as Vulnerable. This is expected and normal - it is simply showing the need for a technology such as ProPolice/SSP<br />
* there is no randomization for PAGEEXEC. This is normal since our recommended x86 kernel configuration didn't activate the PAGEEXEC setting. However, on arches that support a true NX (non-executable) bit (most of them do, including x86_64), PAGEEXEC is the only method available for NOEXEC and has no performance hit.<br />
<br />
== Filesystem Protection ==<br />
<br />
=== Fighting Chroot and Filesystem Abuse ===<br />
<br />
Grsecurity2 includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on /proc usage, chrooting, linking, etc.<br />
<br />
=== Kernel Configuration ===<br />
<br />
We recommend the following grsecurity kernel configuration for filesystem protection:<br />
<br />
#<br />
# Filesystem Protections<br />
#<br />
CONFIG_GRKERNSEC_PROC=y<br />
# CONFIG_GRKERNSEC_PROC_USER is not set<br />
CONFIG_GRKERNSEC_PROC_USERGROUP=y<br />
CONFIG_GRKERNSEC_PROC_GID=3<br />
CONFIG_GRKERNSEC_PROC_ADD=y<br />
CONFIG_GRKERNSEC_LINK=y<br />
CONFIG_GRKERNSEC_FIFO=y<br />
CONFIG_GRKERNSEC_CHROOT=y<br />
CONFIG_GRKERNSEC_CHROOT_MOUNT=y<br />
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y<br />
CONFIG_GRKERNSEC_CHROOT_PIVOT=y<br />
CONFIG_GRKERNSEC_CHROOT_CHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_CHMOD=y<br />
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_MKNOD=y<br />
CONFIG_GRKERNSEC_CHROOT_SHMAT=y<br />
CONFIG_GRKERNSEC_CHROOT_UNIX=y<br />
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y<br />
CONFIG_GRKERNSEC_CHROOT_NICE=y<br />
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y<br />
CONFIG_GRKERNSEC_CHROOT_CAPS=y<br />
<br />
=== Triggering the Security Mechanism ===<br />
<br />
When you're using a kernel compiled with the above (or similar) settings, you will get the option to enable/disable many of the options through the /proc filesystem or via sysctl.<br />
<br />
The example below shows an excerpt of a typical /etc/sysctl.conf:<br />
<br />
kernel.grsecurity.chroot_deny_sysctl = 1<br />
kernel.grsecurity.chroot_caps = 1<br />
kernel.grsecurity.chroot_execlog = 0<br />
kernel.grsecurity.chroot_restrict_nice = 1<br />
kernel.grsecurity.chroot_deny_mknod = 1<br />
kernel.grsecurity.chroot_deny_chmod = 1<br />
kernel.grsecurity.chroot_enforce_chdir = 1<br />
kernel.grsecurity.chroot_deny_pivot = 1<br />
kernel.grsecurity.chroot_deny_chroot = 1<br />
kernel.grsecurity.chroot_deny_fchdir = 1<br />
kernel.grsecurity.chroot_deny_mount = 1<br />
kernel.grsecurity.chroot_deny_unix = 1<br />
kernel.grsecurity.chroot_deny_shmat = 1<br />
<br />
You can enable or disable settings at will using the sysctl command:<br />
<br />
(Toggling the exec_logging feature ON)<br />
# sysctl -w kernel.grsecurity.exec_logging = 1<br />
(Toggling the exec_logging feature OFF)<br />
# sysctl -w kernel.grsecurity.exec_logging = 0<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
== Kernel Auditing ==<br />
<br />
=== Extend your System's Logging Facilities ===<br />
<br />
grsecurity adds extra functionality to the kernel pertaining the logging. With grsecurity's Kernel Auditing the kernel informs you when applications are started, devices (un)mounted, etc.<br />
<br />
=== The various Kernel Audit Settings ===<br />
<br />
The following kernel configuration section can be used to enable grsecurity's Kernel Audit Settings:<br />
<br />
#<br />
# Kernel Auditing<br />
#<br />
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set<br />
CONFIG_GRKERNSEC_EXECLOG=y<br />
CONFIG_GRKERNSEC_RESLOG=y<br />
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y<br />
CONFIG_GRKERNSEC_AUDIT_CHDIR=y<br />
CONFIG_GRKERNSEC_AUDIT_MOUNT=y<br />
CONFIG_GRKERNSEC_AUDIT_IPC=y<br />
CONFIG_GRKERNSEC_SIGNAL=y<br />
CONFIG_GRKERNSEC_FORKFAIL=y<br />
CONFIG_GRKERNSEC_TIME=y<br />
CONFIG_GRKERNSEC_PROC_IPADDR=y<br />
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y<br />
<br />
== Process Restrictions ==<br />
<br />
=== Executable Protection ===<br />
<br />
With grsecurity you can restrict executables. Since most exploits work through one or more running processes this protection can save your system's health.<br />
<br />
=== Network Protection ===<br />
<br />
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity includes randomization patches to counter these attacks. Apart from these you can also enable socket restrictions, disallowing certain groups network access alltogether.<br />
<br />
=== Kernel Settings ===<br />
<br />
The following kernel settings enable various executable and network protections:<br />
<br />
#<br />
# Executable Protections<br />
#<br />
CONFIG_GRKERNSEC_EXECVE=y<br />
CONFIG_GRKERNSEC_DMESG=y<br />
CONFIG_GRKERNSEC_RANDPID=y<br />
CONFIG_GRKERNSEC_TPE=y<br />
CONFIG_GRKERNSEC_TPE_ALL=y<br />
CONFIG_GRKERNSEC_TPE_GID=100<br />
<br />
#<br />
# Network Protections<br />
#<br />
CONFIG_GRKERNSEC_RANDNET=y<br />
CONFIG_GRKERNSEC_RANDISN=y<br />
CONFIG_GRKERNSEC_RANDID=y<br />
CONFIG_GRKERNSEC_RANDSRC=y<br />
CONFIG_GRKERNSEC_RANDRPC=y<br />
# CONFIG_GRKERNSEC_SOCKET is not set<br />
<br />
= RBAC =<br />
<br />
Role Based Access Control<br />
<br />
There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.<br />
<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
== Configuring the Kernel ==<br />
<br />
The recommended kernel setting for RBAC is:<br />
<br />
#<br />
# Role Based Access Control Options<br />
#<br />
CONFIG_GRKERNSEC_ACL_HIDEKERN=y<br />
CONFIG_GRKERNSEC_ACL_MAXTRIES=3<br />
CONFIG_GRKERNSEC_ACL_TIMEOUT=30<br />
<br />
== Working with gradm ==<br />
<br />
gradm is a tool which allows you to administer and maintain a policy for your system. With it, you can enable or disable the RBAC system, reload the RBAC roles, change your role, set a password for admin mode, etc.<br />
<br />
When you install gradm a default policy will be installed in /etc/grsec/policy. Please see in AUR for gradm package.<br />
<br />
By default, the RBAC policies are not activated. It is the sysadmin's job to determine when the system should have an RBAC policy enforced. Before activating the RBAC system you should set an admin password.<br />
<br />
# gradm -P admin<br />
Setting up grsecurity RBAC password<br />
Password: (Enter a well-chosen password)<br />
Re-enter Password: (Enter the same password for confirmation)<br />
Password written in /etc/grsec/pw<br />
# gradm -E<br />
<br />
To disable the RBAC system, run gradm -D. If you are not allowed to, you first need to switch to the admin role:<br />
<br />
# gradm -a admin<br />
Password: (Enter your admin role password)<br />
# gradm -D<br />
<br />
If you want to leave the admin role, run gradm -u admin:<br />
<br />
# gradm -u admin<br />
<br />
== Generating a Policy ==<br />
<br />
The RBAC system comes with a great feature called "learning mode". The learning mode can generate an anticipatory least privilege policy for your system. This allows for time and money savings by being able to rapidly deploy multiple secure servers.<br />
<br />
To use the learning mode, activate it using gradm:<br />
<br />
# gradm -F -L /etc/grsec/learning.log<br />
<br />
Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate or any other heavy file i/o operation as this can really slow down the processing time.<br />
<br />
When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under {{ic|/etc/grsec/learning.roles}}:<br />
<br />
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles<br />
<br />
Audit the {{ic|/etc/grsec/learning.roles}} and save it as {{ic|/etc/grsec/policy}} (mode {{ic|0600}}) when you are finished.<br />
<br />
# mv /etc/grsec/learning.roles /etc/grsec/policy<br />
# chmod 0600 /etc/grsec/policy<br />
<br />
You will now be able to enable the RBAC system with your new learned policy.<br />
<br />
== Tweaking your Policy ==<br />
<br />
An interesting feature of grsecurity 2.x is Set Operation Support for the configuration file. Currently it supports unions, intersections and differences of sets (of objects in this case).<br />
<br />
define objset1 {<br />
/root/blah rw<br />
/root/blah2 r<br />
/root/blah3 x<br />
}<br />
<br />
define somename2 {<br />
/root/test1 rw<br />
/root/blah2 rw<br />
/root/test3 h<br />
}<br />
<br />
Here is an example of its use, and the resulting objects that will be added to your subject:<br />
<br />
subject /somebinary o<br />
$objset1 & $somename2<br />
<br />
The above would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah2 r<br />
<br />
This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.<br />
<br />
subject /somebinary o<br />
$objset1 | $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 rw<br />
/root/blah3 x<br />
/root/test1 rw<br />
/root/test3 h<br />
<br />
This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.<br />
<br />
subject /somebinary o<br />
$objset1 - $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 h<br />
/root/blah3 x<br />
<br />
This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.<br />
<br />
In some obscure pseudo-language you could see this as:<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained /tmp/blah r) )<br />
then<br />
$objset1 - $objset2 would contain /tmp/blah w<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained / rwx) )<br />
then <br />
$objset1 - $objset2 would contain /tmp/blah h<br />
<br />
As for order of precedence (from highest to lowest): "-, & |".<br />
<br />
If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:<br />
<br />
(($set1 - $set2) | $set3) & $set4<br />
<br />
= Using linux-pax-flags AUR Package =<br />
<br />
The linux-pax-flags program is what makes using PaX on Arch Linux easy as pie. When you run this program it will set the PaX flags for all the problematic programs for you. However, if you use some uncommon program it may have problems forcing you to set the paxctl flags yourself. You will most likely see something like {{ic|Denied RWX}} in journalctl. That means you will need to disable MPROTECT for the program {{ic|paxctl -cPEmRXS /usr/bin/bla}}<br />
<br />
After you find what PaX flags need to be set post a comment on the linux-pax-flags AUR package so it can be added.<br />
<br />
More extensive documentation of the linux-pax-flags utility is to be found on it's man page.<br />
<br />
= Tips and Tricks =<br />
<br />
Because you will not be able to change the PaX flags for a running program, and that the vast majority of programs which would need them are graphical, it is strongly advisable to not use a Graphical Login like GDM or KDM. Instead simply have the system drop you to a console to log in and use {{ic|startx}}. Then you will have a chance to set the PaX flags before anything starts. For the same reasons it is strongly advisable to update your system and run {{ic|linux-pax-flags}} right after boot, before running {{ic|startx}}.<br />
<br />
Grsecurity will harden /proc and /sys so your normal user will no longer be able to see the network status, becuase of this non of your desktop network monitors will work. Instead just install terminal based monitoring programs, such as [https://www.archlinux.org/packages/community/x86_64/nmon/ nmon] or [https://www.archlinux.org/packages/community/x86_64/nload/ nload] and run them as root, or as a user in the proc-trusted group.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Grsecurity&diff=272408Grsecurity2013-08-24T22:33:18Z<p>Hunterthomson: /* Download Files */ spelling</p>
<hr />
<div>[[Category:Kernel]][[Category:Security]]<br />
The grsecurity project, hosted on https://grsecurity.net, provides various patches to the Linux kernel which enhance your system's overall security. grsecurity also ships with PaX which provides the most advanced memory protections of any OS. PaX invented ALSR and shows that it is only the tip of the iceberg. The RBAC Mandatory Access Control system of grsecurity was the inspriation for SELinux and AppArmor.<br />
<br />
In short, a Linux kernel hardened with grsecurity is the most hardened kernel you could have. Not even OpenBSD has all the hardening features it provides. A comprehensive list is maintained on the [http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options grsecurity features page] itself. However, the grsecurity Wiki is often out-of-date. The best way is to simply read the help text in the kernel config.<br />
<br />
Arch has all the utilities and kernel packages you need to run a grsecurity hardened Arch Linux system in the AUR. Arch even has a script called [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] which will make using PaX as painless as possible by setting all of the PaX flags for you.<br />
<br />
You can install the kernel either from a binary repository or - if you want more control - manually from the AUR.<br />
<br />
= Install binary packages =<br />
<br />
Add the [http://arsch.orgizm.net/ Arsch Arch Linux Repository] to your package sources and install the kernel with {{ic|pacman -Sy linux-grsec}} (or the PaX only kernel with {{ic|pacman -Sy linux-pax}}). Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
= Setup and Install from AUR =<br />
<br />
To build the AUR package we will follow this general game plan. First, download all needed files and check GPG signatures. Second, configure kernel and compile. Third, copy a backup of these files to the Root users home folder. Forth, install utilities needed for PaX and RBAC. Fifth, install the kernel package. Sixth, run linux-pax-flags to poke security holes in applications that will not run without them. Finally, reboot into your hardened system.<br />
<br />
== Download Files ==<br />
<br />
Download the packages<br />
[https://aur.archlinux.org/packages/linux-grsec/ linux-grsec]<br />
Or<br />
[https://aur.archlinux.org/packages/linux-grsec-lts/ linux-grsec-lts]<br />
<br />
Kernel linux-3.X.tar.xz and current patch-3.X.X.tar.xz also the .sign signature files for each.<br />
[https://www.kernel.org/pub/linux/kernel/v3.x/ kernel.org]<br />
<br />
Download the current grsecurity patch and Signatures<br />
[https://grsecurity.net/test.php grsecurity Test]<br />
Or<br />
[https://grsecurity.net/download_stable.php grsecurity Stable] for LTS kernel<br />
<br />
{{tip|The Grsecurity Test is in fact stable. The Stable Grsecurity version is just for the LTS}}<br />
<br />
=== Verify The GPG Signatures ===<br />
<br />
With the .sign files in the same directory as the file it is a a signature of, verify the signature like so...<br />
<br />
$ gpg2 --verify linux-3.10.tar.sign<br />
<br />
== Setup Build Environment ==<br />
<br />
Unpack the linux-grsec.tar.gz and copy all the files into it<br />
<br />
$ tar xzf linux-grsec.tar.gz<br />
$ cp ~/Downloads/linux-3.10.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/patch-3.10.9.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/grsecurity-2.9.1-3.10.9-201308202015.patch ~/linux-grsec<br />
<br />
Change into the build directory<br />
<br />
$ cd ~/linux-grsec<br />
<br />
== Build the Kernel Package ==<br />
<br />
It is going to take a long time to build the kernel because it is based on the default Arch kernel config with has about ten times as make modules enabled then your system actually needs. However, it is a known working config and to eliminate any more variables it is advisable to just live with the extra build time.<br />
<br />
Build the package<br />
<br />
$ MENUCONFIG=2 makepkg<br />
<br />
You should be dropped into the ncurses GUI now. Navigate to the grsecurity settings to verify the configuration and/or change things as needed. These setting can be found in {{ic|Security options ---> Grsecurity ---> Customize Configuration --->}}<br />
<br />
For both Desktops and Servers after you are sure you will not need to change any of the Grsecurity settings with sysctl, disable {{ic|Sysctl support}} found in {{ic|Sysctl Support}}.<br />
<br />
If this kernel is for a Server also enable {{ic|Disable privileged I/O}} found in {{ic|Memory Protections}}.<br />
<br />
All other setting should be optimal as they are, so now exit out of the ncurses GUI config and Save. Now the package should start to build. If all goes well you will have two .pkg.tar.xz packages one for the kernel and one for the kernel-headers.<br />
<br />
=== Make a Backup ===<br />
<br />
Keep all linux-grsec.tar.gz files along with the grsecruity patch and compiled packages in the Root users home folder. That way you can roll back if needed. Every time a new grsecurity patch is release you will not be able to download outdated patches every again.<br />
<br />
# mkdir /root/3.10.9<br />
# cp -r /home/USER/linux-grsec /root/3.10.9<br />
<br />
== Install PaX and RBAC Utilities ==<br />
<br />
The AUR also has [https://aur.archlinux.org/packages/paxctl/ paxctl], [https://aur.archlinux.org/packages/gradm/ gradm], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] packages that you will need.<br />
<br />
For simplicities sake I will assume you are using yaourt to install package form the AUR, however any other way of installing these packages will work as well.<br />
<br />
$ yaourt -S linux-pax-flags paxctl gradm<br />
<br />
== Set PaX Flags ==<br />
<br />
Use the linux-pax-flags program to configure all the PaX flags for troublesome programs.<br />
More information can be found in the Using linux-pax-flags AUR Package section.<br />
<br />
# linux-pax-flags<br />
<br />
== Install Hardened Kernel ==<br />
<br />
Now that all the needed utilities are installed and the system is configured for PaX, install the hardened kernel and headers.<br />
<br />
# pacman -U /root/3.10.9/*.pkg.tar.xz<br />
<br />
Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
You should now be in your hardened system. Just make sure to run {{ic|linux-pax-flags}} after every time you update your system or install a new program and you should have a trouble free experience.<br />
<br />
= Manual Kernel Configuration =<br />
<br />
Throughout this document we will talk about kernel configuration using the kernel variables like CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. These are the variables that the kernel build process uses to determine if a certain feature needs to be compiled.<br />
<br />
When you configure your kernel through make menuconfig or similar, you receive a user interface through which you can select the various kernel options. If you select the Help button at a certain kernel feature you will see at the top that it lists such a kernel variable.<br />
<br />
You can therefore still configure your kernel as you like - with a bit of thinking. And if you can't find a certain option, there's always the possibility to edit /usr/src/linux/.config by hand :)<br />
<br />
Of course, to be able to select the various grsecurity kernel options, you must enable grsecurity in your kernel.<br />
See [[default grsecurity kernel configuration]]<br />
<br />
== PaX ==<br />
<br />
=== Fighting the Exploitation of Software Bugs ===<br />
<br />
PaX introduces a couple of security mechanisms that make it harder for attackers to exploit software bugs that involve memory corruption (so do not treat PaX as if it protects against all possible software bugs). The PaX introduction document talks about three possible exploit techniques:<br />
<br />
# introduce/execute arbitrary code<br />
# execute existing code out of original program order<br />
# execute existing code in original program order with arbitrary data<br />
<br />
One prevention method disallows executable code to be stored in writable memory. When we look at a process, it requires five memory regions:<br />
<br />
# a data section which contains the statically allocated and global data<br />
# a BSS region (Block Started by Symbol) which contains information about the zero-initialized data of the process<br />
# a code region, also called the text segment, which contains the executable instructions<br />
# a heap which contains the dynamically allocated memory<br />
# a stack which contains the local variables<br />
<br />
The first PaX prevention method, called NOEXEC, is meant to give control over the runtime code generation. It marks memory pages that do not contain executable code as non-executable. This means that the heap and the stack, which only contain variable data and shouldn't contain executable code, are marked as non-executable. Exploits that place code in these areas with the intention of running it will fail.<br />
<br />
NOEXEC does more than this actually, interested readers should focus their attention to the [http://pax.grsecurity.net/docs/noexec.txt PaX NOEXEC documentation].<br />
<br />
The second PaX prevention method, called ASLR (Address Space Layout Randomization), randomize the addresses given to memory requests. Where previously memory was assigned contiguously (which means exploits know where the tasks' memory regions are situated) ASLR randomizes this allocation, rendering techniques that rely on this information useless.<br />
<br />
More information about ASLR can be found [http://pax.grsecurity.net/docs/aslr.txt online].<br />
<br />
=== PaX kernel configuration ===<br />
<br />
<br />
The recommended kernel setting for PaX is:<br />
<br />
#<br />
# Security options<br />
#<br />
#<br />
# PaX<br />
#<br />
CONFIG_PAX=y<br />
#<br />
# PaX Control<br />
#<br />
# CONFIG_PAX_SOFTMODE is not set<br />
CONFIG_PAX_EI_PAX=y<br />
CONFIG_PAX_PT_PAX_FLAGS=y<br />
CONFIG_PAX_NO_ACL_FLAGS=y<br />
# CONFIG_PAX_HAVE_ACL_FLAGS is not set<br />
# CONFIG_PAX_HOOK_ACL_FLAGS is not set<br />
#<br />
# Non-executable pages<br />
#<br />
CONFIG_PAX_NOEXEC=y<br />
CONFIG_PAX_PAGEEXEC=y<br />
CONFIG_PAX_SEGMEXEC=y<br />
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set<br />
CONFIG_PAX_DEFAULT_SEGMEXEC=y<br />
CONFIG_PAX_EMUTRAMP=y<br />
CONFIG_PAX_MPROTECT=y<br />
# CONFIG_PAX_NOELFRELOCS is not set<br />
#<br />
# Address Space Layout Randomization<br />
#<br />
CONFIG_PAX_ASLR=y<br />
CONFIG_PAX_RANDKSTACK=y<br />
CONFIG_PAX_RANDUSTACK=y<br />
CONFIG_PAX_RANDMMAP=y<br />
#<br />
# Miscellaneous hardening features<br />
#<br />
CONFIG_PAX_MEMORY_SANITIZE=y<br />
CONFIG_PAX_MEMORY_UDEREF=y<br />
CONFIG_KEYS=y<br />
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_NETWORK_XFRM=y<br />
CONFIG_SECURITY_CAPABILITIES=m<br />
CONFIG_SECURITY_ROOTPLUG=m<br />
<br />
If you are running a non-x86 system you will observe that there is no CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC instead as it is the only non-exec implementation around.<br />
<br />
=== Controlling PaX ===<br />
<br />
Not all Linux applications are happy with the PaX security restrictions. These tools include xorg-x11, java, mplayer, xmms and others. If you plan on using them you can elevate the protections for these applications using chpax and paxctl. You can find they on AUR.<br />
<br />
You can also use pax-utils, which is a small toolbox which contains useful applications to administrate a PaX aware server. Find it on AUR.<br />
<br />
Interesting tools include scanelf and pspax:<br />
<br />
* With scanelf you can scan over library and binary directories and list the various permissions and ELF types that pertain to running an ideal pax/grsec setup<br />
* With pspax you can display PaX flags/capabilities/xattr from the kernel's perspective<br />
<br />
=== Verifying the PaX Settings ===<br />
<br />
Peter Busser has written a regression test suite called paxtest. This tool will check various cases of possible attack vectors and inform you of the result. When you run it, it will leave a logfile called paxtest.log in the current working directory.<br />
<br />
# paxtest<br />
Executable anonymous mapping : Killed<br />
Executable bss : Killed<br />
Executable data : Killed<br />
Executable heap : Killed<br />
Executable stack : Killed<br />
Executable anonymous mapping (mprotect) : Killed<br />
Executable bss (mprotect) : Killed<br />
Executable data (mprotect) : Killed<br />
Executable heap (mprotect) : Killed<br />
Executable stack (mprotect) : Killed<br />
Executable shared library bss (mprotect) : Killed<br />
Executable shared library data (mprotect): Killed<br />
Writable text segments : Killed<br />
Anonymous mapping randomisation test : 16 bits (guessed)<br />
Heap randomisation test (ET_EXEC) : 13 bits (guessed)<br />
Heap randomisation test (ET_DYN) : 25 bits (guessed)<br />
Main executable randomisation (ET_EXEC) : 16 bits (guessed)<br />
Main executable randomisation (ET_DYN) : 17 bits (guessed)<br />
Shared library randomisation test : 16 bits (guessed)<br />
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)<br />
Stack randomisation test (PAGEEXEC) : No randomisation<br />
Return to function (strcpy) : Vulnerable<br />
Return to function (memcpy) : Vulnerable<br />
Return to function (strcpy, RANDEXEC) : Killed<br />
Return to function (memcpy, RANDEXEC) : Killed<br />
Executable shared library bss : Killed<br />
Executable shared library data : Killed<br />
<br />
In the above example run you notice that:<br />
<br />
* strcpy and memcpy are listed as Vulnerable. This is expected and normal - it is simply showing the need for a technology such as ProPolice/SSP<br />
* there is no randomization for PAGEEXEC. This is normal since our recommended x86 kernel configuration didn't activate the PAGEEXEC setting. However, on arches that support a true NX (non-executable) bit (most of them do, including x86_64), PAGEEXEC is the only method available for NOEXEC and has no performance hit.<br />
<br />
== Filesystem Protection ==<br />
<br />
=== Fighting Chroot and Filesystem Abuse ===<br />
<br />
Grsecurity2 includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on /proc usage, chrooting, linking, etc.<br />
<br />
=== Kernel Configuration ===<br />
<br />
We recommend the following grsecurity kernel configuration for filesystem protection:<br />
<br />
#<br />
# Filesystem Protections<br />
#<br />
CONFIG_GRKERNSEC_PROC=y<br />
# CONFIG_GRKERNSEC_PROC_USER is not set<br />
CONFIG_GRKERNSEC_PROC_USERGROUP=y<br />
CONFIG_GRKERNSEC_PROC_GID=3<br />
CONFIG_GRKERNSEC_PROC_ADD=y<br />
CONFIG_GRKERNSEC_LINK=y<br />
CONFIG_GRKERNSEC_FIFO=y<br />
CONFIG_GRKERNSEC_CHROOT=y<br />
CONFIG_GRKERNSEC_CHROOT_MOUNT=y<br />
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y<br />
CONFIG_GRKERNSEC_CHROOT_PIVOT=y<br />
CONFIG_GRKERNSEC_CHROOT_CHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_CHMOD=y<br />
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_MKNOD=y<br />
CONFIG_GRKERNSEC_CHROOT_SHMAT=y<br />
CONFIG_GRKERNSEC_CHROOT_UNIX=y<br />
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y<br />
CONFIG_GRKERNSEC_CHROOT_NICE=y<br />
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y<br />
CONFIG_GRKERNSEC_CHROOT_CAPS=y<br />
<br />
=== Triggering the Security Mechanism ===<br />
<br />
When you're using a kernel compiled with the above (or similar) settings, you will get the option to enable/disable many of the options through the /proc filesystem or via sysctl.<br />
<br />
The example below shows an excerpt of a typical /etc/sysctl.conf:<br />
<br />
kernel.grsecurity.chroot_deny_sysctl = 1<br />
kernel.grsecurity.chroot_caps = 1<br />
kernel.grsecurity.chroot_execlog = 0<br />
kernel.grsecurity.chroot_restrict_nice = 1<br />
kernel.grsecurity.chroot_deny_mknod = 1<br />
kernel.grsecurity.chroot_deny_chmod = 1<br />
kernel.grsecurity.chroot_enforce_chdir = 1<br />
kernel.grsecurity.chroot_deny_pivot = 1<br />
kernel.grsecurity.chroot_deny_chroot = 1<br />
kernel.grsecurity.chroot_deny_fchdir = 1<br />
kernel.grsecurity.chroot_deny_mount = 1<br />
kernel.grsecurity.chroot_deny_unix = 1<br />
kernel.grsecurity.chroot_deny_shmat = 1<br />
<br />
You can enable or disable settings at will using the sysctl command:<br />
<br />
(Toggling the exec_logging feature ON)<br />
# sysctl -w kernel.grsecurity.exec_logging = 1<br />
(Toggling the exec_logging feature OFF)<br />
# sysctl -w kernel.grsecurity.exec_logging = 0<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
== Kernel Auditing ==<br />
<br />
=== Extend your System's Logging Facilities ===<br />
<br />
grsecurity adds extra functionality to the kernel pertaining the logging. With grsecurity's Kernel Auditing the kernel informs you when applications are started, devices (un)mounted, etc.<br />
<br />
=== The various Kernel Audit Settings ===<br />
<br />
The following kernel configuration section can be used to enable grsecurity's Kernel Audit Settings:<br />
<br />
#<br />
# Kernel Auditing<br />
#<br />
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set<br />
CONFIG_GRKERNSEC_EXECLOG=y<br />
CONFIG_GRKERNSEC_RESLOG=y<br />
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y<br />
CONFIG_GRKERNSEC_AUDIT_CHDIR=y<br />
CONFIG_GRKERNSEC_AUDIT_MOUNT=y<br />
CONFIG_GRKERNSEC_AUDIT_IPC=y<br />
CONFIG_GRKERNSEC_SIGNAL=y<br />
CONFIG_GRKERNSEC_FORKFAIL=y<br />
CONFIG_GRKERNSEC_TIME=y<br />
CONFIG_GRKERNSEC_PROC_IPADDR=y<br />
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y<br />
<br />
== Process Restrictions ==<br />
<br />
=== Executable Protection ===<br />
<br />
With grsecurity you can restrict executables. Since most exploits work through one or more running processes this protection can save your system's health.<br />
<br />
=== Network Protection ===<br />
<br />
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity includes randomization patches to counter these attacks. Apart from these you can also enable socket restrictions, disallowing certain groups network access alltogether.<br />
<br />
=== Kernel Settings ===<br />
<br />
The following kernel settings enable various executable and network protections:<br />
<br />
#<br />
# Executable Protections<br />
#<br />
CONFIG_GRKERNSEC_EXECVE=y<br />
CONFIG_GRKERNSEC_DMESG=y<br />
CONFIG_GRKERNSEC_RANDPID=y<br />
CONFIG_GRKERNSEC_TPE=y<br />
CONFIG_GRKERNSEC_TPE_ALL=y<br />
CONFIG_GRKERNSEC_TPE_GID=100<br />
<br />
#<br />
# Network Protections<br />
#<br />
CONFIG_GRKERNSEC_RANDNET=y<br />
CONFIG_GRKERNSEC_RANDISN=y<br />
CONFIG_GRKERNSEC_RANDID=y<br />
CONFIG_GRKERNSEC_RANDSRC=y<br />
CONFIG_GRKERNSEC_RANDRPC=y<br />
# CONFIG_GRKERNSEC_SOCKET is not set<br />
<br />
= RBAC =<br />
<br />
Role Based Access Control<br />
<br />
There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.<br />
<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
== Configuring the Kernel ==<br />
<br />
The recommended kernel setting for RBAC is:<br />
<br />
#<br />
# Role Based Access Control Options<br />
#<br />
CONFIG_GRKERNSEC_ACL_HIDEKERN=y<br />
CONFIG_GRKERNSEC_ACL_MAXTRIES=3<br />
CONFIG_GRKERNSEC_ACL_TIMEOUT=30<br />
<br />
== Working with gradm ==<br />
<br />
gradm is a tool which allows you to administer and maintain a policy for your system. With it, you can enable or disable the RBAC system, reload the RBAC roles, change your role, set a password for admin mode, etc.<br />
<br />
When you install gradm a default policy will be installed in /etc/grsec/policy. Please see in AUR for gradm package.<br />
<br />
By default, the RBAC policies are not activated. It is the sysadmin's job to determine when the system should have an RBAC policy enforced. Before activating the RBAC system you should set an admin password.<br />
<br />
# gradm -P admin<br />
Setting up grsecurity RBAC password<br />
Password: (Enter a well-chosen password)<br />
Re-enter Password: (Enter the same password for confirmation)<br />
Password written in /etc/grsec/pw<br />
# gradm -E<br />
<br />
To disable the RBAC system, run gradm -D. If you are not allowed to, you first need to switch to the admin role:<br />
<br />
# gradm -a admin<br />
Password: (Enter your admin role password)<br />
# gradm -D<br />
<br />
If you want to leave the admin role, run gradm -u admin:<br />
<br />
# gradm -u admin<br />
<br />
== Generating a Policy ==<br />
<br />
The RBAC system comes with a great feature called "learning mode". The learning mode can generate an anticipatory least privilege policy for your system. This allows for time and money savings by being able to rapidly deploy multiple secure servers.<br />
<br />
To use the learning mode, activate it using gradm:<br />
<br />
# gradm -F -L /etc/grsec/learning.log<br />
<br />
Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate or any other heavy file i/o operation as this can really slow down the processing time.<br />
<br />
When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under {{ic|/etc/grsec/learning.roles}}:<br />
<br />
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles<br />
<br />
Audit the {{ic|/etc/grsec/learning.roles}} and save it as {{ic|/etc/grsec/policy}} (mode {{ic|0600}}) when you are finished.<br />
<br />
# mv /etc/grsec/learning.roles /etc/grsec/policy<br />
# chmod 0600 /etc/grsec/policy<br />
<br />
You will now be able to enable the RBAC system with your new learned policy.<br />
<br />
== Tweaking your Policy ==<br />
<br />
An interesting feature of grsecurity 2.x is Set Operation Support for the configuration file. Currently it supports unions, intersections and differences of sets (of objects in this case).<br />
<br />
define objset1 {<br />
/root/blah rw<br />
/root/blah2 r<br />
/root/blah3 x<br />
}<br />
<br />
define somename2 {<br />
/root/test1 rw<br />
/root/blah2 rw<br />
/root/test3 h<br />
}<br />
<br />
Here is an example of its use, and the resulting objects that will be added to your subject:<br />
<br />
subject /somebinary o<br />
$objset1 & $somename2<br />
<br />
The above would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah2 r<br />
<br />
This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.<br />
<br />
subject /somebinary o<br />
$objset1 | $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 rw<br />
/root/blah3 x<br />
/root/test1 rw<br />
/root/test3 h<br />
<br />
This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.<br />
<br />
subject /somebinary o<br />
$objset1 - $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 h<br />
/root/blah3 x<br />
<br />
This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.<br />
<br />
In some obscure pseudo-language you could see this as:<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained /tmp/blah r) )<br />
then<br />
$objset1 - $objset2 would contain /tmp/blah w<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained / rwx) )<br />
then <br />
$objset1 - $objset2 would contain /tmp/blah h<br />
<br />
As for order of precedence (from highest to lowest): "-, & |".<br />
<br />
If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:<br />
<br />
(($set1 - $set2) | $set3) & $set4<br />
<br />
= Using linux-pax-flags AUR Package =<br />
<br />
The linux-pax-flags program is what makes using PaX on Arch Linux easy as pie. When you run this program it will set the PaX flags for all the problematic programs for you. However, if you use some uncommon program it may have problems forcing you to set the paxctl flags yourself. You will most likely see something like {{ic|Denied RWX}} in journalctl. That means you will need to disable MPROTECT for the program {{ic|paxctl -cPEmRXS /usr/bin/bla}}<br />
<br />
After you find what PaX flags need to be set post a comment on the linux-pax-flags AUR package so it can be added.<br />
<br />
More extensive documentation of the linux-pax-flags utility is to be found on it's man page.<br />
<br />
= Tips and Tricks =<br />
<br />
Because you will not be able to change the PaX flags for a running program, and that the vast majority of programs which would need them are graphical, it is strongly advisable to not use a Graphical Login like GDM or KDM. Instead simply have the system drop you to a console to log in and use {{ic|startx}}. Then you will have a chance to set the PaX flags before anything starts. For the same reasons it is strongly advisable to update your system and run {{ic|linux-pax-flags}} right after boot, before running {{ic|startx}}.<br />
<br />
Grsecurity will harden /proc and /sys so your normal user will no longer be able to see the network status, becuase of this non of your desktop network monitors will work. Instead just install terminal based monitoring programs, such as [https://www.archlinux.org/packages/community/x86_64/nmon/ nmon] or [https://www.archlinux.org/packages/community/x86_64/nload/ nload] and run them as root, or as a user in the proc-trusted group.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Grsecurity&diff=272407Grsecurity2013-08-24T22:29:43Z<p>Hunterthomson: /* Build the Kernel Package */ Suggest only to disable sysctl support when you are sure you don't need it</p>
<hr />
<div>[[Category:Kernel]][[Category:Security]]<br />
The grsecurity project, hosted on https://grsecurity.net, provides various patches to the Linux kernel which enhance your system's overall security. grsecurity also ships with PaX which provides the most advanced memory protections of any OS. PaX invented ALSR and shows that it is only the tip of the iceberg. The RBAC Mandatory Access Control system of grsecurity was the inspriation for SELinux and AppArmor.<br />
<br />
In short, a Linux kernel hardened with grsecurity is the most hardened kernel you could have. Not even OpenBSD has all the hardening features it provides. A comprehensive list is maintained on the [http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options grsecurity features page] itself. However, the grsecurity Wiki is often out-of-date. The best way is to simply read the help text in the kernel config.<br />
<br />
Arch has all the utilities and kernel packages you need to run a grsecurity hardened Arch Linux system in the AUR. Arch even has a script called [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] which will make using PaX as painless as possible by setting all of the PaX flags for you.<br />
<br />
You can install the kernel either from a binary repository or - if you want more control - manually from the AUR.<br />
<br />
= Install binary packages =<br />
<br />
Add the [http://arsch.orgizm.net/ Arsch Arch Linux Repository] to your package sources and install the kernel with {{ic|pacman -Sy linux-grsec}} (or the PaX only kernel with {{ic|pacman -Sy linux-pax}}). Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
= Setup and Install from AUR =<br />
<br />
To build the AUR package we will follow this general game plan. First, download all needed files and check GPG signatures. Second, configure kernel and compile. Third, copy a backup of these files to the Root users home folder. Forth, install utilities needed for PaX and RBAC. Fifth, install the kernel package. Sixth, run linux-pax-flags to poke security holes in applications that will not run without them. Finally, reboot into your hardened system.<br />
<br />
== Download Files ==<br />
<br />
Download the packages<br />
[https://aur.archlinux.org/packages/linux-grsec/ linux-grsec]<br />
Or<br />
[https://aur.archlinux.org/packages/linux-grsec-lts/ linux-grsec-lts]<br />
<br />
Kernel linux-3.X.tar.xz and current patch-3.X.X.tar.xz also the .sign signature files for each.<br />
[https://www.kernel.org/pub/linux/kernel/v3.x/ kernel.org]<br />
<br />
Download the current grsecurity patch and Signatures<br />
[https://grsecurity.net/test.php grsecurity Test]<br />
Or<br />
[https://grsecurity.net/download_stable.php grsecurity Stable] for LTS kernel<br />
<br />
{{tip|The Grsecurity Test is in fact Stable. The Stable Grsecurity version is just for the LTS}}<br />
<br />
=== Verify The GPG Signatures ===<br />
<br />
With the .sign files in the same directory as the file it is a a signature of, verify the signature like so...<br />
<br />
$ gpg2 --verify linux-3.10.tar.sign<br />
<br />
== Setup Build Environment ==<br />
<br />
Unpack the linux-grsec.tar.gz and copy all the files into it<br />
<br />
$ tar xzf linux-grsec.tar.gz<br />
$ cp ~/Downloads/linux-3.10.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/patch-3.10.9.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/grsecurity-2.9.1-3.10.9-201308202015.patch ~/linux-grsec<br />
<br />
Change into the build directory<br />
<br />
$ cd ~/linux-grsec<br />
<br />
== Build the Kernel Package ==<br />
<br />
It is going to take a long time to build the kernel because it is based on the default Arch kernel config with has about ten times as make modules enabled then your system actually needs. However, it is a known working config and to eliminate any more variables it is advisable to just live with the extra build time.<br />
<br />
Build the package<br />
<br />
$ MENUCONFIG=2 makepkg<br />
<br />
You should be dropped into the ncurses GUI now. Navigate to the grsecurity settings to verify the configuration and/or change things as needed. These setting can be found in {{ic|Security options ---> Grsecurity ---> Customize Configuration --->}}<br />
<br />
For both Desktops and Servers after you are sure you will not need to change any of the Grsecurity settings with sysctl, disable {{ic|Sysctl support}} found in {{ic|Sysctl Support}}.<br />
<br />
If this kernel is for a Server also enable {{ic|Disable privileged I/O}} found in {{ic|Memory Protections}}.<br />
<br />
All other setting should be optimal as they are, so now exit out of the ncurses GUI config and Save. Now the package should start to build. If all goes well you will have two .pkg.tar.xz packages one for the kernel and one for the kernel-headers.<br />
<br />
=== Make a Backup ===<br />
<br />
Keep all linux-grsec.tar.gz files along with the grsecruity patch and compiled packages in the Root users home folder. That way you can roll back if needed. Every time a new grsecurity patch is release you will not be able to download outdated patches every again.<br />
<br />
# mkdir /root/3.10.9<br />
# cp -r /home/USER/linux-grsec /root/3.10.9<br />
<br />
== Install PaX and RBAC Utilities ==<br />
<br />
The AUR also has [https://aur.archlinux.org/packages/paxctl/ paxctl], [https://aur.archlinux.org/packages/gradm/ gradm], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] packages that you will need.<br />
<br />
For simplicities sake I will assume you are using yaourt to install package form the AUR, however any other way of installing these packages will work as well.<br />
<br />
$ yaourt -S linux-pax-flags paxctl gradm<br />
<br />
== Set PaX Flags ==<br />
<br />
Use the linux-pax-flags program to configure all the PaX flags for troublesome programs.<br />
More information can be found in the Using linux-pax-flags AUR Package section.<br />
<br />
# linux-pax-flags<br />
<br />
== Install Hardened Kernel ==<br />
<br />
Now that all the needed utilities are installed and the system is configured for PaX, install the hardened kernel and headers.<br />
<br />
# pacman -U /root/3.10.9/*.pkg.tar.xz<br />
<br />
Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
You should now be in your hardened system. Just make sure to run {{ic|linux-pax-flags}} after every time you update your system or install a new program and you should have a trouble free experience.<br />
<br />
= Manual Kernel Configuration =<br />
<br />
Throughout this document we will talk about kernel configuration using the kernel variables like CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. These are the variables that the kernel build process uses to determine if a certain feature needs to be compiled.<br />
<br />
When you configure your kernel through make menuconfig or similar, you receive a user interface through which you can select the various kernel options. If you select the Help button at a certain kernel feature you will see at the top that it lists such a kernel variable.<br />
<br />
You can therefore still configure your kernel as you like - with a bit of thinking. And if you can't find a certain option, there's always the possibility to edit /usr/src/linux/.config by hand :)<br />
<br />
Of course, to be able to select the various grsecurity kernel options, you must enable grsecurity in your kernel.<br />
See [[default grsecurity kernel configuration]]<br />
<br />
== PaX ==<br />
<br />
=== Fighting the Exploitation of Software Bugs ===<br />
<br />
PaX introduces a couple of security mechanisms that make it harder for attackers to exploit software bugs that involve memory corruption (so do not treat PaX as if it protects against all possible software bugs). The PaX introduction document talks about three possible exploit techniques:<br />
<br />
# introduce/execute arbitrary code<br />
# execute existing code out of original program order<br />
# execute existing code in original program order with arbitrary data<br />
<br />
One prevention method disallows executable code to be stored in writable memory. When we look at a process, it requires five memory regions:<br />
<br />
# a data section which contains the statically allocated and global data<br />
# a BSS region (Block Started by Symbol) which contains information about the zero-initialized data of the process<br />
# a code region, also called the text segment, which contains the executable instructions<br />
# a heap which contains the dynamically allocated memory<br />
# a stack which contains the local variables<br />
<br />
The first PaX prevention method, called NOEXEC, is meant to give control over the runtime code generation. It marks memory pages that do not contain executable code as non-executable. This means that the heap and the stack, which only contain variable data and shouldn't contain executable code, are marked as non-executable. Exploits that place code in these areas with the intention of running it will fail.<br />
<br />
NOEXEC does more than this actually, interested readers should focus their attention to the [http://pax.grsecurity.net/docs/noexec.txt PaX NOEXEC documentation].<br />
<br />
The second PaX prevention method, called ASLR (Address Space Layout Randomization), randomize the addresses given to memory requests. Where previously memory was assigned contiguously (which means exploits know where the tasks' memory regions are situated) ASLR randomizes this allocation, rendering techniques that rely on this information useless.<br />
<br />
More information about ASLR can be found [http://pax.grsecurity.net/docs/aslr.txt online].<br />
<br />
=== PaX kernel configuration ===<br />
<br />
<br />
The recommended kernel setting for PaX is:<br />
<br />
#<br />
# Security options<br />
#<br />
#<br />
# PaX<br />
#<br />
CONFIG_PAX=y<br />
#<br />
# PaX Control<br />
#<br />
# CONFIG_PAX_SOFTMODE is not set<br />
CONFIG_PAX_EI_PAX=y<br />
CONFIG_PAX_PT_PAX_FLAGS=y<br />
CONFIG_PAX_NO_ACL_FLAGS=y<br />
# CONFIG_PAX_HAVE_ACL_FLAGS is not set<br />
# CONFIG_PAX_HOOK_ACL_FLAGS is not set<br />
#<br />
# Non-executable pages<br />
#<br />
CONFIG_PAX_NOEXEC=y<br />
CONFIG_PAX_PAGEEXEC=y<br />
CONFIG_PAX_SEGMEXEC=y<br />
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set<br />
CONFIG_PAX_DEFAULT_SEGMEXEC=y<br />
CONFIG_PAX_EMUTRAMP=y<br />
CONFIG_PAX_MPROTECT=y<br />
# CONFIG_PAX_NOELFRELOCS is not set<br />
#<br />
# Address Space Layout Randomization<br />
#<br />
CONFIG_PAX_ASLR=y<br />
CONFIG_PAX_RANDKSTACK=y<br />
CONFIG_PAX_RANDUSTACK=y<br />
CONFIG_PAX_RANDMMAP=y<br />
#<br />
# Miscellaneous hardening features<br />
#<br />
CONFIG_PAX_MEMORY_SANITIZE=y<br />
CONFIG_PAX_MEMORY_UDEREF=y<br />
CONFIG_KEYS=y<br />
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_NETWORK_XFRM=y<br />
CONFIG_SECURITY_CAPABILITIES=m<br />
CONFIG_SECURITY_ROOTPLUG=m<br />
<br />
If you are running a non-x86 system you will observe that there is no CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC instead as it is the only non-exec implementation around.<br />
<br />
=== Controlling PaX ===<br />
<br />
Not all Linux applications are happy with the PaX security restrictions. These tools include xorg-x11, java, mplayer, xmms and others. If you plan on using them you can elevate the protections for these applications using chpax and paxctl. You can find they on AUR.<br />
<br />
You can also use pax-utils, which is a small toolbox which contains useful applications to administrate a PaX aware server. Find it on AUR.<br />
<br />
Interesting tools include scanelf and pspax:<br />
<br />
* With scanelf you can scan over library and binary directories and list the various permissions and ELF types that pertain to running an ideal pax/grsec setup<br />
* With pspax you can display PaX flags/capabilities/xattr from the kernel's perspective<br />
<br />
=== Verifying the PaX Settings ===<br />
<br />
Peter Busser has written a regression test suite called paxtest. This tool will check various cases of possible attack vectors and inform you of the result. When you run it, it will leave a logfile called paxtest.log in the current working directory.<br />
<br />
# paxtest<br />
Executable anonymous mapping : Killed<br />
Executable bss : Killed<br />
Executable data : Killed<br />
Executable heap : Killed<br />
Executable stack : Killed<br />
Executable anonymous mapping (mprotect) : Killed<br />
Executable bss (mprotect) : Killed<br />
Executable data (mprotect) : Killed<br />
Executable heap (mprotect) : Killed<br />
Executable stack (mprotect) : Killed<br />
Executable shared library bss (mprotect) : Killed<br />
Executable shared library data (mprotect): Killed<br />
Writable text segments : Killed<br />
Anonymous mapping randomisation test : 16 bits (guessed)<br />
Heap randomisation test (ET_EXEC) : 13 bits (guessed)<br />
Heap randomisation test (ET_DYN) : 25 bits (guessed)<br />
Main executable randomisation (ET_EXEC) : 16 bits (guessed)<br />
Main executable randomisation (ET_DYN) : 17 bits (guessed)<br />
Shared library randomisation test : 16 bits (guessed)<br />
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)<br />
Stack randomisation test (PAGEEXEC) : No randomisation<br />
Return to function (strcpy) : Vulnerable<br />
Return to function (memcpy) : Vulnerable<br />
Return to function (strcpy, RANDEXEC) : Killed<br />
Return to function (memcpy, RANDEXEC) : Killed<br />
Executable shared library bss : Killed<br />
Executable shared library data : Killed<br />
<br />
In the above example run you notice that:<br />
<br />
* strcpy and memcpy are listed as Vulnerable. This is expected and normal - it is simply showing the need for a technology such as ProPolice/SSP<br />
* there is no randomization for PAGEEXEC. This is normal since our recommended x86 kernel configuration didn't activate the PAGEEXEC setting. However, on arches that support a true NX (non-executable) bit (most of them do, including x86_64), PAGEEXEC is the only method available for NOEXEC and has no performance hit.<br />
<br />
== Filesystem Protection ==<br />
<br />
=== Fighting Chroot and Filesystem Abuse ===<br />
<br />
Grsecurity2 includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on /proc usage, chrooting, linking, etc.<br />
<br />
=== Kernel Configuration ===<br />
<br />
We recommend the following grsecurity kernel configuration for filesystem protection:<br />
<br />
#<br />
# Filesystem Protections<br />
#<br />
CONFIG_GRKERNSEC_PROC=y<br />
# CONFIG_GRKERNSEC_PROC_USER is not set<br />
CONFIG_GRKERNSEC_PROC_USERGROUP=y<br />
CONFIG_GRKERNSEC_PROC_GID=3<br />
CONFIG_GRKERNSEC_PROC_ADD=y<br />
CONFIG_GRKERNSEC_LINK=y<br />
CONFIG_GRKERNSEC_FIFO=y<br />
CONFIG_GRKERNSEC_CHROOT=y<br />
CONFIG_GRKERNSEC_CHROOT_MOUNT=y<br />
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y<br />
CONFIG_GRKERNSEC_CHROOT_PIVOT=y<br />
CONFIG_GRKERNSEC_CHROOT_CHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_CHMOD=y<br />
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_MKNOD=y<br />
CONFIG_GRKERNSEC_CHROOT_SHMAT=y<br />
CONFIG_GRKERNSEC_CHROOT_UNIX=y<br />
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y<br />
CONFIG_GRKERNSEC_CHROOT_NICE=y<br />
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y<br />
CONFIG_GRKERNSEC_CHROOT_CAPS=y<br />
<br />
=== Triggering the Security Mechanism ===<br />
<br />
When you're using a kernel compiled with the above (or similar) settings, you will get the option to enable/disable many of the options through the /proc filesystem or via sysctl.<br />
<br />
The example below shows an excerpt of a typical /etc/sysctl.conf:<br />
<br />
kernel.grsecurity.chroot_deny_sysctl = 1<br />
kernel.grsecurity.chroot_caps = 1<br />
kernel.grsecurity.chroot_execlog = 0<br />
kernel.grsecurity.chroot_restrict_nice = 1<br />
kernel.grsecurity.chroot_deny_mknod = 1<br />
kernel.grsecurity.chroot_deny_chmod = 1<br />
kernel.grsecurity.chroot_enforce_chdir = 1<br />
kernel.grsecurity.chroot_deny_pivot = 1<br />
kernel.grsecurity.chroot_deny_chroot = 1<br />
kernel.grsecurity.chroot_deny_fchdir = 1<br />
kernel.grsecurity.chroot_deny_mount = 1<br />
kernel.grsecurity.chroot_deny_unix = 1<br />
kernel.grsecurity.chroot_deny_shmat = 1<br />
<br />
You can enable or disable settings at will using the sysctl command:<br />
<br />
(Toggling the exec_logging feature ON)<br />
# sysctl -w kernel.grsecurity.exec_logging = 1<br />
(Toggling the exec_logging feature OFF)<br />
# sysctl -w kernel.grsecurity.exec_logging = 0<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
== Kernel Auditing ==<br />
<br />
=== Extend your System's Logging Facilities ===<br />
<br />
grsecurity adds extra functionality to the kernel pertaining the logging. With grsecurity's Kernel Auditing the kernel informs you when applications are started, devices (un)mounted, etc.<br />
<br />
=== The various Kernel Audit Settings ===<br />
<br />
The following kernel configuration section can be used to enable grsecurity's Kernel Audit Settings:<br />
<br />
#<br />
# Kernel Auditing<br />
#<br />
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set<br />
CONFIG_GRKERNSEC_EXECLOG=y<br />
CONFIG_GRKERNSEC_RESLOG=y<br />
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y<br />
CONFIG_GRKERNSEC_AUDIT_CHDIR=y<br />
CONFIG_GRKERNSEC_AUDIT_MOUNT=y<br />
CONFIG_GRKERNSEC_AUDIT_IPC=y<br />
CONFIG_GRKERNSEC_SIGNAL=y<br />
CONFIG_GRKERNSEC_FORKFAIL=y<br />
CONFIG_GRKERNSEC_TIME=y<br />
CONFIG_GRKERNSEC_PROC_IPADDR=y<br />
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y<br />
<br />
== Process Restrictions ==<br />
<br />
=== Executable Protection ===<br />
<br />
With grsecurity you can restrict executables. Since most exploits work through one or more running processes this protection can save your system's health.<br />
<br />
=== Network Protection ===<br />
<br />
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity includes randomization patches to counter these attacks. Apart from these you can also enable socket restrictions, disallowing certain groups network access alltogether.<br />
<br />
=== Kernel Settings ===<br />
<br />
The following kernel settings enable various executable and network protections:<br />
<br />
#<br />
# Executable Protections<br />
#<br />
CONFIG_GRKERNSEC_EXECVE=y<br />
CONFIG_GRKERNSEC_DMESG=y<br />
CONFIG_GRKERNSEC_RANDPID=y<br />
CONFIG_GRKERNSEC_TPE=y<br />
CONFIG_GRKERNSEC_TPE_ALL=y<br />
CONFIG_GRKERNSEC_TPE_GID=100<br />
<br />
#<br />
# Network Protections<br />
#<br />
CONFIG_GRKERNSEC_RANDNET=y<br />
CONFIG_GRKERNSEC_RANDISN=y<br />
CONFIG_GRKERNSEC_RANDID=y<br />
CONFIG_GRKERNSEC_RANDSRC=y<br />
CONFIG_GRKERNSEC_RANDRPC=y<br />
# CONFIG_GRKERNSEC_SOCKET is not set<br />
<br />
= RBAC =<br />
<br />
Role Based Access Control<br />
<br />
There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.<br />
<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
== Configuring the Kernel ==<br />
<br />
The recommended kernel setting for RBAC is:<br />
<br />
#<br />
# Role Based Access Control Options<br />
#<br />
CONFIG_GRKERNSEC_ACL_HIDEKERN=y<br />
CONFIG_GRKERNSEC_ACL_MAXTRIES=3<br />
CONFIG_GRKERNSEC_ACL_TIMEOUT=30<br />
<br />
== Working with gradm ==<br />
<br />
gradm is a tool which allows you to administer and maintain a policy for your system. With it, you can enable or disable the RBAC system, reload the RBAC roles, change your role, set a password for admin mode, etc.<br />
<br />
When you install gradm a default policy will be installed in /etc/grsec/policy. Please see in AUR for gradm package.<br />
<br />
By default, the RBAC policies are not activated. It is the sysadmin's job to determine when the system should have an RBAC policy enforced. Before activating the RBAC system you should set an admin password.<br />
<br />
# gradm -P admin<br />
Setting up grsecurity RBAC password<br />
Password: (Enter a well-chosen password)<br />
Re-enter Password: (Enter the same password for confirmation)<br />
Password written in /etc/grsec/pw<br />
# gradm -E<br />
<br />
To disable the RBAC system, run gradm -D. If you are not allowed to, you first need to switch to the admin role:<br />
<br />
# gradm -a admin<br />
Password: (Enter your admin role password)<br />
# gradm -D<br />
<br />
If you want to leave the admin role, run gradm -u admin:<br />
<br />
# gradm -u admin<br />
<br />
== Generating a Policy ==<br />
<br />
The RBAC system comes with a great feature called "learning mode". The learning mode can generate an anticipatory least privilege policy for your system. This allows for time and money savings by being able to rapidly deploy multiple secure servers.<br />
<br />
To use the learning mode, activate it using gradm:<br />
<br />
# gradm -F -L /etc/grsec/learning.log<br />
<br />
Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate or any other heavy file i/o operation as this can really slow down the processing time.<br />
<br />
When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under {{ic|/etc/grsec/learning.roles}}:<br />
<br />
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles<br />
<br />
Audit the {{ic|/etc/grsec/learning.roles}} and save it as {{ic|/etc/grsec/policy}} (mode {{ic|0600}}) when you are finished.<br />
<br />
# mv /etc/grsec/learning.roles /etc/grsec/policy<br />
# chmod 0600 /etc/grsec/policy<br />
<br />
You will now be able to enable the RBAC system with your new learned policy.<br />
<br />
== Tweaking your Policy ==<br />
<br />
An interesting feature of grsecurity 2.x is Set Operation Support for the configuration file. Currently it supports unions, intersections and differences of sets (of objects in this case).<br />
<br />
define objset1 {<br />
/root/blah rw<br />
/root/blah2 r<br />
/root/blah3 x<br />
}<br />
<br />
define somename2 {<br />
/root/test1 rw<br />
/root/blah2 rw<br />
/root/test3 h<br />
}<br />
<br />
Here is an example of its use, and the resulting objects that will be added to your subject:<br />
<br />
subject /somebinary o<br />
$objset1 & $somename2<br />
<br />
The above would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah2 r<br />
<br />
This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.<br />
<br />
subject /somebinary o<br />
$objset1 | $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 rw<br />
/root/blah3 x<br />
/root/test1 rw<br />
/root/test3 h<br />
<br />
This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.<br />
<br />
subject /somebinary o<br />
$objset1 - $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 h<br />
/root/blah3 x<br />
<br />
This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.<br />
<br />
In some obscure pseudo-language you could see this as:<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained /tmp/blah r) )<br />
then<br />
$objset1 - $objset2 would contain /tmp/blah w<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained / rwx) )<br />
then <br />
$objset1 - $objset2 would contain /tmp/blah h<br />
<br />
As for order of precedence (from highest to lowest): "-, & |".<br />
<br />
If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:<br />
<br />
(($set1 - $set2) | $set3) & $set4<br />
<br />
= Using linux-pax-flags AUR Package =<br />
<br />
The linux-pax-flags program is what makes using PaX on Arch Linux easy as pie. When you run this program it will set the PaX flags for all the problematic programs for you. However, if you use some uncommon program it may have problems forcing you to set the paxctl flags yourself. You will most likely see something like {{ic|Denied RWX}} in journalctl. That means you will need to disable MPROTECT for the program {{ic|paxctl -cPEmRXS /usr/bin/bla}}<br />
<br />
After you find what PaX flags need to be set post a comment on the linux-pax-flags AUR package so it can be added.<br />
<br />
More extensive documentation of the linux-pax-flags utility is to be found on it's man page.<br />
<br />
= Tips and Tricks =<br />
<br />
Because you will not be able to change the PaX flags for a running program, and that the vast majority of programs which would need them are graphical, it is strongly advisable to not use a Graphical Login like GDM or KDM. Instead simply have the system drop you to a console to log in and use {{ic|startx}}. Then you will have a chance to set the PaX flags before anything starts. For the same reasons it is strongly advisable to update your system and run {{ic|linux-pax-flags}} right after boot, before running {{ic|startx}}.<br />
<br />
Grsecurity will harden /proc and /sys so your normal user will no longer be able to see the network status, becuase of this non of your desktop network monitors will work. Instead just install terminal based monitoring programs, such as [https://www.archlinux.org/packages/community/x86_64/nmon/ nmon] or [https://www.archlinux.org/packages/community/x86_64/nload/ nload] and run them as root, or as a user in the proc-trusted group.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Grsecurity&diff=272406Grsecurity2013-08-24T22:26:54Z<p>Hunterthomson: /* Install Hardened Kernel */ Added bootloader setup</p>
<hr />
<div>[[Category:Kernel]][[Category:Security]]<br />
The grsecurity project, hosted on https://grsecurity.net, provides various patches to the Linux kernel which enhance your system's overall security. grsecurity also ships with PaX which provides the most advanced memory protections of any OS. PaX invented ALSR and shows that it is only the tip of the iceberg. The RBAC Mandatory Access Control system of grsecurity was the inspriation for SELinux and AppArmor.<br />
<br />
In short, a Linux kernel hardened with grsecurity is the most hardened kernel you could have. Not even OpenBSD has all the hardening features it provides. A comprehensive list is maintained on the [http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options grsecurity features page] itself. However, the grsecurity Wiki is often out-of-date. The best way is to simply read the help text in the kernel config.<br />
<br />
Arch has all the utilities and kernel packages you need to run a grsecurity hardened Arch Linux system in the AUR. Arch even has a script called [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] which will make using PaX as painless as possible by setting all of the PaX flags for you.<br />
<br />
You can install the kernel either from a binary repository or - if you want more control - manually from the AUR.<br />
<br />
= Install binary packages =<br />
<br />
Add the [http://arsch.orgizm.net/ Arsch Arch Linux Repository] to your package sources and install the kernel with {{ic|pacman -Sy linux-grsec}} (or the PaX only kernel with {{ic|pacman -Sy linux-pax}}). Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
= Setup and Install from AUR =<br />
<br />
To build the AUR package we will follow this general game plan. First, download all needed files and check GPG signatures. Second, configure kernel and compile. Third, copy a backup of these files to the Root users home folder. Forth, install utilities needed for PaX and RBAC. Fifth, install the kernel package. Sixth, run linux-pax-flags to poke security holes in applications that will not run without them. Finally, reboot into your hardened system.<br />
<br />
== Download Files ==<br />
<br />
Download the packages<br />
[https://aur.archlinux.org/packages/linux-grsec/ linux-grsec]<br />
Or<br />
[https://aur.archlinux.org/packages/linux-grsec-lts/ linux-grsec-lts]<br />
<br />
Kernel linux-3.X.tar.xz and current patch-3.X.X.tar.xz also the .sign signature files for each.<br />
[https://www.kernel.org/pub/linux/kernel/v3.x/ kernel.org]<br />
<br />
Download the current grsecurity patch and Signatures<br />
[https://grsecurity.net/test.php grsecurity Test]<br />
Or<br />
[https://grsecurity.net/download_stable.php grsecurity Stable] for LTS kernel<br />
<br />
{{tip|The Grsecurity Test is in fact Stable. The Stable Grsecurity version is just for the LTS}}<br />
<br />
=== Verify The GPG Signatures ===<br />
<br />
With the .sign files in the same directory as the file it is a a signature of, verify the signature like so...<br />
<br />
$ gpg2 --verify linux-3.10.tar.sign<br />
<br />
== Setup Build Environment ==<br />
<br />
Unpack the linux-grsec.tar.gz and copy all the files into it<br />
<br />
$ tar xzf linux-grsec.tar.gz<br />
$ cp ~/Downloads/linux-3.10.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/patch-3.10.9.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/grsecurity-2.9.1-3.10.9-201308202015.patch ~/linux-grsec<br />
<br />
Change into the build directory<br />
<br />
$ cd ~/linux-grsec<br />
<br />
== Build the Kernel Package ==<br />
<br />
It is going to take a long time to build the kernel because it is based on the default Arch kernel config with has about ten times as make modules enabled then your system actually needs. However, it is a known working config and to eliminate any more variables it is advisable to just live with the extra build time.<br />
<br />
Build the package<br />
<br />
$ MENUCONFIG=2 makepkg<br />
<br />
You should be dropped into the ncurses GUI now. Navigate to the grsecurity settings to verify the configuration and/or change things as needed. These setting can be found in {{ic|Security options ---> Grsecurity ---> Customize Configuration --->}}<br />
<br />
For both Desktops and Servers disable {{ic|Sysctl support}} found in {{ic|Sysctl Support}}.<br />
If this kernel is for a Server also enable {{ic|Disable privileged I/O}} found in {{ic|Memory Protections}}.<br />
<br />
All other setting should be optimal as they are, so now exit out of the ncurses GUI config and Save. Now the package should start to build. If all goes well you will have two .pkg.tar.xz packages one for the kernel and one for the kernel-headers.<br />
<br />
=== Make a Backup ===<br />
<br />
Keep all linux-grsec.tar.gz files along with the grsecruity patch and compiled packages in the Root users home folder. That way you can roll back if needed. Every time a new grsecurity patch is release you will not be able to download outdated patches every again.<br />
<br />
# mkdir /root/3.10.9<br />
# cp -r /home/USER/linux-grsec /root/3.10.9<br />
<br />
== Install PaX and RBAC Utilities ==<br />
<br />
The AUR also has [https://aur.archlinux.org/packages/paxctl/ paxctl], [https://aur.archlinux.org/packages/gradm/ gradm], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] packages that you will need.<br />
<br />
For simplicities sake I will assume you are using yaourt to install package form the AUR, however any other way of installing these packages will work as well.<br />
<br />
$ yaourt -S linux-pax-flags paxctl gradm<br />
<br />
== Set PaX Flags ==<br />
<br />
Use the linux-pax-flags program to configure all the PaX flags for troublesome programs.<br />
More information can be found in the Using linux-pax-flags AUR Package section.<br />
<br />
# linux-pax-flags<br />
<br />
== Install Hardened Kernel ==<br />
<br />
Now that all the needed utilities are installed and the system is configured for PaX, install the hardened kernel and headers.<br />
<br />
# pacman -U /root/3.10.9/*.pkg.tar.xz<br />
<br />
Finish by adding the new kernel to your bootloader menu (with {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} for example) and reboot.<br />
<br />
You should now be in your hardened system. Just make sure to run {{ic|linux-pax-flags}} after every time you update your system or install a new program and you should have a trouble free experience.<br />
<br />
= Manual Kernel Configuration =<br />
<br />
Throughout this document we will talk about kernel configuration using the kernel variables like CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. These are the variables that the kernel build process uses to determine if a certain feature needs to be compiled.<br />
<br />
When you configure your kernel through make menuconfig or similar, you receive a user interface through which you can select the various kernel options. If you select the Help button at a certain kernel feature you will see at the top that it lists such a kernel variable.<br />
<br />
You can therefore still configure your kernel as you like - with a bit of thinking. And if you can't find a certain option, there's always the possibility to edit /usr/src/linux/.config by hand :)<br />
<br />
Of course, to be able to select the various grsecurity kernel options, you must enable grsecurity in your kernel.<br />
See [[default grsecurity kernel configuration]]<br />
<br />
== PaX ==<br />
<br />
=== Fighting the Exploitation of Software Bugs ===<br />
<br />
PaX introduces a couple of security mechanisms that make it harder for attackers to exploit software bugs that involve memory corruption (so do not treat PaX as if it protects against all possible software bugs). The PaX introduction document talks about three possible exploit techniques:<br />
<br />
# introduce/execute arbitrary code<br />
# execute existing code out of original program order<br />
# execute existing code in original program order with arbitrary data<br />
<br />
One prevention method disallows executable code to be stored in writable memory. When we look at a process, it requires five memory regions:<br />
<br />
# a data section which contains the statically allocated and global data<br />
# a BSS region (Block Started by Symbol) which contains information about the zero-initialized data of the process<br />
# a code region, also called the text segment, which contains the executable instructions<br />
# a heap which contains the dynamically allocated memory<br />
# a stack which contains the local variables<br />
<br />
The first PaX prevention method, called NOEXEC, is meant to give control over the runtime code generation. It marks memory pages that do not contain executable code as non-executable. This means that the heap and the stack, which only contain variable data and shouldn't contain executable code, are marked as non-executable. Exploits that place code in these areas with the intention of running it will fail.<br />
<br />
NOEXEC does more than this actually, interested readers should focus their attention to the [http://pax.grsecurity.net/docs/noexec.txt PaX NOEXEC documentation].<br />
<br />
The second PaX prevention method, called ASLR (Address Space Layout Randomization), randomize the addresses given to memory requests. Where previously memory was assigned contiguously (which means exploits know where the tasks' memory regions are situated) ASLR randomizes this allocation, rendering techniques that rely on this information useless.<br />
<br />
More information about ASLR can be found [http://pax.grsecurity.net/docs/aslr.txt online].<br />
<br />
=== PaX kernel configuration ===<br />
<br />
<br />
The recommended kernel setting for PaX is:<br />
<br />
#<br />
# Security options<br />
#<br />
#<br />
# PaX<br />
#<br />
CONFIG_PAX=y<br />
#<br />
# PaX Control<br />
#<br />
# CONFIG_PAX_SOFTMODE is not set<br />
CONFIG_PAX_EI_PAX=y<br />
CONFIG_PAX_PT_PAX_FLAGS=y<br />
CONFIG_PAX_NO_ACL_FLAGS=y<br />
# CONFIG_PAX_HAVE_ACL_FLAGS is not set<br />
# CONFIG_PAX_HOOK_ACL_FLAGS is not set<br />
#<br />
# Non-executable pages<br />
#<br />
CONFIG_PAX_NOEXEC=y<br />
CONFIG_PAX_PAGEEXEC=y<br />
CONFIG_PAX_SEGMEXEC=y<br />
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set<br />
CONFIG_PAX_DEFAULT_SEGMEXEC=y<br />
CONFIG_PAX_EMUTRAMP=y<br />
CONFIG_PAX_MPROTECT=y<br />
# CONFIG_PAX_NOELFRELOCS is not set<br />
#<br />
# Address Space Layout Randomization<br />
#<br />
CONFIG_PAX_ASLR=y<br />
CONFIG_PAX_RANDKSTACK=y<br />
CONFIG_PAX_RANDUSTACK=y<br />
CONFIG_PAX_RANDMMAP=y<br />
#<br />
# Miscellaneous hardening features<br />
#<br />
CONFIG_PAX_MEMORY_SANITIZE=y<br />
CONFIG_PAX_MEMORY_UDEREF=y<br />
CONFIG_KEYS=y<br />
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_NETWORK_XFRM=y<br />
CONFIG_SECURITY_CAPABILITIES=m<br />
CONFIG_SECURITY_ROOTPLUG=m<br />
<br />
If you are running a non-x86 system you will observe that there is no CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC instead as it is the only non-exec implementation around.<br />
<br />
=== Controlling PaX ===<br />
<br />
Not all Linux applications are happy with the PaX security restrictions. These tools include xorg-x11, java, mplayer, xmms and others. If you plan on using them you can elevate the protections for these applications using chpax and paxctl. You can find they on AUR.<br />
<br />
You can also use pax-utils, which is a small toolbox which contains useful applications to administrate a PaX aware server. Find it on AUR.<br />
<br />
Interesting tools include scanelf and pspax:<br />
<br />
* With scanelf you can scan over library and binary directories and list the various permissions and ELF types that pertain to running an ideal pax/grsec setup<br />
* With pspax you can display PaX flags/capabilities/xattr from the kernel's perspective<br />
<br />
=== Verifying the PaX Settings ===<br />
<br />
Peter Busser has written a regression test suite called paxtest. This tool will check various cases of possible attack vectors and inform you of the result. When you run it, it will leave a logfile called paxtest.log in the current working directory.<br />
<br />
# paxtest<br />
Executable anonymous mapping : Killed<br />
Executable bss : Killed<br />
Executable data : Killed<br />
Executable heap : Killed<br />
Executable stack : Killed<br />
Executable anonymous mapping (mprotect) : Killed<br />
Executable bss (mprotect) : Killed<br />
Executable data (mprotect) : Killed<br />
Executable heap (mprotect) : Killed<br />
Executable stack (mprotect) : Killed<br />
Executable shared library bss (mprotect) : Killed<br />
Executable shared library data (mprotect): Killed<br />
Writable text segments : Killed<br />
Anonymous mapping randomisation test : 16 bits (guessed)<br />
Heap randomisation test (ET_EXEC) : 13 bits (guessed)<br />
Heap randomisation test (ET_DYN) : 25 bits (guessed)<br />
Main executable randomisation (ET_EXEC) : 16 bits (guessed)<br />
Main executable randomisation (ET_DYN) : 17 bits (guessed)<br />
Shared library randomisation test : 16 bits (guessed)<br />
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)<br />
Stack randomisation test (PAGEEXEC) : No randomisation<br />
Return to function (strcpy) : Vulnerable<br />
Return to function (memcpy) : Vulnerable<br />
Return to function (strcpy, RANDEXEC) : Killed<br />
Return to function (memcpy, RANDEXEC) : Killed<br />
Executable shared library bss : Killed<br />
Executable shared library data : Killed<br />
<br />
In the above example run you notice that:<br />
<br />
* strcpy and memcpy are listed as Vulnerable. This is expected and normal - it is simply showing the need for a technology such as ProPolice/SSP<br />
* there is no randomization for PAGEEXEC. This is normal since our recommended x86 kernel configuration didn't activate the PAGEEXEC setting. However, on arches that support a true NX (non-executable) bit (most of them do, including x86_64), PAGEEXEC is the only method available for NOEXEC and has no performance hit.<br />
<br />
== Filesystem Protection ==<br />
<br />
=== Fighting Chroot and Filesystem Abuse ===<br />
<br />
Grsecurity2 includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on /proc usage, chrooting, linking, etc.<br />
<br />
=== Kernel Configuration ===<br />
<br />
We recommend the following grsecurity kernel configuration for filesystem protection:<br />
<br />
#<br />
# Filesystem Protections<br />
#<br />
CONFIG_GRKERNSEC_PROC=y<br />
# CONFIG_GRKERNSEC_PROC_USER is not set<br />
CONFIG_GRKERNSEC_PROC_USERGROUP=y<br />
CONFIG_GRKERNSEC_PROC_GID=3<br />
CONFIG_GRKERNSEC_PROC_ADD=y<br />
CONFIG_GRKERNSEC_LINK=y<br />
CONFIG_GRKERNSEC_FIFO=y<br />
CONFIG_GRKERNSEC_CHROOT=y<br />
CONFIG_GRKERNSEC_CHROOT_MOUNT=y<br />
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y<br />
CONFIG_GRKERNSEC_CHROOT_PIVOT=y<br />
CONFIG_GRKERNSEC_CHROOT_CHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_CHMOD=y<br />
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_MKNOD=y<br />
CONFIG_GRKERNSEC_CHROOT_SHMAT=y<br />
CONFIG_GRKERNSEC_CHROOT_UNIX=y<br />
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y<br />
CONFIG_GRKERNSEC_CHROOT_NICE=y<br />
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y<br />
CONFIG_GRKERNSEC_CHROOT_CAPS=y<br />
<br />
=== Triggering the Security Mechanism ===<br />
<br />
When you're using a kernel compiled with the above (or similar) settings, you will get the option to enable/disable many of the options through the /proc filesystem or via sysctl.<br />
<br />
The example below shows an excerpt of a typical /etc/sysctl.conf:<br />
<br />
kernel.grsecurity.chroot_deny_sysctl = 1<br />
kernel.grsecurity.chroot_caps = 1<br />
kernel.grsecurity.chroot_execlog = 0<br />
kernel.grsecurity.chroot_restrict_nice = 1<br />
kernel.grsecurity.chroot_deny_mknod = 1<br />
kernel.grsecurity.chroot_deny_chmod = 1<br />
kernel.grsecurity.chroot_enforce_chdir = 1<br />
kernel.grsecurity.chroot_deny_pivot = 1<br />
kernel.grsecurity.chroot_deny_chroot = 1<br />
kernel.grsecurity.chroot_deny_fchdir = 1<br />
kernel.grsecurity.chroot_deny_mount = 1<br />
kernel.grsecurity.chroot_deny_unix = 1<br />
kernel.grsecurity.chroot_deny_shmat = 1<br />
<br />
You can enable or disable settings at will using the sysctl command:<br />
<br />
(Toggling the exec_logging feature ON)<br />
# sysctl -w kernel.grsecurity.exec_logging = 1<br />
(Toggling the exec_logging feature OFF)<br />
# sysctl -w kernel.grsecurity.exec_logging = 0<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
== Kernel Auditing ==<br />
<br />
=== Extend your System's Logging Facilities ===<br />
<br />
grsecurity adds extra functionality to the kernel pertaining the logging. With grsecurity's Kernel Auditing the kernel informs you when applications are started, devices (un)mounted, etc.<br />
<br />
=== The various Kernel Audit Settings ===<br />
<br />
The following kernel configuration section can be used to enable grsecurity's Kernel Audit Settings:<br />
<br />
#<br />
# Kernel Auditing<br />
#<br />
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set<br />
CONFIG_GRKERNSEC_EXECLOG=y<br />
CONFIG_GRKERNSEC_RESLOG=y<br />
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y<br />
CONFIG_GRKERNSEC_AUDIT_CHDIR=y<br />
CONFIG_GRKERNSEC_AUDIT_MOUNT=y<br />
CONFIG_GRKERNSEC_AUDIT_IPC=y<br />
CONFIG_GRKERNSEC_SIGNAL=y<br />
CONFIG_GRKERNSEC_FORKFAIL=y<br />
CONFIG_GRKERNSEC_TIME=y<br />
CONFIG_GRKERNSEC_PROC_IPADDR=y<br />
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y<br />
<br />
== Process Restrictions ==<br />
<br />
=== Executable Protection ===<br />
<br />
With grsecurity you can restrict executables. Since most exploits work through one or more running processes this protection can save your system's health.<br />
<br />
=== Network Protection ===<br />
<br />
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity includes randomization patches to counter these attacks. Apart from these you can also enable socket restrictions, disallowing certain groups network access alltogether.<br />
<br />
=== Kernel Settings ===<br />
<br />
The following kernel settings enable various executable and network protections:<br />
<br />
#<br />
# Executable Protections<br />
#<br />
CONFIG_GRKERNSEC_EXECVE=y<br />
CONFIG_GRKERNSEC_DMESG=y<br />
CONFIG_GRKERNSEC_RANDPID=y<br />
CONFIG_GRKERNSEC_TPE=y<br />
CONFIG_GRKERNSEC_TPE_ALL=y<br />
CONFIG_GRKERNSEC_TPE_GID=100<br />
<br />
#<br />
# Network Protections<br />
#<br />
CONFIG_GRKERNSEC_RANDNET=y<br />
CONFIG_GRKERNSEC_RANDISN=y<br />
CONFIG_GRKERNSEC_RANDID=y<br />
CONFIG_GRKERNSEC_RANDSRC=y<br />
CONFIG_GRKERNSEC_RANDRPC=y<br />
# CONFIG_GRKERNSEC_SOCKET is not set<br />
<br />
= RBAC =<br />
<br />
Role Based Access Control<br />
<br />
There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.<br />
<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
== Configuring the Kernel ==<br />
<br />
The recommended kernel setting for RBAC is:<br />
<br />
#<br />
# Role Based Access Control Options<br />
#<br />
CONFIG_GRKERNSEC_ACL_HIDEKERN=y<br />
CONFIG_GRKERNSEC_ACL_MAXTRIES=3<br />
CONFIG_GRKERNSEC_ACL_TIMEOUT=30<br />
<br />
== Working with gradm ==<br />
<br />
gradm is a tool which allows you to administer and maintain a policy for your system. With it, you can enable or disable the RBAC system, reload the RBAC roles, change your role, set a password for admin mode, etc.<br />
<br />
When you install gradm a default policy will be installed in /etc/grsec/policy. Please see in AUR for gradm package.<br />
<br />
By default, the RBAC policies are not activated. It is the sysadmin's job to determine when the system should have an RBAC policy enforced. Before activating the RBAC system you should set an admin password.<br />
<br />
# gradm -P admin<br />
Setting up grsecurity RBAC password<br />
Password: (Enter a well-chosen password)<br />
Re-enter Password: (Enter the same password for confirmation)<br />
Password written in /etc/grsec/pw<br />
# gradm -E<br />
<br />
To disable the RBAC system, run gradm -D. If you are not allowed to, you first need to switch to the admin role:<br />
<br />
# gradm -a admin<br />
Password: (Enter your admin role password)<br />
# gradm -D<br />
<br />
If you want to leave the admin role, run gradm -u admin:<br />
<br />
# gradm -u admin<br />
<br />
== Generating a Policy ==<br />
<br />
The RBAC system comes with a great feature called "learning mode". The learning mode can generate an anticipatory least privilege policy for your system. This allows for time and money savings by being able to rapidly deploy multiple secure servers.<br />
<br />
To use the learning mode, activate it using gradm:<br />
<br />
# gradm -F -L /etc/grsec/learning.log<br />
<br />
Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate or any other heavy file i/o operation as this can really slow down the processing time.<br />
<br />
When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under {{ic|/etc/grsec/learning.roles}}:<br />
<br />
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles<br />
<br />
Audit the {{ic|/etc/grsec/learning.roles}} and save it as {{ic|/etc/grsec/policy}} (mode {{ic|0600}}) when you are finished.<br />
<br />
# mv /etc/grsec/learning.roles /etc/grsec/policy<br />
# chmod 0600 /etc/grsec/policy<br />
<br />
You will now be able to enable the RBAC system with your new learned policy.<br />
<br />
== Tweaking your Policy ==<br />
<br />
An interesting feature of grsecurity 2.x is Set Operation Support for the configuration file. Currently it supports unions, intersections and differences of sets (of objects in this case).<br />
<br />
define objset1 {<br />
/root/blah rw<br />
/root/blah2 r<br />
/root/blah3 x<br />
}<br />
<br />
define somename2 {<br />
/root/test1 rw<br />
/root/blah2 rw<br />
/root/test3 h<br />
}<br />
<br />
Here is an example of its use, and the resulting objects that will be added to your subject:<br />
<br />
subject /somebinary o<br />
$objset1 & $somename2<br />
<br />
The above would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah2 r<br />
<br />
This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.<br />
<br />
subject /somebinary o<br />
$objset1 | $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 rw<br />
/root/blah3 x<br />
/root/test1 rw<br />
/root/test3 h<br />
<br />
This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.<br />
<br />
subject /somebinary o<br />
$objset1 - $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 h<br />
/root/blah3 x<br />
<br />
This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.<br />
<br />
In some obscure pseudo-language you could see this as:<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained /tmp/blah r) )<br />
then<br />
$objset1 - $objset2 would contain /tmp/blah w<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained / rwx) )<br />
then <br />
$objset1 - $objset2 would contain /tmp/blah h<br />
<br />
As for order of precedence (from highest to lowest): "-, & |".<br />
<br />
If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:<br />
<br />
(($set1 - $set2) | $set3) & $set4<br />
<br />
= Using linux-pax-flags AUR Package =<br />
<br />
The linux-pax-flags program is what makes using PaX on Arch Linux easy as pie. When you run this program it will set the PaX flags for all the problematic programs for you. However, if you use some uncommon program it may have problems forcing you to set the paxctl flags yourself. You will most likely see something like {{ic|Denied RWX}} in journalctl. That means you will need to disable MPROTECT for the program {{ic|paxctl -cPEmRXS /usr/bin/bla}}<br />
<br />
After you find what PaX flags need to be set post a comment on the linux-pax-flags AUR package so it can be added.<br />
<br />
More extensive documentation of the linux-pax-flags utility is to be found on it's man page.<br />
<br />
= Tips and Tricks =<br />
<br />
Because you will not be able to change the PaX flags for a running program, and that the vast majority of programs which would need them are graphical, it is strongly advisable to not use a Graphical Login like GDM or KDM. Instead simply have the system drop you to a console to log in and use {{ic|startx}}. Then you will have a chance to set the PaX flags before anything starts. For the same reasons it is strongly advisable to update your system and run {{ic|linux-pax-flags}} right after boot, before running {{ic|startx}}.<br />
<br />
Grsecurity will harden /proc and /sys so your normal user will no longer be able to see the network status, becuase of this non of your desktop network monitors will work. Instead just install terminal based monitoring programs, such as [https://www.archlinux.org/packages/community/x86_64/nmon/ nmon] or [https://www.archlinux.org/packages/community/x86_64/nload/ nload] and run them as root, or as a user in the proc-trusted group.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Grsecurity&diff=272340Grsecurity2013-08-24T10:13:35Z<p>Hunterthomson: /* Download Files */ said stable was for LTS</p>
<hr />
<div>[[Category:Kernel]][[Category:Security]]<br />
The grsecurity project, hosted on https://grsecurity.net, provides various patches to the Linux kernel which enhance your system's overall security. Grsecurity also ships with PaX which provides the most advanced memory protections of any OS. PaX invented ALSR and shows that ALSA is only the tip of the iceberg. Grsecurities RBAC Mandatory Access Control system was the insproation for SELinux and AppArmor.<br />
<br />
In short, a Linux kernel hardened with Grsecurity is the most hardened kernel you could have. Not even OpenBSD has all the hardening features it provides. A comprehensive list is maintained on the grsecurity features page itself. However, the grsecruity Wiki is often out-of-date. The best way is to simply read the Help text in the kernel config.<br />
<br />
Arch has all the utilities and kernel packages in the AUR you need to run a Grsecurity Hardened Arch Linux system. Arch even has a script called [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] which will make using PaX as painless as possible by setting all of the PaX flags for you.<br />
<br />
Installing your kernel from the AUR package is the recommended way to install a Grsecurity hardened kernel.<br />
<br />
= Setup and Install from AUR =<br />
<br />
To build the AUR package we will follow this general game plan. First, download all needed files and check GPG signatures. Second, configure kernel and compile. Third, copy a backup of these files to the Root users home folder. Forth, install utilities needed for PaX and RBAC. Fifth, install the kernel package. Sixth, run linux-pax-flags to poke security holes in applications that will not run without them. Finally, reboot into your hardened system.<br />
<br />
== Download Files ==<br />
<br />
Download the packages<br />
[https://aur.archlinux.org/packages/linux-grsec/ linux-grsec]<br />
Or<br />
[https://aur.archlinux.org/packages/linux-grsec-lts/ linux-grsec-lts]<br />
<br />
Kernel linux-3.X.tar.xz and current patch-3.X.X.tar.xz also the .sign signature files for each.<br />
[https://www.kernel.org/pub/linux/kernel/v3.x/ kernel.org]<br />
<br />
Download the current grsecurity patch and Signatures<br />
[https://grsecurity.net/test.php grsecurity Test]<br />
Or<br />
[https://grsecurity.net/download_stable.php grsecurity Stable] for LTS kernel<br />
<br />
{{tip|The Grsecurity Test is in fact Stable. The Stable Grsecurity version is just for the LTS}}<br />
<br />
=== Verify The GPG Signatures ===<br />
<br />
With the .sign files in the same directory as the file it is a a signature of, verify the signature like so...<br />
<br />
$ gpg2 --verify linux-3.10.tar.sign<br />
<br />
== Setup Build Environment ==<br />
<br />
Unpack the linux-grsec.tar.gz and copy all the files into it<br />
<br />
$ tar xzf linux-grsec.tar.gz<br />
$ cp ~/Downloads/linux-3.10.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/patch-3.10.9.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/grsecurity-2.9.1-3.10.9-201308202015.patch ~/linux-grsec<br />
<br />
Change into the build directory<br />
<br />
$ cd ~/linux-grsec<br />
<br />
Edit the PKGBUILD so when the package is built it will launch the makemenu ncurses configuration GUI, and build the package when we are done editing the kernel configuration.<br />
<br />
$ nano PKGBUILD<br />
<br />
Change _menuconfig=0 to _menuconfig=2<br />
<br />
== Build the Kernel Package ==<br />
<br />
It is going to take a long time to build the kernel because it is based on the default Arch kernel config with has about ten times as make modules enabled then your system actually needs. However, it is a known working config and to eliminate any more variables it is advisable to just live with the extra build time.<br />
<br />
Build the package<br />
<br />
$ makepkg<br />
<br />
You should be dropped into the ncurses GUI now. Navigate to the grsecurity settings to verify the configuration and/or change things as needed. These setting can be found in {{ic|Security options ---> Grsecurity ---> Customize Configuration --->}}<br />
<br />
For both Desktops and Servers disable {{ic|Sysctl support}} found in {{ic|Sysctl Support}}.<br />
If this kernel is for a Server also enable {{ic|Disable privileged I/O}} found in {{ic|Memory Protections}}.<br />
<br />
All other setting should be optimal as they are, so now exit out of the ncurses GUI config and Save. Now the package should start to build. If all goes well you will have two .pkg.tar.xz pakages one for the kernel and one for the kenrel-headers.<br />
<br />
=== Make a Backup ===<br />
<br />
Keep all linux-grsec.tar.gz files along with the grsecruity patch and compiled packages in the Root users home folder. That way you can roll back if needed. Every time a new grsecurity patch is release you will not be able to download outdated patches every again.<br />
<br />
# mkdir /root/3.10.9<br />
# cp -r /home/USER/linux-grsec /root/3.10.9<br />
<br />
== Install PaX and RBAC Utilities ==<br />
<br />
The AUR also has [https://aur.archlinux.org/packages/paxctl/ paxctl], [https://aur.archlinux.org/packages/gradm/ gradm], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] packages that you will need.<br />
<br />
For simplicities sake I will assume you are using yaourt to install package form the AUR, however any other way of installing these packages will work as well.<br />
<br />
$ yaourt -S linux-pax-flags paxctl gradm<br />
<br />
== Set PaX Flags ==<br />
<br />
Use the linux-pax-flags program to configure all the PaX flags for troublesome programs.<br />
More information can be found in the Using linux-pax-flags AUR Package section.<br />
<br />
# linux-pax-flags<br />
<br />
== Install Hardened Kernel ==<br />
<br />
Now that all the needed utilities are installed and the system is configured for PaX, install the hardened kernel and headers. Then reboot into the hardened kernel and make sure to select it at boot, but it should now be the default kernel.<br />
<br />
# pacman -U /root/3.10.9/*.pkg.tar.xz<br />
<br />
You should now be in your hardened system. Just make sure to run {{ic|linux-pax-flags}} after every time you update your system or install a new program and you should have a trouble free experience.<br />
<br />
= Manual Kernel Configuration =<br />
<br />
Throughout this document we will talk about kernel configuration using the kernel variables like CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. These are the variables that the kernel build process uses to determine if a certain feature needs to be compiled.<br />
<br />
When you configure your kernel through make menuconfig or similar, you receive a user interface through which you can select the various kernel options. If you select the Help button at a certain kernel feature you will see at the top that it lists such a kernel variable.<br />
<br />
You can therefore still configure your kernel as you like - with a bit of thinking. And if you can't find a certain option, there's always the possibility to edit /usr/src/linux/.config by hand :)<br />
<br />
Of course, to be able to select the various grsecurity kernel options, you must enable grsecurity in your kernel.<br />
See [[default grsecurity kernel configuration]]<br />
<br />
== PaX ==<br />
<br />
=== Fighting the Exploitation of Software Bugs ===<br />
<br />
PaX introduces a couple of security mechanisms that make it harder for attackers to exploit software bugs that involve memory corruption (so do not treat PaX as if it protects against all possible software bugs). The PaX introduction document talks about three possible exploit techniques:<br />
<br />
# introduce/execute arbitrary code<br />
# execute existing code out of original program order<br />
# execute existing code in original program order with arbitrary data<br />
<br />
One prevention method disallows executable code to be stored in writable memory. When we look at a process, it requires five memory regions:<br />
<br />
# a data section which contains the statically allocated and global data<br />
# a BSS region (Block Started by Symbol) which contains information about the zero-initialized data of the process<br />
# a code region, also called the text segment, which contains the executable instructions<br />
# a heap which contains the dynamically allocated memory<br />
# a stack which contains the local variables<br />
<br />
The first PaX prevention method, called NOEXEC, is meant to give control over the runtime code generation. It marks memory pages that do not contain executable code as non-executable. This means that the heap and the stack, which only contain variable data and shouldn't contain executable code, are marked as non-executable. Exploits that place code in these areas with the intention of running it will fail.<br />
<br />
NOEXEC does more than this actually, interested readers should focus their attention to the [http://pax.grsecurity.net/docs/noexec.txt PaX NOEXEC documentation].<br />
<br />
The second PaX prevention method, called ASLR (Address Space Layout Randomization), randomize the addresses given to memory requests. Where previously memory was assigned contiguously (which means exploits know where the tasks' memory regions are situated) ASLR randomizes this allocation, rendering techniques that rely on this information useless.<br />
<br />
More information about ASLR can be found [http://pax.grsecurity.net/docs/aslr.txt online].<br />
<br />
=== Enabling PaX ===<br />
<br />
==== Installing from AUR ====<br />
<br />
There are PKGBUILDs for both PaX-only ({{aur|linux-pax}}) and grsecurity+PaX ({{aur|linux-grsec}}) enabled kernels in AUR.<br />
<br />
==== The manual way ====<br />
<br />
The recommended kernel setting for PaX is:<br />
<br />
#<br />
# Security options<br />
#<br />
#<br />
# PaX<br />
#<br />
CONFIG_PAX=y<br />
#<br />
# PaX Control<br />
#<br />
# CONFIG_PAX_SOFTMODE is not set<br />
CONFIG_PAX_EI_PAX=y<br />
CONFIG_PAX_PT_PAX_FLAGS=y<br />
CONFIG_PAX_NO_ACL_FLAGS=y<br />
# CONFIG_PAX_HAVE_ACL_FLAGS is not set<br />
# CONFIG_PAX_HOOK_ACL_FLAGS is not set<br />
#<br />
# Non-executable pages<br />
#<br />
CONFIG_PAX_NOEXEC=y<br />
CONFIG_PAX_PAGEEXEC=y<br />
CONFIG_PAX_SEGMEXEC=y<br />
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set<br />
CONFIG_PAX_DEFAULT_SEGMEXEC=y<br />
CONFIG_PAX_EMUTRAMP=y<br />
CONFIG_PAX_MPROTECT=y<br />
# CONFIG_PAX_NOELFRELOCS is not set<br />
#<br />
# Address Space Layout Randomization<br />
#<br />
CONFIG_PAX_ASLR=y<br />
CONFIG_PAX_RANDKSTACK=y<br />
CONFIG_PAX_RANDUSTACK=y<br />
CONFIG_PAX_RANDMMAP=y<br />
#<br />
# Miscellaneous hardening features<br />
#<br />
CONFIG_PAX_MEMORY_SANITIZE=y<br />
CONFIG_PAX_MEMORY_UDEREF=y<br />
CONFIG_KEYS=y<br />
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_NETWORK_XFRM=y<br />
CONFIG_SECURITY_CAPABILITIES=m<br />
CONFIG_SECURITY_ROOTPLUG=m<br />
<br />
If you are running a non-x86 system you will observe that there is no CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC instead as it is the only non-exec implementation around.<br />
<br />
=== Controlling PaX ===<br />
<br />
Not all Linux applications are happy with the PaX security restrictions. These tools include xorg-x11, java, mplayer, xmms and others. If you plan on using them you can elevate the protections for these applications using chpax and paxctl. You can find they on AUR.<br />
<br />
You can also use pax-utils, which is a small toolbox which contains useful applications to administrate a PaX aware server. Find it on AUR.<br />
<br />
Interesting tools include scanelf and pspax:<br />
<br />
* With scanelf you can scan over library and binary directories and list the various permissions and ELF types that pertain to running an ideal pax/grsec setup<br />
* With pspax you can display PaX flags/capabilities/xattr from the kernel's perspective<br />
<br />
=== Verifying the PaX Settings ===<br />
<br />
Peter Busser has written a regression test suite called paxtest. This tool will check various cases of possible attack vectors and inform you of the result. When you run it, it will leave a logfile called paxtest.log in the current working directory.<br />
<br />
# paxtest<br />
Executable anonymous mapping : Killed<br />
Executable bss : Killed<br />
Executable data : Killed<br />
Executable heap : Killed<br />
Executable stack : Killed<br />
Executable anonymous mapping (mprotect) : Killed<br />
Executable bss (mprotect) : Killed<br />
Executable data (mprotect) : Killed<br />
Executable heap (mprotect) : Killed<br />
Executable stack (mprotect) : Killed<br />
Executable shared library bss (mprotect) : Killed<br />
Executable shared library data (mprotect): Killed<br />
Writable text segments : Killed<br />
Anonymous mapping randomisation test : 16 bits (guessed)<br />
Heap randomisation test (ET_EXEC) : 13 bits (guessed)<br />
Heap randomisation test (ET_DYN) : 25 bits (guessed)<br />
Main executable randomisation (ET_EXEC) : 16 bits (guessed)<br />
Main executable randomisation (ET_DYN) : 17 bits (guessed)<br />
Shared library randomisation test : 16 bits (guessed)<br />
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)<br />
Stack randomisation test (PAGEEXEC) : No randomisation<br />
Return to function (strcpy) : Vulnerable<br />
Return to function (memcpy) : Vulnerable<br />
Return to function (strcpy, RANDEXEC) : Killed<br />
Return to function (memcpy, RANDEXEC) : Killed<br />
Executable shared library bss : Killed<br />
Executable shared library data : Killed<br />
<br />
In the above example run you notice that:<br />
<br />
* strcpy and memcpy are listed as Vulnerable. This is expected and normal - it is simply showing the need for a technology such as ProPolice/SSP<br />
* there is no randomization for PAGEEXEC. This is normal since our recommended x86 kernel configuration didn't activate the PAGEEXEC setting. However, on arches that support a true NX (non-executable) bit (most of them do, including x86_64), PAGEEXEC is the only method available for NOEXEC and has no performance hit.<br />
<br />
== Filesystem Protection ==<br />
<br />
=== Fighting Chroot and Filesystem Abuse ===<br />
<br />
Grsecurity2 includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on /proc usage, chrooting, linking, etc.<br />
<br />
=== Kernel Configuration ===<br />
<br />
We recommend the following grsecurity kernel configuration for filesystem protection:<br />
<br />
#<br />
# Filesystem Protections<br />
#<br />
CONFIG_GRKERNSEC_PROC=y<br />
# CONFIG_GRKERNSEC_PROC_USER is not set<br />
CONFIG_GRKERNSEC_PROC_USERGROUP=y<br />
CONFIG_GRKERNSEC_PROC_GID=3<br />
CONFIG_GRKERNSEC_PROC_ADD=y<br />
CONFIG_GRKERNSEC_LINK=y<br />
CONFIG_GRKERNSEC_FIFO=y<br />
CONFIG_GRKERNSEC_CHROOT=y<br />
CONFIG_GRKERNSEC_CHROOT_MOUNT=y<br />
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y<br />
CONFIG_GRKERNSEC_CHROOT_PIVOT=y<br />
CONFIG_GRKERNSEC_CHROOT_CHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_CHMOD=y<br />
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_MKNOD=y<br />
CONFIG_GRKERNSEC_CHROOT_SHMAT=y<br />
CONFIG_GRKERNSEC_CHROOT_UNIX=y<br />
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y<br />
CONFIG_GRKERNSEC_CHROOT_NICE=y<br />
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y<br />
CONFIG_GRKERNSEC_CHROOT_CAPS=y<br />
<br />
=== Triggering the Security Mechanism ===<br />
<br />
When you're using a kernel compiled with the above (or similar) settings, you will get the option to enable/disable many of the options through the /proc filesystem or via sysctl.<br />
<br />
The example below shows an excerpt of a typical /etc/sysctl.conf:<br />
<br />
kernel.grsecurity.chroot_deny_sysctl = 1<br />
kernel.grsecurity.chroot_caps = 1<br />
kernel.grsecurity.chroot_execlog = 0<br />
kernel.grsecurity.chroot_restrict_nice = 1<br />
kernel.grsecurity.chroot_deny_mknod = 1<br />
kernel.grsecurity.chroot_deny_chmod = 1<br />
kernel.grsecurity.chroot_enforce_chdir = 1<br />
kernel.grsecurity.chroot_deny_pivot = 1<br />
kernel.grsecurity.chroot_deny_chroot = 1<br />
kernel.grsecurity.chroot_deny_fchdir = 1<br />
kernel.grsecurity.chroot_deny_mount = 1<br />
kernel.grsecurity.chroot_deny_unix = 1<br />
kernel.grsecurity.chroot_deny_shmat = 1<br />
<br />
You can enable or disable settings at will using the sysctl command:<br />
<br />
(Toggling the exec_logging feature ON)<br />
# sysctl -w kernel.grsecurity.exec_logging = 1<br />
(Toggling the exec_logging feature OFF)<br />
# sysctl -w kernel.grsecurity.exec_logging = 0<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
== Kernel Auditing ==<br />
<br />
=== Extend your System's Logging Facilities ===<br />
<br />
grsecurity adds extra functionality to the kernel pertaining the logging. With grsecurity's Kernel Auditing the kernel informs you when applications are started, devices (un)mounted, etc.<br />
<br />
=== The various Kernel Audit Settings ===<br />
<br />
The following kernel configuration section can be used to enable grsecurity's Kernel Audit Settings:<br />
<br />
#<br />
# Kernel Auditing<br />
#<br />
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set<br />
CONFIG_GRKERNSEC_EXECLOG=y<br />
CONFIG_GRKERNSEC_RESLOG=y<br />
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y<br />
CONFIG_GRKERNSEC_AUDIT_CHDIR=y<br />
CONFIG_GRKERNSEC_AUDIT_MOUNT=y<br />
CONFIG_GRKERNSEC_AUDIT_IPC=y<br />
CONFIG_GRKERNSEC_SIGNAL=y<br />
CONFIG_GRKERNSEC_FORKFAIL=y<br />
CONFIG_GRKERNSEC_TIME=y<br />
CONFIG_GRKERNSEC_PROC_IPADDR=y<br />
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y<br />
<br />
== Process Restrictions ==<br />
<br />
=== Executable Protection ===<br />
<br />
With grsecurity you can restrict executables. Since most exploits work through one or more running processes this protection can save your system's health.<br />
<br />
=== Network Protection ===<br />
<br />
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity includes randomization patches to counter these attacks. Apart from these you can also enable socket restrictions, disallowing certain groups network access alltogether.<br />
<br />
=== Kernel Settings ===<br />
<br />
The following kernel settings enable various executable and network protections:<br />
<br />
#<br />
# Executable Protections<br />
#<br />
CONFIG_GRKERNSEC_EXECVE=y<br />
CONFIG_GRKERNSEC_DMESG=y<br />
CONFIG_GRKERNSEC_RANDPID=y<br />
CONFIG_GRKERNSEC_TPE=y<br />
CONFIG_GRKERNSEC_TPE_ALL=y<br />
CONFIG_GRKERNSEC_TPE_GID=100<br />
<br />
#<br />
# Network Protections<br />
#<br />
CONFIG_GRKERNSEC_RANDNET=y<br />
CONFIG_GRKERNSEC_RANDISN=y<br />
CONFIG_GRKERNSEC_RANDID=y<br />
CONFIG_GRKERNSEC_RANDSRC=y<br />
CONFIG_GRKERNSEC_RANDRPC=y<br />
# CONFIG_GRKERNSEC_SOCKET is not set<br />
<br />
= RBAC =<br />
<br />
Role Based Access Control<br />
<br />
There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.<br />
<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
== Configuring the Kernel ==<br />
<br />
The recommended kernel setting for RBAC is:<br />
<br />
#<br />
# Role Based Access Control Options<br />
#<br />
CONFIG_GRKERNSEC_ACL_HIDEKERN=y<br />
CONFIG_GRKERNSEC_ACL_MAXTRIES=3<br />
CONFIG_GRKERNSEC_ACL_TIMEOUT=30<br />
<br />
== Working with gradm ==<br />
<br />
gradm is a tool which allows you to administer and maintain a policy for your system. With it, you can enable or disable the RBAC system, reload the RBAC roles, change your role, set a password for admin mode, etc.<br />
<br />
When you install gradm a default policy will be installed in /etc/grsec/policy. Please see in AUR for gradm package.<br />
<br />
By default, the RBAC policies are not activated. It is the sysadmin's job to determine when the system should have an RBAC policy enforced. Before activating the RBAC system you should set an admin password.<br />
<br />
# gradm -P admin<br />
Setting up grsecurity RBAC password<br />
Password: (Enter a well-chosen password)<br />
Re-enter Password: (Enter the same password for confirmation)<br />
Password written in /etc/grsec/pw<br />
# gradm -E<br />
<br />
To disable the RBAC system, run gradm -D. If you are not allowed to, you first need to switch to the admin role:<br />
<br />
# gradm -a admin<br />
Password: (Enter your admin role password)<br />
# gradm -D<br />
<br />
If you want to leave the admin role, run gradm -u admin:<br />
<br />
# gradm -u admin<br />
<br />
== Generating a Policy ==<br />
<br />
The RBAC system comes with a great feature called "learning mode". The learning mode can generate an anticipatory least privilege policy for your system. This allows for time and money savings by being able to rapidly deploy multiple secure servers.<br />
<br />
To use the learning mode, activate it using gradm:<br />
<br />
# gradm -F -L /etc/grsec/learning.log<br />
<br />
Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate or any other heavy file i/o operation as this can really slow down the processing time.<br />
<br />
When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under {{ic|/etc/grsec/learning.roles}}:<br />
<br />
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles<br />
<br />
Audit the {{ic|/etc/grsec/learning.roles}} and save it as {{ic|/etc/grsec/policy}} (mode {{ic|0600}}) when you are finished.<br />
<br />
# mv /etc/grsec/learning.roles /etc/grsec/policy<br />
# chmod 0600 /etc/grsec/policy<br />
<br />
You will now be able to enable the RBAC system with your new learned policy.<br />
<br />
== Tweaking your Policy ==<br />
<br />
An interesting feature of grsecurity 2.x is Set Operation Support for the configuration file. Currently it supports unions, intersections and differences of sets (of objects in this case).<br />
<br />
define objset1 {<br />
/root/blah rw<br />
/root/blah2 r<br />
/root/blah3 x<br />
}<br />
<br />
define somename2 {<br />
/root/test1 rw<br />
/root/blah2 rw<br />
/root/test3 h<br />
}<br />
<br />
Here is an example of its use, and the resulting objects that will be added to your subject:<br />
<br />
subject /somebinary o<br />
$objset1 & $somename2<br />
<br />
The above would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah2 r<br />
<br />
This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.<br />
<br />
subject /somebinary o<br />
$objset1 | $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 rw<br />
/root/blah3 x<br />
/root/test1 rw<br />
/root/test3 h<br />
<br />
This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.<br />
<br />
subject /somebinary o<br />
$objset1 - $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 h<br />
/root/blah3 x<br />
<br />
This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.<br />
<br />
In some obscure pseudo-language you could see this as:<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained /tmp/blah r) )<br />
then<br />
$objset1 - $objset2 would contain /tmp/blah w<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained / rwx) )<br />
then <br />
$objset1 - $objset2 would contain /tmp/blah h<br />
<br />
As for order of precedence (from highest to lowest): "-, & |".<br />
<br />
If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:<br />
<br />
(($set1 - $set2) | $set3) & $set4<br />
<br />
= Using linux-pax-flags AUR Package =<br />
<br />
The linux-pax-flags program is what makes using PaX on Arch Linux easy as pie. When you run this program it will set the PaX flags for all the problematic programs for you. However, if you use some uncommon program it may have problems forcing you to set the paxctl flags yourself. You will most likely see something like {{ic|Denied RWX}} in journalctl. That means you will need to disable MPROTECT for the program {{ic|paxctl -cPEmRXS /usr/bin/bla}}<br />
<br />
After you find what PaX flags need to be set post a comment on the linux-pax-flags AUR package so it can be added.<br />
<br />
= Tips and Tricks =<br />
<br />
Because you will not be able to change the PaX flags for a running program, and that the vast majority of programs which would need them are graphical, it is strongly advisable to not use a Graphical Login like GDM or KDM. Instead simply have the system drop you to a console to log in and use {{ic|startx}}. Then you will have a chance to set the PaX flags before anything starts. For the same reasons it is strongly advisable to update your system and run {{ic|linux-pax-flags}} right after boot, before running {{ic|startx}}.<br />
<br />
Grsecurity will harden /proc and /sys so your normal user will no longer be able to see the network status, becuase of this non of your desktop network monitors will work. Instead just install terminal based monitoring programs, such as [https://www.archlinux.org/packages/community/x86_64/nmon/ nmon] or [https://www.archlinux.org/packages/community/x86_64/nload/ nload] and run them as root, or as a user in the proc-trusted group.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Grsecurity&diff=272339Grsecurity2013-08-24T10:11:24Z<p>Hunterthomson: /* Tips and Tricks */ suggested the proc-trusted group to run nload and stuff</p>
<hr />
<div>[[Category:Kernel]][[Category:Security]]<br />
The grsecurity project, hosted on https://grsecurity.net, provides various patches to the Linux kernel which enhance your system's overall security. Grsecurity also ships with PaX which provides the most advanced memory protections of any OS. PaX invented ALSR and shows that ALSA is only the tip of the iceberg. Grsecurities RBAC Mandatory Access Control system was the insproation for SELinux and AppArmor.<br />
<br />
In short, a Linux kernel hardened with Grsecurity is the most hardened kernel you could have. Not even OpenBSD has all the hardening features it provides. A comprehensive list is maintained on the grsecurity features page itself. However, the grsecruity Wiki is often out-of-date. The best way is to simply read the Help text in the kernel config.<br />
<br />
Arch has all the utilities and kernel packages in the AUR you need to run a Grsecurity Hardened Arch Linux system. Arch even has a script called [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] which will make using PaX as painless as possible by setting all of the PaX flags for you.<br />
<br />
Installing your kernel from the AUR package is the recommended way to install a Grsecurity hardened kernel.<br />
<br />
= Setup and Install from AUR =<br />
<br />
To build the AUR package we will follow this general game plan. First, download all needed files and check GPG signatures. Second, configure kernel and compile. Third, copy a backup of these files to the Root users home folder. Forth, install utilities needed for PaX and RBAC. Fifth, install the kernel package. Sixth, run linux-pax-flags to poke security holes in applications that will not run without them. Finally, reboot into your hardened system.<br />
<br />
== Download Files ==<br />
<br />
Download the packages<br />
[https://aur.archlinux.org/packages/linux-grsec/ linux-grsec]<br />
Or<br />
[https://aur.archlinux.org/packages/linux-grsec-lts/ linux-grsec-lts]<br />
<br />
Kernel linux-3.X.tar.xz and current patch-3.X.X.tar.xz also the .sign signature files for each.<br />
[https://www.kernel.org/pub/linux/kernel/v3.x/ kernel.org]<br />
<br />
Download the current grsecurity patch and Signatures<br />
[https://grsecurity.net/test.php grsecurity Test]<br />
Or<br />
[https://grsecurity.net/download_stable.php grsecurity Stable]<br />
<br />
=== Verify The GPG Signatures ===<br />
<br />
With the .sign files in the same directory as the file it is a a signature of, verify the signature like so...<br />
<br />
$ gpg2 --verify linux-3.10.tar.sign<br />
<br />
== Setup Build Environment ==<br />
<br />
Unpack the linux-grsec.tar.gz and copy all the files into it<br />
<br />
$ tar xzf linux-grsec.tar.gz<br />
$ cp ~/Downloads/linux-3.10.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/patch-3.10.9.tar.xz ~/linux-grsec<br />
$ cp ~/Downloads/grsecurity-2.9.1-3.10.9-201308202015.patch ~/linux-grsec<br />
<br />
Change into the build directory<br />
<br />
$ cd ~/linux-grsec<br />
<br />
Edit the PKGBUILD so when the package is built it will launch the makemenu ncurses configuration GUI, and build the package when we are done editing the kernel configuration.<br />
<br />
$ nano PKGBUILD<br />
<br />
Change _menuconfig=0 to _menuconfig=2<br />
<br />
== Build the Kernel Package ==<br />
<br />
It is going to take a long time to build the kernel because it is based on the default Arch kernel config with has about ten times as make modules enabled then your system actually needs. However, it is a known working config and to eliminate any more variables it is advisable to just live with the extra build time.<br />
<br />
Build the package<br />
<br />
$ makepkg<br />
<br />
You should be dropped into the ncurses GUI now. Navigate to the grsecurity settings to verify the configuration and/or change things as needed. These setting can be found in {{ic|Security options ---> Grsecurity ---> Customize Configuration --->}}<br />
<br />
For both Desktops and Servers disable {{ic|Sysctl support}} found in {{ic|Sysctl Support}}.<br />
If this kernel is for a Server also enable {{ic|Disable privileged I/O}} found in {{ic|Memory Protections}}.<br />
<br />
All other setting should be optimal as they are, so now exit out of the ncurses GUI config and Save. Now the package should start to build. If all goes well you will have two .pkg.tar.xz pakages one for the kernel and one for the kenrel-headers.<br />
<br />
=== Make a Backup ===<br />
<br />
Keep all linux-grsec.tar.gz files along with the grsecruity patch and compiled packages in the Root users home folder. That way you can roll back if needed. Every time a new grsecurity patch is release you will not be able to download outdated patches every again.<br />
<br />
# mkdir /root/3.10.9<br />
# cp -r /home/USER/linux-grsec /root/3.10.9<br />
<br />
== Install PaX and RBAC Utilities ==<br />
<br />
The AUR also has [https://aur.archlinux.org/packages/paxctl/ paxctl], [https://aur.archlinux.org/packages/gradm/ gradm], and [https://aur.archlinux.org/packages/linux-pax-flags/ linux-pax-flags] packages that you will need.<br />
<br />
For simplicities sake I will assume you are using yaourt to install package form the AUR, however any other way of installing these packages will work as well.<br />
<br />
$ yaourt -S linux-pax-flags paxctl gradm<br />
<br />
== Set PaX Flags ==<br />
<br />
Use the linux-pax-flags program to configure all the PaX flags for troublesome programs.<br />
More information can be found in the Using linux-pax-flags AUR Package section.<br />
<br />
# linux-pax-flags<br />
<br />
== Install Hardened Kernel ==<br />
<br />
Now that all the needed utilities are installed and the system is configured for PaX, install the hardened kernel and headers. Then reboot into the hardened kernel and make sure to select it at boot, but it should now be the default kernel.<br />
<br />
# pacman -U /root/3.10.9/*.pkg.tar.xz<br />
<br />
You should now be in your hardened system. Just make sure to run {{ic|linux-pax-flags}} after every time you update your system or install a new program and you should have a trouble free experience.<br />
<br />
= Manual Kernel Configuration =<br />
<br />
Throughout this document we will talk about kernel configuration using the kernel variables like CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. These are the variables that the kernel build process uses to determine if a certain feature needs to be compiled.<br />
<br />
When you configure your kernel through make menuconfig or similar, you receive a user interface through which you can select the various kernel options. If you select the Help button at a certain kernel feature you will see at the top that it lists such a kernel variable.<br />
<br />
You can therefore still configure your kernel as you like - with a bit of thinking. And if you can't find a certain option, there's always the possibility to edit /usr/src/linux/.config by hand :)<br />
<br />
Of course, to be able to select the various grsecurity kernel options, you must enable grsecurity in your kernel.<br />
See [[default grsecurity kernel configuration]]<br />
<br />
== PaX ==<br />
<br />
=== Fighting the Exploitation of Software Bugs ===<br />
<br />
PaX introduces a couple of security mechanisms that make it harder for attackers to exploit software bugs that involve memory corruption (so do not treat PaX as if it protects against all possible software bugs). The PaX introduction document talks about three possible exploit techniques:<br />
<br />
# introduce/execute arbitrary code<br />
# execute existing code out of original program order<br />
# execute existing code in original program order with arbitrary data<br />
<br />
One prevention method disallows executable code to be stored in writable memory. When we look at a process, it requires five memory regions:<br />
<br />
# a data section which contains the statically allocated and global data<br />
# a BSS region (Block Started by Symbol) which contains information about the zero-initialized data of the process<br />
# a code region, also called the text segment, which contains the executable instructions<br />
# a heap which contains the dynamically allocated memory<br />
# a stack which contains the local variables<br />
<br />
The first PaX prevention method, called NOEXEC, is meant to give control over the runtime code generation. It marks memory pages that do not contain executable code as non-executable. This means that the heap and the stack, which only contain variable data and shouldn't contain executable code, are marked as non-executable. Exploits that place code in these areas with the intention of running it will fail.<br />
<br />
NOEXEC does more than this actually, interested readers should focus their attention to the [http://pax.grsecurity.net/docs/noexec.txt PaX NOEXEC documentation].<br />
<br />
The second PaX prevention method, called ASLR (Address Space Layout Randomization), randomize the addresses given to memory requests. Where previously memory was assigned contiguously (which means exploits know where the tasks' memory regions are situated) ASLR randomizes this allocation, rendering techniques that rely on this information useless.<br />
<br />
More information about ASLR can be found [http://pax.grsecurity.net/docs/aslr.txt online].<br />
<br />
=== Enabling PaX ===<br />
<br />
==== Installing from AUR ====<br />
<br />
There are PKGBUILDs for both PaX-only ({{aur|linux-pax}}) and grsecurity+PaX ({{aur|linux-grsec}}) enabled kernels in AUR.<br />
<br />
==== The manual way ====<br />
<br />
The recommended kernel setting for PaX is:<br />
<br />
#<br />
# Security options<br />
#<br />
#<br />
# PaX<br />
#<br />
CONFIG_PAX=y<br />
#<br />
# PaX Control<br />
#<br />
# CONFIG_PAX_SOFTMODE is not set<br />
CONFIG_PAX_EI_PAX=y<br />
CONFIG_PAX_PT_PAX_FLAGS=y<br />
CONFIG_PAX_NO_ACL_FLAGS=y<br />
# CONFIG_PAX_HAVE_ACL_FLAGS is not set<br />
# CONFIG_PAX_HOOK_ACL_FLAGS is not set<br />
#<br />
# Non-executable pages<br />
#<br />
CONFIG_PAX_NOEXEC=y<br />
CONFIG_PAX_PAGEEXEC=y<br />
CONFIG_PAX_SEGMEXEC=y<br />
# CONFIG_PAX_DEFAULT_PAGEEXEC is not set<br />
CONFIG_PAX_DEFAULT_SEGMEXEC=y<br />
CONFIG_PAX_EMUTRAMP=y<br />
CONFIG_PAX_MPROTECT=y<br />
# CONFIG_PAX_NOELFRELOCS is not set<br />
#<br />
# Address Space Layout Randomization<br />
#<br />
CONFIG_PAX_ASLR=y<br />
CONFIG_PAX_RANDKSTACK=y<br />
CONFIG_PAX_RANDUSTACK=y<br />
CONFIG_PAX_RANDMMAP=y<br />
#<br />
# Miscellaneous hardening features<br />
#<br />
CONFIG_PAX_MEMORY_SANITIZE=y<br />
CONFIG_PAX_MEMORY_UDEREF=y<br />
CONFIG_KEYS=y<br />
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_NETWORK_XFRM=y<br />
CONFIG_SECURITY_CAPABILITIES=m<br />
CONFIG_SECURITY_ROOTPLUG=m<br />
<br />
If you are running a non-x86 system you will observe that there is no CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC instead as it is the only non-exec implementation around.<br />
<br />
=== Controlling PaX ===<br />
<br />
Not all Linux applications are happy with the PaX security restrictions. These tools include xorg-x11, java, mplayer, xmms and others. If you plan on using them you can elevate the protections for these applications using chpax and paxctl. You can find they on AUR.<br />
<br />
You can also use pax-utils, which is a small toolbox which contains useful applications to administrate a PaX aware server. Find it on AUR.<br />
<br />
Interesting tools include scanelf and pspax:<br />
<br />
* With scanelf you can scan over library and binary directories and list the various permissions and ELF types that pertain to running an ideal pax/grsec setup<br />
* With pspax you can display PaX flags/capabilities/xattr from the kernel's perspective<br />
<br />
=== Verifying the PaX Settings ===<br />
<br />
Peter Busser has written a regression test suite called paxtest. This tool will check various cases of possible attack vectors and inform you of the result. When you run it, it will leave a logfile called paxtest.log in the current working directory.<br />
<br />
# paxtest<br />
Executable anonymous mapping : Killed<br />
Executable bss : Killed<br />
Executable data : Killed<br />
Executable heap : Killed<br />
Executable stack : Killed<br />
Executable anonymous mapping (mprotect) : Killed<br />
Executable bss (mprotect) : Killed<br />
Executable data (mprotect) : Killed<br />
Executable heap (mprotect) : Killed<br />
Executable stack (mprotect) : Killed<br />
Executable shared library bss (mprotect) : Killed<br />
Executable shared library data (mprotect): Killed<br />
Writable text segments : Killed<br />
Anonymous mapping randomisation test : 16 bits (guessed)<br />
Heap randomisation test (ET_EXEC) : 13 bits (guessed)<br />
Heap randomisation test (ET_DYN) : 25 bits (guessed)<br />
Main executable randomisation (ET_EXEC) : 16 bits (guessed)<br />
Main executable randomisation (ET_DYN) : 17 bits (guessed)<br />
Shared library randomisation test : 16 bits (guessed)<br />
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)<br />
Stack randomisation test (PAGEEXEC) : No randomisation<br />
Return to function (strcpy) : Vulnerable<br />
Return to function (memcpy) : Vulnerable<br />
Return to function (strcpy, RANDEXEC) : Killed<br />
Return to function (memcpy, RANDEXEC) : Killed<br />
Executable shared library bss : Killed<br />
Executable shared library data : Killed<br />
<br />
In the above example run you notice that:<br />
<br />
* strcpy and memcpy are listed as Vulnerable. This is expected and normal - it is simply showing the need for a technology such as ProPolice/SSP<br />
* there is no randomization for PAGEEXEC. This is normal since our recommended x86 kernel configuration didn't activate the PAGEEXEC setting. However, on arches that support a true NX (non-executable) bit (most of them do, including x86_64), PAGEEXEC is the only method available for NOEXEC and has no performance hit.<br />
<br />
== Filesystem Protection ==<br />
<br />
=== Fighting Chroot and Filesystem Abuse ===<br />
<br />
Grsecurity2 includes many patches that prohibits users from gaining unnecessary knowledge about the system. This includes restrictions on /proc usage, chrooting, linking, etc.<br />
<br />
=== Kernel Configuration ===<br />
<br />
We recommend the following grsecurity kernel configuration for filesystem protection:<br />
<br />
#<br />
# Filesystem Protections<br />
#<br />
CONFIG_GRKERNSEC_PROC=y<br />
# CONFIG_GRKERNSEC_PROC_USER is not set<br />
CONFIG_GRKERNSEC_PROC_USERGROUP=y<br />
CONFIG_GRKERNSEC_PROC_GID=3<br />
CONFIG_GRKERNSEC_PROC_ADD=y<br />
CONFIG_GRKERNSEC_LINK=y<br />
CONFIG_GRKERNSEC_FIFO=y<br />
CONFIG_GRKERNSEC_CHROOT=y<br />
CONFIG_GRKERNSEC_CHROOT_MOUNT=y<br />
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y<br />
CONFIG_GRKERNSEC_CHROOT_PIVOT=y<br />
CONFIG_GRKERNSEC_CHROOT_CHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_CHMOD=y<br />
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y<br />
CONFIG_GRKERNSEC_CHROOT_MKNOD=y<br />
CONFIG_GRKERNSEC_CHROOT_SHMAT=y<br />
CONFIG_GRKERNSEC_CHROOT_UNIX=y<br />
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y<br />
CONFIG_GRKERNSEC_CHROOT_NICE=y<br />
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y<br />
CONFIG_GRKERNSEC_CHROOT_CAPS=y<br />
<br />
=== Triggering the Security Mechanism ===<br />
<br />
When you're using a kernel compiled with the above (or similar) settings, you will get the option to enable/disable many of the options through the /proc filesystem or via sysctl.<br />
<br />
The example below shows an excerpt of a typical /etc/sysctl.conf:<br />
<br />
kernel.grsecurity.chroot_deny_sysctl = 1<br />
kernel.grsecurity.chroot_caps = 1<br />
kernel.grsecurity.chroot_execlog = 0<br />
kernel.grsecurity.chroot_restrict_nice = 1<br />
kernel.grsecurity.chroot_deny_mknod = 1<br />
kernel.grsecurity.chroot_deny_chmod = 1<br />
kernel.grsecurity.chroot_enforce_chdir = 1<br />
kernel.grsecurity.chroot_deny_pivot = 1<br />
kernel.grsecurity.chroot_deny_chroot = 1<br />
kernel.grsecurity.chroot_deny_fchdir = 1<br />
kernel.grsecurity.chroot_deny_mount = 1<br />
kernel.grsecurity.chroot_deny_unix = 1<br />
kernel.grsecurity.chroot_deny_shmat = 1<br />
<br />
You can enable or disable settings at will using the sysctl command:<br />
<br />
(Toggling the exec_logging feature ON)<br />
# sysctl -w kernel.grsecurity.exec_logging = 1<br />
(Toggling the exec_logging feature OFF)<br />
# sysctl -w kernel.grsecurity.exec_logging = 0<br />
<br />
There is a very important sysctl setting pertaining to grsecurity, namely kernel.grsecurity.grsec_lock. When set, you are not able to change any setting anymore.<br />
<br />
# sysctl -w kernel.grsecurity.grsec_lock = 1<br />
<br />
== Kernel Auditing ==<br />
<br />
=== Extend your System's Logging Facilities ===<br />
<br />
grsecurity adds extra functionality to the kernel pertaining the logging. With grsecurity's Kernel Auditing the kernel informs you when applications are started, devices (un)mounted, etc.<br />
<br />
=== The various Kernel Audit Settings ===<br />
<br />
The following kernel configuration section can be used to enable grsecurity's Kernel Audit Settings:<br />
<br />
#<br />
# Kernel Auditing<br />
#<br />
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set<br />
CONFIG_GRKERNSEC_EXECLOG=y<br />
CONFIG_GRKERNSEC_RESLOG=y<br />
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y<br />
CONFIG_GRKERNSEC_AUDIT_CHDIR=y<br />
CONFIG_GRKERNSEC_AUDIT_MOUNT=y<br />
CONFIG_GRKERNSEC_AUDIT_IPC=y<br />
CONFIG_GRKERNSEC_SIGNAL=y<br />
CONFIG_GRKERNSEC_FORKFAIL=y<br />
CONFIG_GRKERNSEC_TIME=y<br />
CONFIG_GRKERNSEC_PROC_IPADDR=y<br />
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y<br />
<br />
== Process Restrictions ==<br />
<br />
=== Executable Protection ===<br />
<br />
With grsecurity you can restrict executables. Since most exploits work through one or more running processes this protection can save your system's health.<br />
<br />
=== Network Protection ===<br />
<br />
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity includes randomization patches to counter these attacks. Apart from these you can also enable socket restrictions, disallowing certain groups network access alltogether.<br />
<br />
=== Kernel Settings ===<br />
<br />
The following kernel settings enable various executable and network protections:<br />
<br />
#<br />
# Executable Protections<br />
#<br />
CONFIG_GRKERNSEC_EXECVE=y<br />
CONFIG_GRKERNSEC_DMESG=y<br />
CONFIG_GRKERNSEC_RANDPID=y<br />
CONFIG_GRKERNSEC_TPE=y<br />
CONFIG_GRKERNSEC_TPE_ALL=y<br />
CONFIG_GRKERNSEC_TPE_GID=100<br />
<br />
#<br />
# Network Protections<br />
#<br />
CONFIG_GRKERNSEC_RANDNET=y<br />
CONFIG_GRKERNSEC_RANDISN=y<br />
CONFIG_GRKERNSEC_RANDID=y<br />
CONFIG_GRKERNSEC_RANDSRC=y<br />
CONFIG_GRKERNSEC_RANDRPC=y<br />
# CONFIG_GRKERNSEC_SOCKET is not set<br />
<br />
= RBAC =<br />
<br />
Role Based Access Control<br />
<br />
There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.<br />
<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
== Configuring the Kernel ==<br />
<br />
The recommended kernel setting for RBAC is:<br />
<br />
#<br />
# Role Based Access Control Options<br />
#<br />
CONFIG_GRKERNSEC_ACL_HIDEKERN=y<br />
CONFIG_GRKERNSEC_ACL_MAXTRIES=3<br />
CONFIG_GRKERNSEC_ACL_TIMEOUT=30<br />
<br />
== Working with gradm ==<br />
<br />
gradm is a tool which allows you to administer and maintain a policy for your system. With it, you can enable or disable the RBAC system, reload the RBAC roles, change your role, set a password for admin mode, etc.<br />
<br />
When you install gradm a default policy will be installed in /etc/grsec/policy. Please see in AUR for gradm package.<br />
<br />
By default, the RBAC policies are not activated. It is the sysadmin's job to determine when the system should have an RBAC policy enforced. Before activating the RBAC system you should set an admin password.<br />
<br />
# gradm -P admin<br />
Setting up grsecurity RBAC password<br />
Password: (Enter a well-chosen password)<br />
Re-enter Password: (Enter the same password for confirmation)<br />
Password written in /etc/grsec/pw<br />
# gradm -E<br />
<br />
To disable the RBAC system, run gradm -D. If you are not allowed to, you first need to switch to the admin role:<br />
<br />
# gradm -a admin<br />
Password: (Enter your admin role password)<br />
# gradm -D<br />
<br />
If you want to leave the admin role, run gradm -u admin:<br />
<br />
# gradm -u admin<br />
<br />
== Generating a Policy ==<br />
<br />
The RBAC system comes with a great feature called "learning mode". The learning mode can generate an anticipatory least privilege policy for your system. This allows for time and money savings by being able to rapidly deploy multiple secure servers.<br />
<br />
To use the learning mode, activate it using gradm:<br />
<br />
# gradm -F -L /etc/grsec/learning.log<br />
<br />
Now use your system, do the things you would normally do. Try to avoid rsyncing, running locate or any other heavy file i/o operation as this can really slow down the processing time.<br />
<br />
When you believe you have used your system sufficiently to obtain a good policy, let gradm process them and propose roles under {{ic|/etc/grsec/learning.roles}}:<br />
<br />
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles<br />
<br />
Audit the {{ic|/etc/grsec/learning.roles}} and save it as {{ic|/etc/grsec/policy}} (mode {{ic|0600}}) when you are finished.<br />
<br />
# mv /etc/grsec/learning.roles /etc/grsec/policy<br />
# chmod 0600 /etc/grsec/policy<br />
<br />
You will now be able to enable the RBAC system with your new learned policy.<br />
<br />
== Tweaking your Policy ==<br />
<br />
An interesting feature of grsecurity 2.x is Set Operation Support for the configuration file. Currently it supports unions, intersections and differences of sets (of objects in this case).<br />
<br />
define objset1 {<br />
/root/blah rw<br />
/root/blah2 r<br />
/root/blah3 x<br />
}<br />
<br />
define somename2 {<br />
/root/test1 rw<br />
/root/blah2 rw<br />
/root/test3 h<br />
}<br />
<br />
Here is an example of its use, and the resulting objects that will be added to your subject:<br />
<br />
subject /somebinary o<br />
$objset1 & $somename2<br />
<br />
The above would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah2 r<br />
<br />
This is the result of the & operator which takes both sets and returns the files that exist in both sets and the permission for those files that exist in both sets.<br />
<br />
subject /somebinary o<br />
$objset1 | $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 rw<br />
/root/blah3 x<br />
/root/test1 rw<br />
/root/test3 h<br />
<br />
This is the result of the | operator which takes both sets and returns the files that exist in either set. If a file exists in both sets, it is returned as well and the mode contains the flags that exist in either set.<br />
<br />
subject /somebinary o<br />
$objset1 - $somename2<br />
<br />
This example would expand to:<br />
<br />
subject /somebinary o<br />
/root/blah rw<br />
/root/blah2 h<br />
/root/blah3 x<br />
<br />
This is the result of the - operator which takes both sets and returns the files that exist in the set on the left but not in the match of the file in set on the right. If a file exists on the left and a match is found on the right (either the filenames are the same, or a parent directory exists in the right set), the file is returned and the mode of the second set is removed from the first set, and that file is returned.<br />
<br />
In some obscure pseudo-language you could see this as:<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained /tmp/blah r) )<br />
then<br />
$objset1 - $objset2 would contain /tmp/blah w<br />
<br />
if ( ($objset1 contained /tmp/blah rw) and<br />
($objset2 contained / rwx) )<br />
then <br />
$objset1 - $objset2 would contain /tmp/blah h<br />
<br />
As for order of precedence (from highest to lowest): "-, & |".<br />
<br />
If you do not want to bother remembering precedence, parenthesis support is also included, so you can do things like:<br />
<br />
(($set1 - $set2) | $set3) & $set4<br />
<br />
= Using linux-pax-flags AUR Package =<br />
<br />
The linux-pax-flags program is what makes using PaX on Arch Linux easy as pie. When you run this program it will set the PaX flags for all the problematic programs for you. However, if you use some uncommon program it may have problems forcing you to set the paxctl flags yourself. You will most likely see something like {{ic|Denied RWX}} in journalctl. That means you will need to disable MPROTECT for the program {{ic|paxctl -cPEmRXS /usr/bin/bla}}<br />
<br />
After you find what PaX flags need to be set post a comment on the linux-pax-flags AUR package so it can be added.<br />
<br />
= Tips and Tricks =<br />
<br />
Because you will not be able to change the PaX flags for a running program, and that the vast majority of programs which would need them are graphical, it is strongly advisable to not use a Graphical Login like GDM or KDM. Instead simply have the system drop you to a console to log in and use {{ic|startx}}. Then you will have a chance to set the PaX flags before anything starts. For the same reasons it is strongly advisable to update your system and run {{ic|linux-pax-flags}} right after boot, before running {{ic|startx}}.<br />
<br />
Grsecurity will harden /proc and /sys so your normal user will no longer be able to see the network status, becuase of this non of your desktop network monitors will work. Instead just install terminal based monitoring programs, such as [https://www.archlinux.org/packages/community/x86_64/nmon/ nmon] or [https://www.archlinux.org/packages/community/x86_64/nload/ nload] and run them as root, or as a user in the proc-trusted group.</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Security&diff=272338Security2013-08-24T10:03:14Z<p>Hunterthomson: /* Grsecurity RBAC */ Fixed Wiki link to be more direct i.e. Grsecurity_Patchset#RBAC not Grsecurity#RBAC</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[ru:Security]]<br />
{{expansion|<br />
Many of these categories are just links, or lists of links. Some of the language is repetitive or unclear.}}<br />
{{Article summary start}}<br />
{{Article summary text|This article contains recommendations and best practices for hardening an Arch Linux system.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|List of Applications/Security}}<br />
{{Article summary wiki|:Category:Security}}<br />
{{Article summary end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
==Concepts==<br />
*It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
*There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user himself. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
*Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
*The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
==Kernel Hardening==<br />
The Linux Kernel is insecure by default. It allows far more access to sensitive information then is needed and only provides minimal memory exploitation protections. The [https://grsecurity.net/ Grsecurity Patchset] aims to fix this. Grsecurity ships bundled with the PaX memory patches. PaX invented ALSR and provides far more protections then just that. Grsecurity hardens the file system, provides an advanced Role Based Access Control system and, and prevents information leaks which render PaX memory protections useless.<br />
<br />
Grsecurity has it's own Wiki page that can be found [https://wiki.archlinux.org/index.php/Grsecurity_Patchset Grsecurity Patchset Arch Wiki]<br />
<br />
==Passwords==<br />
Passwords are key to a secure linux system. They secure your [[Users and Groups|user accounts]], [[Disk Encryption|encrypted filesystems]], and [[SSH Keys|ssh]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
It is important that your passwords cannot be easily [[Wikipedia:Password cracking|cracked]] or guessed from personal information. For this reason, do not to use a dictionary word or something like your dog's name. A password should be at least eight characters long, with a mix of upper and lower case letters. It should include at least one number and/or one special character. As expected, longer, more complex passwords are generally better.<br />
<br />
Tools like {{Pkg|pwgen}} and {{Pkg|apg}} can help you generate secure passwords.<br />
<br />
Alternately you can make a password using the first characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to “t6!WdtR5”. This approach could make it easier to remember a password. Or, if you do not mind typing you could make it “The girl is walking down the rainy street.”<br />
<br />
===Maintaining passwords===<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. Tools like {{Pkg|pass}}, {{Pkg|keepassx}}, and {{Pkg|gnome-keyring}} can help manage large numbers of complex passwords. [[Wikipedia:LastPass Password Manager|Lastpass]] is a service that stores encrypted passwords online for synchronization between devices, but requires that you trust both closed-source code and an external corporation.<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
==Physical security==<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
Physical access to a computer is basically root access, but you can stop an attacker from having access without removing your hard drive (also see [[#Disk encryption]]) or resetting your BIOS settings (both of which involve opening the computer). <br />
<br />
===Locking down BIOS===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
===Bootloaders===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
====Syslinux====<br />
<br />
[[Syslinux]] has two levels of bootloader security: a menu master password, and a per-menu-item password. In {{ic|syslinux.cfg}}, use<br />
{{bc|<br />
MENU MASTER PASSWD passwd <br />
}}<br />
to set a master bootloader password, and<br />
{{bc|<br />
MENU PASSWD passwd <br />
}}<br />
within a {{ic|LABEL}} block to password-protect individual boot items.<br />
<br />
====GRUB====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB#Security]] for details.<br />
<br />
==Partitions==<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
===Mount options===<br />
<br />
Following the principle of least privilege, partitions should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
====Relevant mount options====<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
====Potential usage====<br />
<br />
{{Note|Data partitions should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}.}}<br />
<br />
{|<br />
| align="center" style="background:#f0f0f0;"|'''Partition'''<br />
| align="center" style="background:#f0f0f0;"|{{ic|nodev}}<br />
| align="center" style="background:#f0f0f0;"|{{ic|nosuid}}<br />
| align="center" style="background:#f0f0f0;"|{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1]</sup><br />
|- style="background:#e4e4e4"<br />
| {{ic|/home}}||yes||yes||yes, if you do not code or use wine<br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|- style="background:#e4e4e4"<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{AUR|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
==Filesystem permissions==<br />
The default filesystem permissions allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the http or nobody users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Setting the UMASK]].<br />
<br />
==Disk encryption==<br />
<br />
[[Disk Encryption]], preferably full disk encryption with a [[Disk Encryption#Choosing a strong passphrase|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[TrueCrypt#Encrypting a file as a virtual_volume|TrueCrypt]], allow the user to encrypt a single file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure. [[TrueCrypt#Creating a hidden volume|Hidden volumes]] create another layer of security, introducing [[Wikipedia:TrueCrypt#Plausible deniability|plausible deniability]] for encrypted data.<br />
<br />
==User setup==<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
===Password hashes===<br />
The default Arch hash [[SHA_password_hashes|sha512]] is very strong and there is no need to change it. By default, passwords are hashed in {{ic|/etc/shadow}}, readable only by root, and only user identifiers are stored in {{ic|/etc/passwd}}, therefore, as long as the [[Security#Restricting root|root user is secured]], the file cannot be copied and cracked on an external system.<br />
<br />
=== Automatic logout ===<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}}, so you will never forget an open virtual console shell (where screensavers cannot protect you):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very usefull.<br />
<br />
===Lockout user after three failed login attempts===<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
== Restricting root ==<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
===Use sudo instead of su===<br />
Using [[sudo]] for privileged access is preferable to [[Su|su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command). For example, to give the user ''alice'' access to a particular program:<br />
<br />
{{bc|<br />
# visudo<br />
}}<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|To use {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/nano<br />
}}<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
====Editing files using sudo====<br />
Using a text editor like {{ic|vim}} as root is a security vulnerability as it allows one to execute arbitrary shell commands, and does not log the user who executed the commands. To solve this, add<br />
<br />
{{bc|<br />
EXPORT SUDO_EDITOR&#61;rvim<br />
}}<br />
to your shell's configuration file and use {{ic|sudoedit filename}} or {{ic|sudo -e filename}} to edit files. This will automatically edit {{ic|filename}} with {{ic|rvim}}, disabling shell commands from within your text editor.<br />
<br />
===Restricting root login===<br />
Once [[Sudo|sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability.<br />
<br />
====Allow only certain users====<br />
The [[Wikipedia:Pluggable authentication module|PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit {{ic|/etc/pam.d/su}} and uncomment the line:<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
====Denying console login====<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a user-name that exists on the system and that users password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
====Denying ssh login====<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny_root_login|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control | Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control | discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
===Pathname MAC===<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical | Canonical]]-developed MAC implementation designed as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
===Grsecurity RBAC===<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
*[https://wiki.archlinux.org/index.php/Grsecurity_Patchset#RBAC RBAC] has a learning mode like AppArmor for easy configureation<br />
<br />
===Labels MAC===<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA | NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
[[Wikipedia:Access control list | Access control lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
*[[grsecurity]] implements ACL access control, as well as a complete kernel patchset focused on improving security. Its changes extend to control of memory allocation, improved chroot restrictions, and rules involving specific network behavior.<br />
<br />
==Network and Firewalls==<br />
<br />
===Firewalls===<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to install {{Pkg|iptables}} from the [[Official Repositories|official repositories]], enable it, and set up some form of firewall.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
<br />
===Kernel parameters===<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
===SSH===<br />
Avoid using [[Secure Shell]] without [[SSH Keys#Disabling password logins|requiring SSH keys]]. This helps against [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]].<br />
<br />
[[Secure Shell#Deny root login|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
==Authenticating packages==<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
==See also==<br />
* ArchWiki's Current list of security applications: [https://wiki.archlinux.org/index.php/List_of_Applications/Security Lists of Applications: Security]<br />
* [https://wiki.archlinux.org/index.php/Grsecurity_Patchset Grsecurity Patchset]<br />
* [http://www.puschitz.com/SecuringLinux.shtml Securing and Hardening Red Hat Linux Production Systems]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the linux desktop]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the linux server]<br />
* [http://www.faqs.org/docs/securing/index.html Securing and Optimizing Linux]<br />
* [http://www.auscert.org.au/5816 UNIX and Linux Security Checklist v3.0]<br />
* [http://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Security&diff=272337Security2013-08-24T10:02:23Z<p>Hunterthomson: /* See also */ Fixed wiki link yet again to be more direct... i.e. Grsecurity_Patchset not Grsecurity</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[ru:Security]]<br />
{{expansion|<br />
Many of these categories are just links, or lists of links. Some of the language is repetitive or unclear.}}<br />
{{Article summary start}}<br />
{{Article summary text|This article contains recommendations and best practices for hardening an Arch Linux system.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|List of Applications/Security}}<br />
{{Article summary wiki|:Category:Security}}<br />
{{Article summary end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
==Concepts==<br />
*It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
*There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user himself. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
*Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
*The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
==Kernel Hardening==<br />
The Linux Kernel is insecure by default. It allows far more access to sensitive information then is needed and only provides minimal memory exploitation protections. The [https://grsecurity.net/ Grsecurity Patchset] aims to fix this. Grsecurity ships bundled with the PaX memory patches. PaX invented ALSR and provides far more protections then just that. Grsecurity hardens the file system, provides an advanced Role Based Access Control system and, and prevents information leaks which render PaX memory protections useless.<br />
<br />
Grsecurity has it's own Wiki page that can be found [https://wiki.archlinux.org/index.php/Grsecurity_Patchset Grsecurity Patchset Arch Wiki]<br />
<br />
==Passwords==<br />
Passwords are key to a secure linux system. They secure your [[Users and Groups|user accounts]], [[Disk Encryption|encrypted filesystems]], and [[SSH Keys|ssh]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
It is important that your passwords cannot be easily [[Wikipedia:Password cracking|cracked]] or guessed from personal information. For this reason, do not to use a dictionary word or something like your dog's name. A password should be at least eight characters long, with a mix of upper and lower case letters. It should include at least one number and/or one special character. As expected, longer, more complex passwords are generally better.<br />
<br />
Tools like {{Pkg|pwgen}} and {{Pkg|apg}} can help you generate secure passwords.<br />
<br />
Alternately you can make a password using the first characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to “t6!WdtR5”. This approach could make it easier to remember a password. Or, if you do not mind typing you could make it “The girl is walking down the rainy street.”<br />
<br />
===Maintaining passwords===<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. Tools like {{Pkg|pass}}, {{Pkg|keepassx}}, and {{Pkg|gnome-keyring}} can help manage large numbers of complex passwords. [[Wikipedia:LastPass Password Manager|Lastpass]] is a service that stores encrypted passwords online for synchronization between devices, but requires that you trust both closed-source code and an external corporation.<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
==Physical security==<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
Physical access to a computer is basically root access, but you can stop an attacker from having access without removing your hard drive (also see [[#Disk encryption]]) or resetting your BIOS settings (both of which involve opening the computer). <br />
<br />
===Locking down BIOS===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
===Bootloaders===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
====Syslinux====<br />
<br />
[[Syslinux]] has two levels of bootloader security: a menu master password, and a per-menu-item password. In {{ic|syslinux.cfg}}, use<br />
{{bc|<br />
MENU MASTER PASSWD passwd <br />
}}<br />
to set a master bootloader password, and<br />
{{bc|<br />
MENU PASSWD passwd <br />
}}<br />
within a {{ic|LABEL}} block to password-protect individual boot items.<br />
<br />
====GRUB====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB#Security]] for details.<br />
<br />
==Partitions==<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
===Mount options===<br />
<br />
Following the principle of least privilege, partitions should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
====Relevant mount options====<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
====Potential usage====<br />
<br />
{{Note|Data partitions should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}.}}<br />
<br />
{|<br />
| align="center" style="background:#f0f0f0;"|'''Partition'''<br />
| align="center" style="background:#f0f0f0;"|{{ic|nodev}}<br />
| align="center" style="background:#f0f0f0;"|{{ic|nosuid}}<br />
| align="center" style="background:#f0f0f0;"|{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1]</sup><br />
|- style="background:#e4e4e4"<br />
| {{ic|/home}}||yes||yes||yes, if you do not code or use wine<br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|- style="background:#e4e4e4"<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{AUR|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
==Filesystem permissions==<br />
The default filesystem permissions allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the http or nobody users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Setting the UMASK]].<br />
<br />
==Disk encryption==<br />
<br />
[[Disk Encryption]], preferably full disk encryption with a [[Disk Encryption#Choosing a strong passphrase|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[TrueCrypt#Encrypting a file as a virtual_volume|TrueCrypt]], allow the user to encrypt a single file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure. [[TrueCrypt#Creating a hidden volume|Hidden volumes]] create another layer of security, introducing [[Wikipedia:TrueCrypt#Plausible deniability|plausible deniability]] for encrypted data.<br />
<br />
==User setup==<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
===Password hashes===<br />
The default Arch hash [[SHA_password_hashes|sha512]] is very strong and there is no need to change it. By default, passwords are hashed in {{ic|/etc/shadow}}, readable only by root, and only user identifiers are stored in {{ic|/etc/passwd}}, therefore, as long as the [[Security#Restricting root|root user is secured]], the file cannot be copied and cracked on an external system.<br />
<br />
=== Automatic logout ===<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}}, so you will never forget an open virtual console shell (where screensavers cannot protect you):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very usefull.<br />
<br />
===Lockout user after three failed login attempts===<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
== Restricting root ==<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
===Use sudo instead of su===<br />
Using [[sudo]] for privileged access is preferable to [[Su|su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command). For example, to give the user ''alice'' access to a particular program:<br />
<br />
{{bc|<br />
# visudo<br />
}}<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|To use {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/nano<br />
}}<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
====Editing files using sudo====<br />
Using a text editor like {{ic|vim}} as root is a security vulnerability as it allows one to execute arbitrary shell commands, and does not log the user who executed the commands. To solve this, add<br />
<br />
{{bc|<br />
EXPORT SUDO_EDITOR&#61;rvim<br />
}}<br />
to your shell's configuration file and use {{ic|sudoedit filename}} or {{ic|sudo -e filename}} to edit files. This will automatically edit {{ic|filename}} with {{ic|rvim}}, disabling shell commands from within your text editor.<br />
<br />
===Restricting root login===<br />
Once [[Sudo|sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability.<br />
<br />
====Allow only certain users====<br />
The [[Wikipedia:Pluggable authentication module|PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit {{ic|/etc/pam.d/su}} and uncomment the line:<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
====Denying console login====<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a user-name that exists on the system and that users password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
====Denying ssh login====<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny_root_login|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control | Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control | discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
===Pathname MAC===<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical | Canonical]]-developed MAC implementation designed as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
===Grsecurity RBAC===<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
*[https://wiki.archlinux.org/index.php/Grsecurity#RBAC RBAC] has a learning mode like AppArmor for easy configureation<br />
<br />
===Labels MAC===<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA | NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
[[Wikipedia:Access control list | Access control lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
*[[grsecurity]] implements ACL access control, as well as a complete kernel patchset focused on improving security. Its changes extend to control of memory allocation, improved chroot restrictions, and rules involving specific network behavior.<br />
<br />
==Network and Firewalls==<br />
<br />
===Firewalls===<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to install {{Pkg|iptables}} from the [[Official Repositories|official repositories]], enable it, and set up some form of firewall.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
<br />
===Kernel parameters===<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
===SSH===<br />
Avoid using [[Secure Shell]] without [[SSH Keys#Disabling password logins|requiring SSH keys]]. This helps against [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]].<br />
<br />
[[Secure Shell#Deny root login|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
==Authenticating packages==<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
==See also==<br />
* ArchWiki's Current list of security applications: [https://wiki.archlinux.org/index.php/List_of_Applications/Security Lists of Applications: Security]<br />
* [https://wiki.archlinux.org/index.php/Grsecurity_Patchset Grsecurity Patchset]<br />
* [http://www.puschitz.com/SecuringLinux.shtml Securing and Hardening Red Hat Linux Production Systems]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the linux desktop]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the linux server]<br />
* [http://www.faqs.org/docs/securing/index.html Securing and Optimizing Linux]<br />
* [http://www.auscert.org.au/5816 UNIX and Linux Security Checklist v3.0]<br />
* [http://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]</div>Hunterthomsonhttps://wiki.archlinux.org/index.php?title=Security&diff=272336Security2013-08-24T10:01:22Z<p>Hunterthomson: /* Kernel Hardening */ Typo... I need to get some sleep *hand to face</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[ru:Security]]<br />
{{expansion|<br />
Many of these categories are just links, or lists of links. Some of the language is repetitive or unclear.}}<br />
{{Article summary start}}<br />
{{Article summary text|This article contains recommendations and best practices for hardening an Arch Linux system.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|List of Applications/Security}}<br />
{{Article summary wiki|:Category:Security}}<br />
{{Article summary end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
==Concepts==<br />
*It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
*There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user himself. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
*Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
*The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
==Kernel Hardening==<br />
The Linux Kernel is insecure by default. It allows far more access to sensitive information then is needed and only provides minimal memory exploitation protections. The [https://grsecurity.net/ Grsecurity Patchset] aims to fix this. Grsecurity ships bundled with the PaX memory patches. PaX invented ALSR and provides far more protections then just that. Grsecurity hardens the file system, provides an advanced Role Based Access Control system and, and prevents information leaks which render PaX memory protections useless.<br />
<br />
Grsecurity has it's own Wiki page that can be found [https://wiki.archlinux.org/index.php/Grsecurity_Patchset Grsecurity Patchset Arch Wiki]<br />
<br />
==Passwords==<br />
Passwords are key to a secure linux system. They secure your [[Users and Groups|user accounts]], [[Disk Encryption|encrypted filesystems]], and [[SSH Keys|ssh]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
It is important that your passwords cannot be easily [[Wikipedia:Password cracking|cracked]] or guessed from personal information. For this reason, do not to use a dictionary word or something like your dog's name. A password should be at least eight characters long, with a mix of upper and lower case letters. It should include at least one number and/or one special character. As expected, longer, more complex passwords are generally better.<br />
<br />
Tools like {{Pkg|pwgen}} and {{Pkg|apg}} can help you generate secure passwords.<br />
<br />
Alternately you can make a password using the first characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to “t6!WdtR5”. This approach could make it easier to remember a password. Or, if you do not mind typing you could make it “The girl is walking down the rainy street.”<br />
<br />
===Maintaining passwords===<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. Tools like {{Pkg|pass}}, {{Pkg|keepassx}}, and {{Pkg|gnome-keyring}} can help manage large numbers of complex passwords. [[Wikipedia:LastPass Password Manager|Lastpass]] is a service that stores encrypted passwords online for synchronization between devices, but requires that you trust both closed-source code and an external corporation.<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
==Physical security==<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
Physical access to a computer is basically root access, but you can stop an attacker from having access without removing your hard drive (also see [[#Disk encryption]]) or resetting your BIOS settings (both of which involve opening the computer). <br />
<br />
===Locking down BIOS===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
===Bootloaders===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
====Syslinux====<br />
<br />
[[Syslinux]] has two levels of bootloader security: a menu master password, and a per-menu-item password. In {{ic|syslinux.cfg}}, use<br />
{{bc|<br />
MENU MASTER PASSWD passwd <br />
}}<br />
to set a master bootloader password, and<br />
{{bc|<br />
MENU PASSWD passwd <br />
}}<br />
within a {{ic|LABEL}} block to password-protect individual boot items.<br />
<br />
====GRUB====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB#Security]] for details.<br />
<br />
==Partitions==<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
===Mount options===<br />
<br />
Following the principle of least privilege, partitions should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
====Relevant mount options====<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
====Potential usage====<br />
<br />
{{Note|Data partitions should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}.}}<br />
<br />
{|<br />
| align="center" style="background:#f0f0f0;"|'''Partition'''<br />
| align="center" style="background:#f0f0f0;"|{{ic|nodev}}<br />
| align="center" style="background:#f0f0f0;"|{{ic|nosuid}}<br />
| align="center" style="background:#f0f0f0;"|{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1]</sup><br />
|- style="background:#e4e4e4"<br />
| {{ic|/home}}||yes||yes||yes, if you do not code or use wine<br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|- style="background:#e4e4e4"<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{AUR|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
==Filesystem permissions==<br />
The default filesystem permissions allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the http or nobody users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Setting the UMASK]].<br />
<br />
==Disk encryption==<br />
<br />
[[Disk Encryption]], preferably full disk encryption with a [[Disk Encryption#Choosing a strong passphrase|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[TrueCrypt#Encrypting a file as a virtual_volume|TrueCrypt]], allow the user to encrypt a single file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure. [[TrueCrypt#Creating a hidden volume|Hidden volumes]] create another layer of security, introducing [[Wikipedia:TrueCrypt#Plausible deniability|plausible deniability]] for encrypted data.<br />
<br />
==User setup==<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
===Password hashes===<br />
The default Arch hash [[SHA_password_hashes|sha512]] is very strong and there is no need to change it. By default, passwords are hashed in {{ic|/etc/shadow}}, readable only by root, and only user identifiers are stored in {{ic|/etc/passwd}}, therefore, as long as the [[Security#Restricting root|root user is secured]], the file cannot be copied and cracked on an external system.<br />
<br />
=== Automatic logout ===<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}}, so you will never forget an open virtual console shell (where screensavers cannot protect you):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very usefull.<br />
<br />
===Lockout user after three failed login attempts===<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
== Restricting root ==<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
===Use sudo instead of su===<br />
Using [[sudo]] for privileged access is preferable to [[Su|su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command). For example, to give the user ''alice'' access to a particular program:<br />
<br />
{{bc|<br />
# visudo<br />
}}<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|To use {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/nano<br />
}}<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
====Editing files using sudo====<br />
Using a text editor like {{ic|vim}} as root is a security vulnerability as it allows one to execute arbitrary shell commands, and does not log the user who executed the commands. To solve this, add<br />
<br />
{{bc|<br />
EXPORT SUDO_EDITOR&#61;rvim<br />
}}<br />
to your shell's configuration file and use {{ic|sudoedit filename}} or {{ic|sudo -e filename}} to edit files. This will automatically edit {{ic|filename}} with {{ic|rvim}}, disabling shell commands from within your text editor.<br />
<br />
===Restricting root login===<br />
Once [[Sudo|sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability.<br />
<br />
====Allow only certain users====<br />
The [[Wikipedia:Pluggable authentication module|PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit {{ic|/etc/pam.d/su}} and uncomment the line:<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
====Denying console login====<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a user-name that exists on the system and that users password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
====Denying ssh login====<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny_root_login|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control | Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control | discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
===Pathname MAC===<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical | Canonical]]-developed MAC implementation designed as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
===Grsecurity RBAC===<br />
The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.<br />
<br />
*[https://wiki.archlinux.org/index.php/Grsecurity#RBAC RBAC] has a learning mode like AppArmor for easy configureation<br />
<br />
===Labels MAC===<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA | NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
[[Wikipedia:Access control list | Access control lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
*[[grsecurity]] implements ACL access control, as well as a complete kernel patchset focused on improving security. Its changes extend to control of memory allocation, improved chroot restrictions, and rules involving specific network behavior.<br />
<br />
==Network and Firewalls==<br />
<br />
===Firewalls===<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to install {{Pkg|iptables}} from the [[Official Repositories|official repositories]], enable it, and set up some form of firewall.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
<br />
===Kernel parameters===<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
===SSH===<br />
Avoid using [[Secure Shell]] without [[SSH Keys#Disabling password logins|requiring SSH keys]]. This helps against [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]].<br />
<br />
[[Secure Shell#Deny root login|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
==Authenticating packages==<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
==See also==<br />
* ArchWiki's Current list of security applications: [https://wiki.archlinux.org/index.php/List_of_Applications/Security Lists of Applications: Security]<br />
* [https://wiki.archlinux.org/index.php/Grsecurity Grsecurity]<br />
* [http://www.puschitz.com/SecuringLinux.shtml Securing and Hardening Red Hat Linux Production Systems]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the linux desktop]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the linux server]<br />
* [http://www.faqs.org/docs/securing/index.html Securing and Optimizing Linux]<br />
* [http://www.auscert.org.au/5816 UNIX and Linux Security Checklist v3.0]<br />
* [http://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]</div>Hunterthomson