Why are file permission changes an indication of a possible security breach?

Managing Change

Verifying file permissions is an excellent first step in locking down the file system. However, this must be scheduled along with checking for new files, removing old ones, and verifying that existing ones have not changed. As you might imagine, in an active database system, many files are going to be added, removed, and changed on a regular basis. When creating your lockdown procedures for your file system, include not just a list of files and their permissions, but also a method that dynamically updates that list and a method to ensure that static components have not been modified. When you find new files or discover missing ones, verify that this is okay. For example, new datafiles and redo files may appear, or backups may have been copied to tape and then removed from disk.

Software and configuration files should change only when authorized, so this should be a relatively infrequent occurrence. A cryptographic hash is a large, unique number that acts as a fingerprint for a file. Calculate cryptographic hashes of these files during your first pass of locking down your database and then the next time you review your system, you can calculate them again to determine if anything has changed. Message Digest 5 (MD5) and Secure Hashing Algorithm 1 (SHA-1) are common hash algorithms, but in recent years flaws were found in both. SHA-256 and RI PEMD-160 are better options. Be sure to store your hashes offline in case the host is compromised.

It is important to assess file permissions on a regular basis to ensure they remain at their proper settings. This is especially true after an upgrade or even after applying a Critical Patch Update (CPU). These can alter your Oracle installation in any number of ways. It is possible for someone (e.g., an operating system administrator or a database administrator) to change permissions to be more permissive accidentally … or intentionally. In the section of your lockdown plan that deals with security tasks to be performed on a schedule, include these details.

UMASK

umask sets the default file permissions that a file gets when it is first created and uses a list of octal values to indicate what rights to remove. A typical umask is 0022, with the two's meaning new files will have the write privilege removed for members of group and other. You can view your umask by simply typing umask or change it by using umask newmask.

You can also use umask with the same letter syntax as chmod, by using the -S parameter which tells the system which bits to set, as opposed to which bits not to set for the number representation. To make a change permanent, you can add the command to your shell startup script, so it gets run every time you start a shell.

Windows Access Tokens

Runtime privileges, like file permissions, are more complicated on Windows. Every running process on a Windows system contains an access token. Access tokens provide information about the identity and privileges associated with a user account. Windows runtime security involves many elements such as SIDs, security descriptors (ACLs), security principles, and generic access permissions. All of these are managed using access tokens.

Upon login or authentication, a primary access token is created. This access token includes the user's SID, the group SIDs for all groups that the user is a member of, default access control information, impersonation level (explained later in this chapter), and other privilege specifications. After authentication, any process launched on behalf of the user maintains a copy of this access token. Modifications to user accounts on Windows or any of the groups or privileges associated with the user do not take effect until the next time that user authenticates.

Whenever a process requests access to the system or attempts to perform a privileged operation, the system consults that process's access token to determine if the operation should or should not be allowed. In the same way that UNIX and Linux systems have effective and real UID values, Windows processes and threads have a similar concept with access tokens. In the Windows world, there are primary access tokens and impersonation access tokens. The primary access token is associated with the user who is responsible for the process, or thread, whereas the impersonation access token is a deviation from the primary token, though not quite the same in purpose as the effective UID on UNIX.

The main goal of impersonation access tokens is to allow services to assume a user's privileges when providing access to a resource; these are usually client/server interactions. When a request is made of a service, the client provides an impersonation level that designates to what degree the service can impersonate the client. The service then assumes the identity of the client for the duration of the request by using an impersonation access token.

POSIX (UNIX/Linux Systems) Access Control

UNIX-based systems such as Linux used POSIX-style access control lists. This means files have three permission modes: read (r), write (w), and execute (x). These modes can be assigned either using the letters just listed or they also have equivalent numbers. Read is 4, write is 2, and execute is 1. If file permissions are being set using letters, it will be a string of letters or dashes (e.g. a file with read-only permission would show r– and a file with read, write, and execute would show rwx). When using numbers, they are added to denote permissions. Read permission would simply be a 4, and read and write permission would be 6 (4 plus 2). When using POSIX-style access controls, there are three groups or users you set permissions for. The first set is for that specific user who owns the file. The second set is for the group who owns the file. The third is for all other users who do not have any ownership over the file, similar to the Everybody group in Windows. So, a file that allows the owner to read and write, and everyone else only read access would look like this –rw–r–r– or in numeric format it would be 644.

Linux has great command-line tools for changing file permissions and file ownership. Although exploring all that these commands can do is beyond the scope of this book, we will discuss some basics here. In Linux, to list file permissions, the ls command can be used. The syntax to list the file permission and the group and user who own the file is as follows:

ls–lg [filename]

To change file permissions in Linux, you usually use the chmod command. You can run the chmod command using numbers. The following example uses POSIX permission number format to set a file to allow the user who owns it to read, write, and execute the file, and everyone else to read and execute but not write to it, similar to a standard executable file:

chmod 755 filename

Or you could use letters and specify if you are going to add them or delete them from users (u), groups (g), others (o), or all (a). For example, to allow the user who owns the file to read from it and write to it, you would do the following:

chmod u = rw filename

To take away permissions use a—in front of the permissions parameter. To deny read, write, and execute permission to the group that owns the file and to all users other than the one that owns the file, you would do the following:

chmod go-rwx filename

To change the file ownership, use the chown command. To change the user and group that owns a file, do the following:

chown newuser:newgroup filename

In POSIX-style systems, there are three additional attributes that affect how files are executed are accessed. These are set user ID (SUID), the set group ID (SGID), and sticky. These settings work differently when they’re applied to files or directories. The SUID bit can be configured to tell the file what user it should run under when the file is executed. Many times this is used to allow a nonroot user to run a file as the root user. This is used if a user needs to run a file that requires root access, and you don’t want to give their account root access or the root password. SGID for a file works the same way as SUID, but it specifies what group the file should execute as. The sticky has no effect on individual files. The SUID bit has no effect on directories. If the SGID bit is set on a directory, any new files created in that directory will be owned by the group specified using the SGID instead of the group of the user who created the file. This is sometimes used in directories where many users will share files. When the sticky bit is set on a directory, only the user owner of the file or root can delete or rename a file (the group owner cannot). This is sometimes used in shared directories where you don’t want users other than the owner or root to delete or rename a file.

In Linux, there are also several mandatory access control systems. Most of them are somewhat limited to protecting only a subset of files on the system (normally only critical system files). SE Linux is an example of this. SE Linux was developed by the National Security Agency (NSA) and has been incorporated into the 2.6 series Linux kernel. SE Linux uses targets to specify what files it will control and how it will control them. Other mandatory access control systems that are currently being used in Linux include Suse’s AppArmor, Rule Set Based Access Control (RSBAC).

Discretionary Access Control

Discretionary access control (DAC), also known as file permissions, is the access control in Unix and Linux systems. Whenever you have seen the syntax drwxr-xs-x, it is the ugo abbreviation for owner, group, and other permissions in the directory listing. Ugo is the abbreviation for user access, group access, and other system user’s access, respectively. These file permissions are set to allow or deny access to members of their own group, or any other groups. Modification of file, directory, and devices are achieved using the chmod command. Tables 11.1 and 11.2 illustrate the syntax to assign or remove permissions. Permissions can be assigned using the character format:

Table 11.1. Notation to Add, Remove Access, and how to Explicitly Assign Access.

+add access−remove access=access explicitly assigned

Table 11.2. Notation for File Permissions.

rPermission to read filePermission to read a directory (also requires ‘x’)wPermission to delete or modify a filePermission to delete or modify files in a directoryxPermission to execute a file/scriptPermission to read a directory (also requires ‘r’)sSet user or group ID on executionuPermissions granted to the user who owns the filetSet sticky bit. Execute file/script as a user root for regular user

Chmod [ugoa] [+−=] [rwxXst] fileORdirectoryName

In DAC, usually the resource owner will control who access resources. Everyone has administered a system in which they decide to give full rights to everyone so that it is less to manage. The issue with this approach is that users are allowed not only to read, write, and execute files, but also to delete any files they have access to. This author has so often seen system files deleted in error by users, or simply by the user’s lack of knowledge. This is an instance where DAC could be seen as a disadvantage, or less advantageous.

Users and File Permissions

File permissions, such as read, write, and execute, control access to files. The types of permissions available depend on the file system being used.

Linux and UNIX permissions

Most Linux and UNIX file systems support the following file permissions:

•

Read (“r”)

•

Write (“w”)

•

Execute (“x”)

Each of those permissions may be set separately to the owner, group, or world. Figure 4.11 shows the output of a Linux “ls –la /etc” (list all files in the /etc directory, long output) command.

Figure 4.11. Linux “ls -la” Command

The output in Figure 4.11 shows permissions, owner, group, size, date, and filename. Permissions beginning with “d” (such as “acpi”) are directories. Permissions beginning with “-” (such as at.deny) describe files. Figure 4.12 zooms in on files in /etc. highlighting the owner, group, and world permissions.

Figure 4.12. Linux /etc Permissions, Highlighting Owner, Group and World

The adduser.conf file in Figure 4.12 is owned by root and has “-rw-r--r--” permissions. This means adduser.conf is a file (permissions begin with “-”), has read and write (rw-) permissions for the owner (root), read (r--) for the group (also root), and read permissions (r--) for the world.

Microsoft NTFS Permissions

Microsoft NTFS (New Technology File System) has the following basic file permissions:

•

Read

•

Write

•

Read and execute

•

Modify

•

Full control (read, write, execute, modify, and in addition the ability to change the permissions.)

NTFS has more types of permissions than most UNIX or Linux file systems. The NTFS file is controlled by the owner, who may grant permissions to other users. Figure 4.13 shows the permissions of a sample photo at C:\Users\Public\Pictures\Sample Pictures\Penguins.jpg.

Figure 4.13. NTFS Permissions

To see these permissions, right-click an NTFS file, choose “properties,” and then “security.”

Privileged Programs

On UNIX and Linux systems, a regular user cannot edit the password file (/etc/passwd) and shadow file (/etc/shadow), which store account information and encrypted passwords, respectively. But users need to be able to change their passwords (and thus those files). How can they change their passwords if they cannot (directly) change those files?

The answer is setuid (set user ID) programs. Setuid is a Linux and UNIX file permission that makes an executable run with the permissions of the file’s owner, and not as the running user. Setgid (set group ID) programs run with the permissions of the file’s group.

Figure 4.14 shows the permissions of the Linux command /usr/bin/passwd, used to set and change passwords. It is setuid root (the file is owned by the root user, and the owner’s execute bit is set to “s,” for setuid), meaning it runs with root (super user) permissions, regardless of the running user.

Figure 4.14. Linux Setuid Root Program /usr/bin/passwd

The “passwd” program runs as root, allowing any user to change their password, and thus the contents of /etc/passwd and /etc/shadow. Setuid programs must be carefully scrutinized for security holes: attackers may attempt to trick the passwd command to alter other files. The integrity of all setuid and setgid programs on a system should be closely monitored.

8.4.1 Change File Permission: chmod

In OpenVMS, one has file protections, but in UNIX one has file permissions. No matter the name, they serve the same purpose. The UNIX command chmod, like the OpenVMS SET PROTECTION command, changes the permissions assigned to a file or directory. The command chmod provides two methods for specifying a change in file permission, as shown in the following examples.

OpenVMSUNIXForm:$ SET PROTECTION = -% chmod v file(s)( CLASSIFICATION-. LEVEL) file-spec[, . . . ]Example:$ SET PROTECT=(O:RWED,G:RE,W:RE) A.DAT% chmod 755 a.dat% chmod + x a.datExample:$ SET PR0TECT=(O:RWED,G,W) A.DAT% chmod g-w, o-w a.dat% chmod u=rwx, g =, o = a.dat

The first example illustrates the absolute form for specifying a file’s permissions. A level of protection is specified using an octal representation for each of the three types of user—owner, group, and world (in that order): where

What is the first step of Comptia's 7 step best practice for malware removal?

What is the problem with unintended Wi

What can give away too much sensitive information to third parties?

Which of the following should be the first step of the malware removal procedure?