Red Hat Enterprise Linux Training - Notes
Notes from RHEL 7 Partner Training…
You can access Red Hat Support via the CLI tool redhat-support-tool The tool gives you access to the KB, which you can search from the CLI and you can work with support tickets.
Running sosreport will create an archive file with logs and other info that can be attached to a ticket.
redhat-support-tool has options for attaching files, it will look for an sosreport when you first open the ticket.
RHEL 7 has symbolic links for 4 folders in / to the same folder in /usr. They are:
/bin links to /usr/bin
/sbin links to /usr/sbin
/lib links to /usr/lib
/lib64 links to /usr/lib64
cp -r is required for copying folders;-r is for recursive.
mkdir -p creates parent directories as well.
rmdir for removing empty directories, but rm -rf for folders with contents.
Hard links are limited to being in the same file system; soft links/symbolic links can cross file systems.
New user accounts automatically have a Primary Group with the same name as the username. The Primary Group owns the files created by the user.
PolicyKit is similar to UAC in Windows. It is for GUI based apps and maintains its own configuration (independent of sudo) for what users/groups are permitted to elevate their privileges.
SU options:
add <code>-</code> to start with a clean environment
add <code>-c</code> to run a single command
Commands run via sudo are logged to /var/log/secure
userdel -r deletes the user from /etc/passwd and deletes their home directory.
Deleting a user frees up the UID, which could be re-assigned to a new user. Files owned by a UID that has been assigned to a new user keep their ownership, meaning they are now owned by a new user. This may have unintended consequences.
To find unowned files run this command as root: find / -nouser -o -nogroup 2> /dev/null
Passwords for users are stored in /etc/shadow They are stored salted and hashed. Hashing algorithm defaults to SHA-512 - this can be changed - via authconfig –passalgo - but it can only be lowered to MD5 or SHA-256, so probably not a good idea. (More bits == better!)
Passwords are processed by adding the salt to the user provided password and re-encrypted. If the value of this process matches the stored (hashed & salted) password, then the user has provided the correct password. Each user has a randomly generated salt. I assume this is picked at user creation time, but could be updated when the password is changed. Unique salts prevents identical values for hashed passwords.
Password aging and expiry is controlled with chage. Account locking is controlled with usermod -L
Users can be assigned the “nologin” shell. This will prevent shell connections, but still allows the user to have an account. Example provided includes a mail user, where access to email is controlled via local account, but the user does not access their email from a shell session. nologon shell is /sbin/nologin
sssd package provides LDAP client software dependencies. krb5-workstation package is useful for debuging kerberos issues and can work with kerberos tickets from the CLI.
IPA can be used to control sudo, ssh public keys, ssh host keys, server certs, automounter maps. IPA server provides LDAP and Kerberos. IPA can create and manage domains.
samba-winbind can be installed so the computer can join an AD Domain, authconfig can be used to configure winbind.
realmd package can be used to join an AD Domain and configure which users are allowed to login to the Red Hat computer.
Users need to login with their fully qualified name, eg: IPA = user1@ipa.example.com AD = DOMAIN\user1
Red Hat has an IPA guide here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html But from a quick scan I don’t know what IPA stands for.
File Permissions Changing Group ownership of a file or directory - use : before the group name. chown :newgroup dirname
Changing User and Group ownership of a file or directory - declare as user:group. chown newuser:newgroup dirname
Restrictions: Only root can the user that owns a file. root or the current owner can change the group that owns the file, but current (non-root) user can only change the group to one that the user is a member of.
chgrp can also be used to change group ownership; chgrp works like chown, including -R for recursive.
Special Permissions for Files setuid permissions allow a file to be executed as the user that owns the file, instead of the user that calls the file. setgid permissions allow a file to be executed as the group that owns the file. When looking the the file properties (ls -l) you will see a S or an s. The capital S means there are no execute permissions on the file, whereas the small s means that there are execute permissions.
setuid permissions can be set using chmod u+s filename or chmod 4700 filename and setgid permissions can be set using chmod g+s filename or chmod 2700 filename.
Special Permissions for Directories When the sticky bit is enabled on a directory, it restricts who can delete files. Only root, the owner of the file or the owner of the directory that the file is in can delete the file contents. sticky bit is displayed as a t at the end of the permissions for a directory. (ls -ld will show something like: drwxrwxrwt) The sticky bit is set via: chmod a+t directoryname or chmod 1777 directoryname
Shared folders can be configured with setgid so that the files created in these folders inherit the group owner value that is assigned to the directory, instead of the defualt behaviour, which is to have the primary group of the user that creates the file. chmod g+s directoryname Directory permissions will show an S or an s where the x should be. Capital S for no execute bit on the folder.
SELinux
SELinux adds an additional layer of object-oriented security to Linux. Provides sophisticated security rules for defining access.
To check SELinux mode run getenforce To check for SELinux contexts on files/folders use ls -Z To display SELinux booleans run getsebool -a
Modes are to determine how rules are enacted - Enforcing, Permissive, Disabled. Changing between Enforcing and Permissive does not require a reboot. Changing to Disabled does require a reboot - using Permissive instead of Disabled is recommended.
Process Management
Processes can be managed for the current user or another user with Signals. Signals tell the process what action to take - Stop, Terminate, Kill, Core Dump, Resume… Signals can be initiated with keyboard shortcuts or by calling the short name for the signal. Users can Kill processes they own, but root is required to kill processes owned by other users.
Suspend (STOP) is initiated with Crtl-Z Kill is intiated with Crtl-C Core Dump is initiated with Crtl-</code>
Use kill command to send any signal Use killall to kill processes in groups, either by matching name, owned by user or all system processes. Use pkill to kill processes with even more granular control.
Use terminate option first, since it allows for clean up. Kill is final and doesn’t allow for clean up, should only be used if the process does not respond.