Gentoo SELinux HandbookContent:
A. Installing Gentoo SELinux1. Gentoo SELinux Installation1.a. Gentoo SELinux Installation
The installation of Gentoo SELinux is the same as regular Gentoo. The regular install should be followed from the Gentoo Handbook, keeping in mind the following notes. Then the system should converted to SELinux using the SELinux Conversion Guide. Only ext2, ext3, JFS and XFS are supported at this time. XFS users should use 512 byte inodes (the default is 256). SELinux uses extended attributes for storing security labels in files. XFS stores this in the inode, and if the inode is too small, an extra block has to be used, which wastes a lot of space, and incurs performace penalties.
You can save time by looking ahead to the kernel options required for SELinux, to save compiling the kernel multiple times. B. Converting to Gentoo SELinux1. Initial preparations
First switch your profile to the SELinux profile for your architecture:
We will start by updating essential packages. First check which version of linux-headers is installed.
If the linux-headers version is older than 2.4.20, newer headers must be merged.
If you have merged new headers, or you are unsure if your glibc was compiled with newer headers, you must recompile glibc.
2. Boot SELinux KernelMerge an appropriate kernel. A 2.6 kernel is required. The suggested kernel is hardened-sources.
2.b. Compile the Kernel with SELinux Options The kernel must be compiled with security module support, SELinux support, devpts, and extended attribute security labels. Refer to the main installation guide for futher kernel options.
The extended attribute security labels must be turned on for devpts and your filesystem(s). Devfs is not usable in SELinux, and should be turned off. Not all options exist on older 2.6 kernels, such as Auditing support, and runtime disable. In newer kernels, the extended attributes support for proc and the virtual memory fs (tmpfs) are enabled by default; thus, no options will appear in menuconfig.
Now compile and install the kernel and modules, but do not reboot. SElinuxfs must also be enabled to mount at boot. Add this to /etc/fstab:
SELinux does not support devfs. You must configure baselayout to use either static device nodes or udev. If using udev, the device tarball must be disabled. Edit the /etc/conf.d/rc file. Set RC_DEVICES to static or udev, and RC_DEVICE_TARBALL to no. If you have several custom device nodes, static is suggested, otherwise udev is suggested.
We need to make some directories before we reboot.
Now reboot. 3. Install SELinux UserlandMerge the libraries, utilities and base-policy. The policy version may need be adjusted, refer to the SELinux Overview for more information on policy versions. Then load the policy.
New in 2006.1, users now have the choice between the strict policy and the targeted policy. In the strict policy, all processes are confined. If you are familiar with pre 2006.1 Gentoo SELinux policy, that policy was a strict policy. Strict policy is suggested for servers. Gentoo does not support the strict policy on desktops. The targeted policy differs with strict, as only network-facing services are confined and local users are unconfined. Gentoo only supports desktops with the targeted policy. This policy can also be used on servers. Edit the /etc/selinux/config file to set the policy type.
3.c. Merge SELinux-patched packages There are several system packages that have SELinux patches. These patches provide a variety of additional SELinux functionality, such as displaying file contexts.
There are other packages that have SELinux patches, but are optional. These should be remerged if they are already installed, so the SELinux patches are applied:
3.d. Merge Application Policies In future, when merging a package, the policy will be set as a dependency so that it is merged first; however, since the system is being converted, policy for currently installed packages must be merged. The selinux-base-policy already covers most packages in the system profile. Look in the /usr/portage/sec-policy, it has several entries, each which represent a policy. The naming scheme is selinux-PKGNAME, where PKGNAME is the name of the package that the policy is associated. For example, the selinux-apache package is the SELinux policy package for net-www/apache. Merge each of the needed policy packages and then load the policy. If you are converting a desktop, make sure to include the selinux-desktop policy package.
Now label the filesystems. This gives each of the files in the filesystems a security label. Keeping these labels consistent is important.
Reboot. Log in, then relabel again to ensure all files are labeled correctly (some files may have been created during shutdown and reboot)
SELinux is now installed! C. Working with SELinux1. SELinux OverviewA type is a security attribute given to objects such as files, and network ports, etc. The type of a process is commonly referred to as its domain. The SELinux policy is primarily composed of type enforcement rules, which describe how domains are allowed to interact with objects, and how domains are allowed to interact with other domains. A type is generally suffixed with a '_t', such as sysadm_t. This is the most important attribute for a process or object, as most policy decisions are based on the source and target types. SELinux is type enforcement, so the SELinux role is not the same as those in a role-based access control system. Permissions are not given to roles. A role describes the set of types a user can use. For example, a system administrator that is using the system for regular user tasks should be in the staff_r role. If they need to administrate the system, then a role change to sysadm_r is required. In SELinux terms, the domains that a user can be in is determined by their role. If a role is not allowed to have a certain domain, a transition to that domain will be denied, even if the type enforcement rules allow the domain transition. A role is generally suffixed with a '_r', such as system_r. The SELinux identity is similar to a Linux username. The change of identity should be limited to very specific cases, since the role-based access control relies on the SELinux identity. Therfore, in general, a user’s SELinux identity will not change during a session. The user ID in Linux can be changed by set(e)uid, making it inappropriate for a SELinux identity. If a user is given a SELinux identity, it must match the Linux username. Each SELinux identity is allowed a set of roles. Configure SELinux Identity Mapping The SELinux policy has several generic SELinux identities that should be sufficient for all users. This mapping only needs to be configured on the strict policy. The identity mapping for the targeted policy need not be configured, as the default identity (user_u) is sufficient in all cases. When a user logs in, the SELinux identity used is determined by this mapping.
See the SELinux HOWTO for semanage syntax for configuring SELinux identity mappings. Using the above three security models together is called a SELinux context. A context takes the form identity:role:type. The SELinux context is the most important value for determining access. A typical ls -Z may have an output similar to this:
The first three columns are the typical linux permissions, user and group. The fourth column is the file or directory's security context. Objects are given the generic object_r role. From the other two fields of the context, it can be seen that the files are in the system identity, and have four different types, bin_t, boot_t, device_t, and etc_t. A typical ps ax -Z may have an output similar to this:
In this example, the typical process information is displayed, in addition to the process's context. By inspection, all of the system's kernel processes and daemons run under the system_u identity, and system_r role. The individual domains depend on the program. There are a few users logged in over ssh, using the generic user_u identity. Finally there is a user with the identity pebenito logged in with the staff_r role, running in the staff_t domain. The SELinux policy source files are no longer installed onto the system. In the /usr/share/selinux/{strict,targeted} directory there are a collection of policy packages and headers for building local modules. The policy files are processed by m4, and then the policy compiler checkmodule verifies that there are no syntactic errors, and a policy module is created. Then a policy package is created with with the semodule_package program, using the policy module and the module file contexts. The policy packaged then can be loaded into a running SELinux kernel by inserting it into the module store. Policy packages for this policy. These must be inserted into the module store so they can be loaded into the policy. Inside the package there is a loadable policy module, and optionally a file context file. Policy headers for this policy. When compiling the policy, the resultant binary policy is versioned. The first version that was merged into 2.6 was version 15. The version number is only incremented generally when new features are added that require changes to the structure of the compiled policy. For example, in 2.6.5, conditional policy extensions were added. This required the policy version to be incremented to version 16. What Policy Version Does My Kernel Use? The policy version of a running kernel can be determined by executing sestatus or policyvers. Current kernels can load the previous version policy for compatibility. For example a version 17 kernel can also load a version 16 policy. However, this compatibility code may be removed in the future.
The following table contains the policy versions in 2.6 kernels.
1.g. Conditional Policy Extensions The conditional policy extensions allow the enabling and disabling of policy rules at runtime, without loading a modified policy. Using policy booleans and expressions, policy rules can be conditionally applied. The status of policy booleans in the current running policy can be determined two ways. The first is by using sestatus.
The second is getsebool which is a simple tool that displays the status of policy booleans, and if a value change is pending.
The value of a boolean can be toggled by using the togglesebool command. Multiple booleans can be specified on the command line. The new value of the boolean will be displayed.
The value of a boolean can be set specifically by using the setsebool command.
To set the value of a boolean, and make it the devault value, use the -P option.
While a system is running, a program or user may attempt to do something that violates the security policy. If the system is enforcing the policy, the access will be denied, and there will be a message in the kernel log. If the system is not enforcing (permissive mode), the access will be allowed, but there will still be a kernel message. Most kernel messages from SELinux come from the access vector cache (AVC). Understanding denials is important to understand if an attack is happening, or if the program is requiring unexpected accesses. An example denial may look like this:
While most AVC messages are denials, occasionally there might be an audit message for an access that was granted:
In this case, the ability to load the policy was granted. This is a critical security event, and thus is always audited. Another event that is always audited is switching between enforcing and permissive modes. SELinux will supress logging of denials if many are received in a short amount of time. However, This does not always imply there is an attack in progress. A program may be doing something that could cause many denials in a short time, such as doing a stat() on device nodes in /dev. To protect from filling up the system logs, SELinux has rate limiting for its messages:
The policy would have to be modified to not audit these accesses if they are normal program behavior, but still need to be denied.
This means that the file on /dev/hda3 with inode number 517610 has the context system_u:object_r:bar_t, which is invalid. Objects with an invalid context are treated as if they had the system_u:object_r:unlabeled_t context. Denials contain varying amounts of information, depending on the access type.
The most common denial relates to access of files. For better understanding, the first denial message will be broken down:
Not all AVC messages will have all of these fields, as shown in the other two denials. The fields vary depending on the target object's class. However, the most important fields: access type, source and target contexts, and the target object's class will always be in an AVC message. Denials can be very confusing since they can be triggered for several reasons. The key to understanding what is happening is to know the behavior of the program, and to correctly interpret the denial message. The target is not limited to files; it could also be related to network sockets, interprocess communications, or others. In the above example, the agetty is denied locking of a file. The file's type is var_log_t, therefore it is implied that the target file is in /var/log. With the extra information from the path= field in the denial message, it is confirmed to be the file /var/log/wtmp. If path information was unavailable, this could be further confirmed by searching for the inode. Wtmp is a file that has information about users currently logged in, and agetty handles logins on ttys. It can be concluded that this is an expected access of agetty, for updating wtmp. However, why is this access being denied? Is there a flaw in the policy by not allowing agetty to update wtmp? It turns out that wtmp has the incorrect context. It should be system_u:object_r:wtmp_t, rather than system_u:object_r:var_log_t. If this access was not understood, an administrator might mistakenly allow getty_t read/write access to var_log_t files, which would be incorrect, since agetty only needs to modify /var/log/wtmp. This underscores how critical keeping file contexts consistent is. U.S. National Security Agency, SELinux Policy README 2. SELinux HOWTO2.a. Load policy into a running SELinux kernel This requires you to be in the sysadm_r role.
This requires your user have access to the target role. This example is for changing to the sysadm_r role.
2.c. Specify available roles for a user There is a mapping of linux users to SELinux identities. The policy has generic SELinux users for relevant configurations of roles. For example, to map the user pebenito to the SELinux identity staff_u, run:
The policy does not need to be reloaded. If the user is logged in, it must log out and log in again to take effect. This requires you to be in the sysadm_r role.
2.e. Relabel an individual package In addition to relabeling entire filesystems, individual portage packages can be relabeled. This requires you to be in the sysadm_r role.
The script rlpkg is used, and any number of packages can be specified on the command line. 2.f. Scan for libraries with text relocations SELinux has improved memory protections. One feature supported is the permission for ELF text relocations. The libraries with text relocations have a special label, and the rlpkg tool has an option to scan for these libraries.
This will also be done by automatically after a full relabel. 2.g. Start daemons in the correct domain Controlling daemons that have init scripts in /etc/init.d is slightly different in SELinux. The run_init command must be used to run the scripts, to ensure they are ran in the correct domain. The command can be ran normally, except the command is prefixed with run_init. This requires you to be in the sysadm_r role.
run_init has been integrated into Gentoo's init script system. With SELinux installed, services can be started and stopped as usual, but will now authenticate the user.
2.h. Switch between enforcing and permissive modes Switching between modes in SELinux is very simple. Write a 1 for enforcing, or 0 for permissive to /selinux/enforce to set the mode. The current mode can be queried by reading /selinux/enforce; 0 means permissive mode, and 1 means enforcing mode. If the kernel option "NSA SELinux Development Support" is turned off, the system will always be in enforcing mode, and cannot be switched to permissive mode.
A machine with development support turned on can be started in enforcing mode by adding enforcing=1 to the kernel command line, in the bootloader (GRUB, lilo, etc). In addition to the above kernel options, the mode at boot can be set by the /etc/selinux/config file.
The setting in this file will be overridden by the kernel command line options described above. 2.i. Understand sestatus output The sestatus tool can be used to determine detailed SELinux-specific status information about the system. The -v option provides extra detail about the context of processes and files. The output will be divided into four sections. Sestatus only provides complete information for a user logged in as root (or su/sudo), in the sysadm_r role.
The main status information is provided in the first section. The first line shows if SELinux kernel functions exists and are enabled. If the status is disabled, either the kernel does not have SELinux support, or the policy is not loaded. The second line shows the mount point for the SELinux filesystem. During the normal use, the filesystem should be mounted at the default location of /selinux. The third line shows the current SELinux mode, either enforcing or permissive. The fourth line shows the policy database version supported by the currently running kernel.
The second section displays the status of the conditional policy booleans. The left column is the name of boolean. The right column is the status of the boolean, either active, or inactive. This section will not be shown on policy version 15 kernels, as they do not support conditional policy.
The third section displays the context of the current process, and of several key processes. If a process is running in the incorrect context, it will not function correctly.
The fourth section displays the context of the current process's controlling terminal, and of several key files. For symbolic links, the context of the link and then the context of the link target is displayed. If a file has an incorrect context, the file may be inaccessable or have incorrect permissions for a particular process. 3. SELinux FAQDoes SELinux enforce resource limits? No, resource limits are outside the scope of an access control system. If you are looking for this type of support, GRSecurity and RSBAC are better choices. 3.b. SELinux and other hardened projects Can I use SELinux and GRSecurity (and PaX)? Yes, SELinux can be used with GRSecurity and/or PaX with no problems; however, it is suggested that GRACL should not be used, since it would be redundant to SELinux's access control. Can I use SELinux and the hardened compiler (PIE-SSP)? Yes. It is also suggested that PaX be used to take full advantage of the PIE features of the compiler. Unknown. Please report your results if you try this combination. Can I use SELinux with my primary filesystems? SELinux can be used with ext2, ext3, JFS, and XFS. Reiserfs (Reiser3) has extended attributes, but the support was never complete, and has been broken since 2.6.14. Reiser4 is not supported. Can I use SELinux with my ancillary filesystems? Yes, SELinux can mount ancillary filesystems, such as vfat and iso9660 filesystems, with an important caveat. All files in each filesystem will have the same SELinux type, since the filesystems do not support extended attributes. Tmpfs is the only ancillary filesystem with complete extended attribute support, which allows it to behave like a primary filesystem. Can I use SELinux with my network filesystems? Yes, SELinux can mount network filesystems, such as NFS and CIFS filesystems, with an important caveat. All files in each filesystem will have the same SELinux type, since the filesystems do not support extended attributes. In the future, hopefully network filesystems will begin to support extended attributes, then they will work like a primary filesystem. I get a missing SELinux module error when using emerge:
This indicates that the portage SELinux module is missing or damaged. Also python may have been upgraded to a new version which requires python-selinux to be recompiled. Remerge dev-python/python-selinux. If packages have been merged under this condition, they must be relabed after fixing this condition. If the packages needing to be remerged cannot be determined, a full relabel may be required. 3.e. SELinux kernel error messages I get a register_security error message when booting:
This means that the Capability LSM module couldn't register as the primary module, since SELinux is the primary module. The third message means that it registers with SELinux as a secondary module. This is normal. When I try to relabel, it fails with invalid contexts:
First ensure that /selinux is mounted. If selinuxfs is not mounted, setfiles cannot validate any contexts, causing it to believe all contexts are invalid. If /selinux is mounted, then most likely there is new policy that has not yet been loaded; therefore, the contexts have not yet become valid. 4. SELinux Management Infrastructure4.a. SELinux Management Infrastructure The SElinux management infrastructure manages several aspects of SELinux policy. These management tools are based on the core library libsemanage. There are several management programs to to various tasks, including semanage and semodule. They allow you to configure aspects of the policy without requiring the policy sources. 4.b. SELinux Policy Module Management SELinux supports a modular policy. This means several pieces of policy are brought together to form one complete policy to be loaded in the kernel. This is a similar structure as the kernel itself and kernel modules. There is a main kernel image that is loaded, and various kernel modules can be added (assuming their dependencies are met) and removed on a running system without restarting. Similarly each policy has a base module and zero or more policy modules, all used to create a policy. Modules are built by compiling a piece of policy, and creating a policy package (*.pp) with that compiled policy, and optionally file contexts. The base module policy package (base.pp) contains the basic requirements of the policy. All modular policies must have a base module at minimum. In Gentoo we have these plus policies for all parts of the system profile. This is contained in the selinux-base-policy ebuild. The other policy ebuilds in portage have one or more policy modules. For more information on writing a policy module, in particular for managing your local customizations to the policy, please see the policy module guide. When a policy module is inserted or removed, modules are copied into or removed from the module store. This repository has a copy of the modules that were used to create the current policy, in addition to several auxilliary files. This repository is stored in the /etc/selinux/{strict,targeted}/modules. You should never need to directly access the contents of the module store. A libsemanage-based tool should be used instead. Libsemanage handles the module store transactionally. This means that if a set of operations (a transaction) is performed on the store and one part fails, the entire transaction is aborted. This keeps the store in a consistent state. Managing the module store is accomplished with the semodule command. Listing the contents of the module store is done with the -l option.
Since the base module is required in all cases, and is not versioned, it will not be shown in the list. All other modules will be listed, along with their versions. The module should be referenced by its file name.
This will insert the module into module store for the currently configured policy as specified in /etc/selinux/config. If the insert succeeds, the policy will be loaded, unless the -n option is used. To insert the module into an alternate module store, the -s option.
Since this refers to an alternate module store, the policy will not be loaded. The module is referenced by its name in the module store.
This will remove the module into module store for the currently configured policy as specified in /etc/selinux/config. If the remove succeeds, the policy will be loaded, unless the -n option is used. The remove command also respects the -s option. 4.c. Configuring User Login Mappings The current method of assigning sets of roles to a user is by setting up a mapping between linux users and SELinux identities. When a user logs in, the login program will set the SELinux identity based on the this map. If there is no explicit map, the __default__ map is used. Managing the SELinux user login map is accomplished with the semanage tool.
To map the linux user pebenito to the SELinux identity staff_u:
For descriptions on the available SELinux identities, see the SELinux Overview. To remove a login map for the linux user pebenito:
4.d. Configuring Initial Boolean States The setsebool program is now a libsemanage tool. This tool's basic function is to set the state of a Boolean. However, if the machine is restarted, the Booelans will be set using the initial state as specified in the policy. To set the Boolean state, and make that the new initial state in the policy, the -P option of setsebool is used.
This will set the fcron_crond Boolean to true and also make the initial state for the Boolean true. 4.e. Configuring SELinux Identities Generally SELinux identities need not be added to the policy, as user login mappings are sufficient. However, one reason to add them is for improved auditing, since the SELinux identity is part of the scontext of a denial message. Managing the SELinux identities is accomplished with the semanage tool.
In addition to specifying the roles for an identity, a prefix must also be specified. This prefix should match a role, for example staff or sysadm, and it is used for home directory entries. So if staff is used for the prefix, linux users that are mapped to this identity will have their home directory labeled staff_home_dir_t. To add the test_u identity with the roles staff_r and sysadm_r with the prefix staff:
Remove a SELinux user identity To remove the test_u SELinux identity:
5. Local Policy ModulesThis guide discusses how to set up a policy module for local additions of rules to the policy. Copy the example Makefile from the selinux-base-policy doc directory to the directory that will be used for building the policy. It is suggested that /root be used. The places that the semodule tool can read policy modules includes sysadm home directories.
In a policy module, most policy statements are usable in modules. There are a few extra statements that must be added for proper operation.
In addition to the basic allow rule, it has a couple statements required by policy modules. The first is a policy_module() macro that has the name of the module, and the module's version. It also has a require block. This block specifies all types that are required for this module to function. All types used in the module must either be declared in the module or required by this module. 5.d. Write a FC File (optional) The file contexts file is optional and has the same syntax as as always.
Types used in the file context file should be required or declared in the TE file. Simply run make to build all modules in the directory. The module will be compiled for the current policy as specified by /etc/selinux/config.
To build the module for a policy other than the configured policy, use the NAME= option.
The modules can be loaded into the currently configured policy simply by using the load target of the Makefile.
The load target also respects the NAME= option. Alternatively, the semodule command can be used to load individual modules.
5.g. Building Reference Policy Modules The new Gentoo policy is based on the SELinux Reference Policy. For more information on building a complete Reference Policy module, see the Reference Policy Wiki. 6. SELinux Reference Materials
D. Troubleshooting SELinux1. Policy Not Loaded on BootYou must be in sysadm_r to perform this action. A binary policy must be available in /etc/selinux/{strict,targeted}/policy. If it is missing, then install the policy.
1.b. Verify Init Can Load the Policy The final check is to ensure init can load the policy. Run ldd on init, and if libselinux is not in the output, remerge sysvinit.
Now reboot so init gains the correct context, and loads the policy. 2. Trouble Logging in LocallyYou must be in sysadm_r to perform these actions. Run sestatus -v. Click the first context that doesn't match:
There are several possible reasons why init may have the wrong context. First, verify that init is labeled correctly, refer to the sestatus's output for /sbin/init. If it is not system_u:object_r:init_exec_t, relabel sysvinit.
You must be in sysadm_r to perform this action. A binary policy must be available in /etc/selinux/{strict,targeted}/policy. If it is missing, then install the policy.
Verify Init Can Load the Policy The final check is to ensure init can load the policy. Run ldd on init, and if libselinux is not in the output, remerge sysvinit.
Now reboot so init gains the correct context, and loads the policy. Verify that agetty is labeled correctly. Refer to the sestatus's output for /sbin/agetty. If it is not system_u:object_r:getty_exec_t, relabel util-linux. Then restart all gettys.
All of the agettys should now be in the correct system_u:object_r:getty_exec_t context. Try logging in again. The login program (/bin/login) is not labeled correctly. Relabel shadow.
/bin/login should now be system_u:object_r:login_exec_t. Try logging in again. Sshd must be able to use PAM for authenticating the user. The PAM password checking program (/sbin/unix_chkpwd) must be labeled correctly so sshd can transition to the password checking context. Relabel PAM.
The password checking program should now be system_u:object_r:chkpwd_exec_t. Try loggin in again. 2.f. Incorrect Password File Contexts The password file (/etc/passwd), and the shadow file (/etc/shadow) must be labeled correctly, otherwise PAM will not be able to authenticate your user. Relabel the files.
The password and shadow files should now be system_u:object_r:etc_t and system_u:object_r:shadow_t, respectively. Try logging in again. 2.g. Incorrect Bash File Context Bash must be labeled correctly so the user can transition into the user domain when logging in. Relabel bash.
Bash (/bin/bash) should now be system_u:object_r:shell_exec_t. Try logging in again. 3. Trouble Logging in RemotelyYou must be in sysadm_r to perform these actions. Run sestatus -v. Click the first context that doesn't match:
There are several possible reasons why init may have the wrong context. First, verify that init is labeled correctly, refer to the sestatus's output for /sbin/init. If it is not system_u:object_r:init_exec_t, relabel sysvinit.
You must be in sysadm_r to perform this action. A binary policy must be available in /etc/selinux/{strict,targeted}/policy. If it is missing, then install the policy.
Verify Init Can Load the Policy The final check is to ensure init can load the policy. Run ldd on init, and if libselinux is not in the output, remerge sysvinit.
Now reboot so init gains the correct context, and loads the policy. Another possibility is sshd is not labeled correctly, meaning it is not running in the right context. Relabel openssh, then restart sshd.
Sshd must be able to use PAM for authenticating the user. The PAM password checking program (/sbin/unix_chkpwd) must be labeled correctly so sshd can transition to the password checking context. Relabel PAM.
The password checking program should now be system_u:object_r:chkpwd_exec_t. Try loggin in again. 3.e. Incorrect Password File Contexts The password file (/etc/passwd), and the shadow file (/etc/shadow) must be labeled correctly, otherwise PAM will not be able to authenticate your user. Relabel the files.
The password and shadow files should now be system_u:object_r:etc_t and system_u:object_r:shadow_t, respectively. Try logging in again. 3.f. Incorrect Bash File Context Bash must be labeled correctly so the user can transition into the user domain when logging in. Relabel bash.
Bash (/bin/bash) should now be system_u:object_r:shell_exec_t. Try logging in again. First, make sure the user has a valid shell.
If the above command does not return anything, or the shell is wrong, set the user's shell.
PAM also must be enabled in sshd. Make sure this line in /etc/ssh/sshd_config is uncommented:
SELinux currently only allows PAM and a select few programs direct access to /etc/shadow; therefore, openssh must now use PAM for password authentication (public key still works). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. |
|
