System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:
/lib /lib64 /usr/lib /usr/lib64Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be group-owned by the root user. If the directories, is found to be owned by a user other than root correct its ownership with the following command:
$ sudo chgrp root DIR
Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership of library directories is necessary to protect the integrity of the system.
System commands files are stored in the following directories by default:
/bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbinAll these directories should be owned by the root group. If the directory is found to be owned by a group other than root correct its ownership with the following command:
$ sudo chgrp root DIR
If the operating system allows any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.
/bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbinAll these directories should be owned by the root user. If any directory DIR in these directories is found to be owned by a user other than root, correct its ownership with the following command:
$ sudo chown root DIR
System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted.
System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:
/lib /lib64 /usr/lib /usr/lib64Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be owned by the root user. If the directories, is found to be owned by a user other than root correct its ownership with the following command:
$ sudo chown root DIR
Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership of library directories is necessary to protect the integrity of the system.
System executables are stored in the following directories by default:
/bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbinThese directories should not be group-writable or world-writable. If any directory DIR in these directories is found to be group-writable or world-writable, correct its permission with the following command:
$ sudo chmod go-w DIR
System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted.
System-wide shared library directories, which contain are linked to executables during process load time or run time, are stored in the following directories by default:
/lib /lib64 /usr/lib /usr/lib64Kernel modules, which can be added to the kernel during runtime, are stored in /lib/modules. All sub-directories in these directories should not be group-writable or world-writable. If any file in these directories is found to be group-writable or world-writable, correct its permission with the following command:
$ sudo chmod go-w DIR
If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.
All directories in local partitions which are world-writable should be owned by root. If any world-writable directories are not owned by root, this should be investigated. Following this, the files should be deleted or assigned to root user.
Allowing a user account to own a world-writable directory is undesirable because it allows the owner of that directory to remove or replace any files that may be placed in the directory by other users.
When the so-called 'sticky bit' is set on a directory, only the owner of a given file may
remove that file from the directory. Without the sticky bit, any user with write access to a
directory may remove any file in the directory. Setting the sticky bit prevents users from
removing each other's files. In cases where there is no reason for a directory to be
world-writable, a better solution is to remove that permission rather than to set the sticky
bit. However, if a directory is used by a particular application, consult that application's
documentation instead of blindly changing modes.
To set the sticky bit on a world-writable directory DIR, run the following command:
$ sudo chmod +t DIR
Failing to set the sticky bit on public directories allows unauthorized users to delete files
in the directory structure.
The only authorized public directories are those temporary directories supplied with the
system, or those designed to be temporary file repositories. The setting is normally reserved
for directories used by the system, by users for temporary file storage (such as /tmp),
and for directories requiring global read/write access.
All directories in local partitions which are world-writable should be owned by root or another system account. If any world-writable directories are not owned by a system account, this should be investigated. Following this, the files should be deleted or assigned to an appropriate owner.
Allowing a user account to own a world-writable directory is undesirable because it allows the owner of that directory to remove or replace any files that may be placed in the directory by other users.
All directories in local partitions which are world-writable should be group owned by root or another system account. If any world-writable directories are not group owned by a system account, this should be investigated. Following this, the files should be deleted or assigned to an appropriate group.
Allowing a user account to group own a world-writable directory is undesirable because it allows the owner of that directory to remove or replace any files that may be placed in the directory by other users.
System commands are stored in the following directories: by default:
/bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbinAll these directories should have root user as a group owner. If any system command directory is not group owned by a user other than root correct its ownership with the following command:
$ sudo chgrp root DIR
If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.
System commands are stored in the following directories by default:
/bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbinAll these directories should be owned by the root user. If any system command directory is not owned by a user other than root correct its ownership with the following command:
$ sudo chown root DIR
If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.
To properly set the group owner of /etc/sysctl.d, run the command:
$ sudo chgrp root /etc/sysctl.d
The ownership of the /etc/sysctl.d directory by the root group is important because this directory hosts kernel configuration. Protection of this directory is critical for system security. Assigning the ownership to root ensures exclusive control of the kernel configuration.
To properly set the owner of /etc/sysctl.d, run the command:
$ sudo chown root /etc/sysctl.d
The ownership of the /etc/sysctl.d directory by the root user is important because this directory hosts kernel configuration. Protection of this directory is critical for system security. Assigning the ownership to root ensures exclusive control of the kernel configuration.
To properly set the permissions of /etc/sysctl.d, run the command:
$ sudo chmod 0755 /etc/sysctl.d
Setting correct permissions on the /etc/sysctl.d directory is important because this directory hosts kernel configuration. Protection of this directory is critical for system security. Restricting the permissions ensures exclusive control of the kernel configuration.
To properly set the owner of /etc/security/opasswd, run the command:
$ sudo chown root /etc/security/opasswdTo properly set the group owner of
/etc/security/opasswd, run the command: $ sudo chgrp root /etc/security/opasswdTo properly set the permissions of
/etc/security/opasswd, run the command: $ sudo chmod 0600 /etc/security/opasswd
The /etc/security/opasswd file stores old passwords to prevent password reuse. Protection of this file is critical for system security.
To properly set the group owner of /etc/group-, run the command:
$ sudo chgrp root /etc/group-
The /etc/group- file is a backup file of /etc/group, and as such, it contains information regarding groups that are configured on the system. Protection of this file is important for system security.
To properly set the group owner of /etc/gshadow-, run the command:
$ sudo chgrp root /etc/gshadow-
The /etc/gshadow- file is a backup of /etc/gshadow, and as such, it contains group password hashes. Protection of this file is critical for system security.
To properly set the group owner of /etc/passwd-, run the command:
$ sudo chgrp root /etc/passwd-
The /etc/passwd- file is a backup file of /etc/passwd, and as such, it contains information about the users that are configured on the system. Protection of this file is critical for system security.
To properly set the group owner of /etc/shadow-, run the command:
$ sudo chgrp root /etc/shadow-
The /etc/shadow- file is a backup file of /etc/shadow, and as such, it contains the list of local system accounts and password hashes. Protection of this file is critical for system security.
To properly set the group owner of /etc/crypttab, run the command:
$ sudo chgrp root /etc/crypttab
The ownership of the /etc/crypttab file by the root group is important because this file hosts encrypted block devices configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the encrypted block devices configuration.
To properly set the group owner of /etc/group, run the command:
$ sudo chgrp root /etc/group
The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security.
To properly set the group owner of /etc/gshadow, run the command:
$ sudo chgrp root /etc/gshadow
The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security.
To properly set the group owner of /etc/passwd, run the command:
$ sudo chgrp root /etc/passwd
The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security.
To properly set the group owner of /etc/shadow, run the command:
$ sudo chgrp root /etc/shadow
The /etc/shadow file stores password hashes. Protection of this file is critical for system security.
To properly set the group owner of /etc/shells, run the command:
$ sudo chgrp root /etc/shells
The /etc/shells file contains the list of full pathnames to shells on the system. Since this file is used by many system programs this file should be protected.
The System.map files are symbol map files generated during the compilation of the Linux
kernel. They contain the mapping between kernel symbols and their corresponding memory
addresses. These files must be group-owned by root.
To properly set the group owner of /boot/System.map*, run the command:
$ sudo chgrp root /boot/System.map*
The purpose of System.map files is primarily for debugging and profiling the kernel. Unrestricted access to these files might disclose information useful to attackers and malicious software leading to more sophisticated exploitation.
To properly set the group owner of /var/log, run the command:
$ sudo chgrp root /var/log
The /var/log directory contains files with logs of error messages in the system and should only be accessed by authorized personnel.
To properly set the group owner of /var/log/messages, run the command:
$ sudo chgrp root /var/log/messages
The /var/log/messages file contains logs of error messages in the system and should only be accessed by authorized personnel.
To properly set the group owner of /var/log/syslog, run the command:
$ sudo chgrp adm /var/log/syslog
The /var/log/syslog file contains logs of error messages in the system and should only be accessed by authorized personnel.
The Amazon Linux 2023 operating system audit tools must have the proper ownership configured to protected against unauthorized access. Verify it by running the following command:
$ stat -c "%n %G" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules /sbin/auditctl root /sbin/aureport root /sbin/ausearch root /sbin/autrace root /sbin/auditd root /sbin/audispd root /sbin/augenrules rootAudit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators
Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys to make access decisions regarding the access to audit tools.
System commands files are stored in the following directories by default:
/bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbinAll files in these directories should be owned by the root group, or a system account. If the directory, or any file in these directories, is found to be owned by a group other than root or a a system account correct its ownership with the following command:
$ sudo chgrp root FILE
If the operating system allows any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.
To properly set the owner of /etc/group-, run the command:
$ sudo chown root /etc/group-
The /etc/group- file is a backup file of /etc/group, and as such, it contains information regarding groups that are configured on the system. Protection of this file is important for system security.
To properly set the owner of /etc/gshadow-, run the command:
$ sudo chown root /etc/gshadow-
The /etc/gshadow- file is a backup of /etc/gshadow, and as such, it contains group password hashes. Protection of this file is critical for system security.
To properly set the owner of /etc/passwd-, run the command:
$ sudo chown root /etc/passwd-
The /etc/passwd- file is a backup file of /etc/passwd, and as such, it contains information about the users that are configured on the system. Protection of this file is critical for system security.
To properly set the owner of /etc/shadow-, run the command:
$ sudo chown root /etc/shadow-
The /etc/shadow- file is a backup file of /etc/shadow, and as such, it contains the list of local system accounts and password hashes. Protection of this file is critical for system security.
To properly set the owner of /etc/crypttab, run the command:
$ sudo chown root /etc/crypttab
The ownership of the /etc/crypttab file by the root user is important because this file hosts encrypted block devices configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the encrypted block devices configuration.
To properly set the owner of /etc/group, run the command:
$ sudo chown root /etc/group
The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security.
To properly set the owner of /etc/gshadow, run the command:
$ sudo chown root /etc/gshadow
The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security.
To properly set the owner of /etc/passwd, run the command:
$ sudo chown root /etc/passwd
The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security.
To properly set the owner of /etc/shells, run the command:
$ sudo chown root /etc/shells
The /etc/shells file contains the list of full pathnames to shells on the system. Since this file is used by many system programs this file should be protected.
To properly set the owner of /etc/shadow, run the command:
$ sudo chown root /etc/shadow
The /etc/shadow file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.
The System.map files are symbol map files generated during the compilation of the Linux
kernel. They contain the mapping between kernel symbols and their corresponding memory
addresses. These files must be owned by root.
To properly set the owner of /boot/System.map*, run the command:
$ sudo chown root /boot/System.map*
The purpose of System.map files is primarily for debugging and profiling the kernel. Unrestricted access to these files might disclose information useful to attackers and malicious software leading to more sophisticated exploitation.
To properly set the owner of /var/log, run the command:
$ sudo chown root /var/log
The /var/log directory contains files with logs of error messages in the system and should only be accessed by authorized personnel.
To properly set the owner of /var/log/messages, run the command:
$ sudo chown root /var/log/messages
The /var/log/messages file contains logs of error messages in the system and should only be accessed by authorized personnel.
To properly set the owner of /var/log/syslog, run the command:
$ sudo chown syslog /var/log/syslog
The /var/log/syslog file contains logs of error messages in the system and should only be accessed by authorized personnel.
The Amazon Linux 2023 operating system audit tools must have the proper ownership configured to protected against unauthorized access. Verify it by running the following command:
$ stat -c "%n %U" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules /sbin/auditctl root /sbin/aureport root /sbin/ausearch root /sbin/autrace root /sbin/auditd root /sbin/audispd root /sbin/augenrules rootAudit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators
Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys to make access decisions regarding the access to audit tools.
System executables are stored in the following directories by default:
/bin /sbin /usr/bin /usr/libexec /usr/local/bin /usr/local/sbin /usr/sbinAll files in these directories should be owned by the root user. If any file FILE in these directories is found to be owned by a user other than root, correct its ownership with the following command:
$ sudo chown root FILE
System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted.
System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:
/lib /lib64 /usr/lib /usr/lib64Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be owned by the root user. If the directory, or any file in these directories, is found to be owned by a user other than root correct its ownership with the following command:
$ sudo chown root FILE
Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership is necessary to protect the integrity of the system.
The Amazon Linux 2023 operating system audit tools must have the proper permissions configured to protected against unauthorized access. Verify it by running the following command:
$ stat -c "%n %a" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules /sbin/auditctl 755 /sbin/aureport 755 /sbin/ausearch 755 /sbin/autrace 755 /sbin/auditd 755 /sbin/audispd 755 /sbin/augenrules 755Audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators
Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys to make access decisions regarding the access to audit tools.
To properly set the permissions of /etc/group-, run the command:
$ sudo chmod 0644 /etc/group-
The /etc/group- file is a backup file of /etc/group, and as such, it contains information regarding groups that are configured on the system. Protection of this file is important for system security.
To properly set the permissions of /etc/gshadow-, run the command:
$ sudo chmod 0000 /etc/gshadow-
The /etc/gshadow- file is a backup of /etc/gshadow, and as such, it contains group password hashes. Protection of this file is critical for system security.
To properly set the permissions of /etc/passwd-, run the command:
$ sudo chmod 0644 /etc/passwd-
The /etc/passwd- file is a backup file of /etc/passwd, and as such, it contains information about the users that are configured on the system. Protection of this file is critical for system security.
To properly set the permissions of /etc/shadow-, run the command:
$ sudo chmod 0000 /etc/shadow-
The /etc/shadow- file is a backup file of /etc/shadow, and as such, it contains the list of local system accounts and password hashes. Protection of this file is critical for system security.
System executables are stored in the following directories by default:
/bin /sbin /usr/bin /usr/libexec /usr/local/bin /usr/local/sbin /usr/sbinAll files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command:
$ sudo chmod go-w FILE
System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted.
To properly set the permissions of /etc/audit/auditd.conf, run the command:
$ sudo chmod 0640 /etc/audit/auditd.conf
Without the capability to restrict the roles and individuals that can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
To properly set the permissions of /etc/audit/rules.d/*.rules, run the command:
$ sudo chmod 0640 /etc/audit/rules.d/*.rules
Without the capability to restrict the roles and individuals that can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
To properly set the permissions of /etc/audit/audit.rules, run the command:
$ sudo chmod 0640 /etc/audit/audit.rules
Without the capability to restrict the roles and individuals that can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
To properly set the permissions of /etc/crypttab, run the command:
$ sudo chmod 0600 /etc/crypttab
Setting correct permissions on the /etc/crypttab file is important because this file hosts encrypted block devices configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the encrypted block devices configuration.
To properly set the permissions of /etc/group, run the command:
$ sudo chmod 0644 /etc/group
The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security.
To properly set the permissions of /etc/gshadow, run the command:
$ sudo chmod 0000 /etc/gshadow
The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security.
To properly set the permissions of /etc/passwd, run the command:
$ sudo chmod 0644 /etc/passwd
If the /etc/passwd file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the list of accounts on the system and associated information, and protection of this file is critical for system security.
To properly set the permissions of /etc/shadow, run the command:
$ sudo chmod 0000 /etc/shadow
The /etc/shadow file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.
To properly set the permissions of /etc/shells, run the command:
$ sudo chmod 0644 /etc/shells
The /etc/shells file contains the list of full pathnames to shells on the system. Since this file is used by many system programs this file should be protected.
System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:
/lib /lib64 /usr/lib /usr/lib64Kernel modules, which can be added to the kernel during runtime, are stored in /lib/modules. All files in these directories should not be group-writable or world-writable. If any file in these directories is found to be group-writable or world-writable, correct its permission with the following command:
$ sudo chmod go-w FILE
Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Restrictive permissions are necessary to protect the integrity of the system.
Files containing sensitive informations should be protected by restrictive
permissions. Most of the time, there is no need that these files need to be read by any non-root user
To properly set the permissions of /var/log/messages, run the command:
$ sudo chmod 0640 /var/log/messagesCheck that "permissions.local" file contains the correct permissions rules with the following command:
# grep -i messages /etc/permissions.local /var/log/messages root:root 640
The /var/log/messages file contains system error messages. Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the SUSE operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.
System commands are stored in the following directories by default:
/bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbinAll files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command:
$ sudo chmod 755 FILE
System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted.
The System.map files are symbol map files generated during the compilation of the Linux
kernel. They contain the mapping between kernel symbols and their corresponding memory
addresses. In general, there is no need for non-root users to read these files.
To properly set the permissions of /boot/System.map*, run the command:
$ sudo chmod 0600 /boot/System.map*
The purpose of System.map files is primarily for debugging and profiling the kernel. Unrestricted access to these files might disclose information useful to attackers and malicious software leading to more sophisticated exploitation.
If any file is not group-owned by a group present in /etc/group, the cause of the lack of group-ownership must be investigated. Following this, those files should be deleted or assigned to an appropriate group. Locate the mount points related to local devices by the following command:
$ findmnt -n -l -k -it $(awk '/nodev/ { print $2 }' /proc/filesystems | paste -sd,)
For all mount points listed by the previous command, it is necessary to search for files which
do not belong to a valid group using the following command:
$ sudo find MOUNTPOINT -xdev -nogroup 2>/dev/null
Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account, or other similar cases. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed.
To properly set the permissions of /var/log, run the command:
$ sudo chmod 0755 /var/log
The /var/log directory contains files with logs of error messages in the system and should only be accessed by authorized personnel.
To properly set the permissions of /var/log/messages, run the command:
$ sudo chmod 0640 /var/log/messages
The /var/log/messages file contains logs of error messages in the system and should only be accessed by authorized personnel.
To properly set the permissions of /var/log/syslog, run the command:
$ sudo chmod 0640 /var/log/syslog
The /var/log/syslog file contains logs of error messages in the system and should only be accessed by authorized personnel.
The nosuid mount option can be used to prevent
execution of setuid programs in /boot/efi. The SUID and SGID permissions
should not be required on the boot partition.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/boot/efi.
The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from boot partitions.
The noauto mount option is used to prevent automatic mounting of th
/boot partition.
Add the noauto option to the fourth column of
/etc/fstab for the line which controls mounting of
/boot.
The /boot partition contains the kernel and the bootloader. Access to the partition after the boot process finishes should not be needed. Files contained within this partition can be analysed and gained information can be used for exploit creation.
The nodev mount option can be used to prevent device files from
being created in /boot.
Legitimate character and block devices should exist only in
the /dev directory on the root partition or within chroot
jails built for system services.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/boot.
The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails.
The noexec mount option can be used to prevent binaries from being
executed out of /boot.
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/boot.
The /boot partition contains the kernel and the bootloader. No binaries should be executed from this partition after the booting process finishes.
The nosuid mount option can be used to prevent
execution of setuid programs in /boot. The SUID and SGID permissions
should not be required on the boot partition.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/boot.
The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from boot partitions.
The nodev mount option can be used to prevent creation of device
files in /dev/shm. Legitimate character and block devices should
not exist within temporary directories like /dev/shm.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/dev/shm.
The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails.
The noexec mount option can be used to prevent binaries
from being executed out of /dev/shm.
It can be dangerous to allow the execution of binaries
from world-writable temporary storage directories such as /dev/shm.
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/dev/shm.
Allowing users to execute binaries from world-writable directories such as /dev/shm can expose the system to potential compromise.
The nosuid mount option can be used to prevent execution
of setuid programs in /dev/shm. The SUID and SGID permissions should not
be required in these world-writable directories.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/dev/shm.
The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from temporary storage partitions.
The grpquota mount option allows for the filesystem to have disk quotas configured.
Add the grpquota option to the fourth column of
/etc/fstab for the line which controls mounting of
/home.
To ensure the availability of disk space on /home, it is important to limit the impact a single user or group can cause for other users (or the wider system) by intentionally or accidentally filling up the partition. Quotas can also be applied to inodes for filesystems where inode exhaustion is a concern.
The nodev mount option can be used to prevent device files from
being created in /home.
Legitimate character and block devices should exist only in
the /dev directory on the root partition or within chroot
jails built for system services.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/home.
The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails.
The noexec mount option can be used to prevent binaries from being
executed out of /home.
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/home.
The /home directory contains data of individual users. Binaries in this directory should not be considered as trusted and users should not be able to execute them.
The nosuid mount option can be used to prevent
execution of setuid programs in /home. The SUID and SGID permissions
should not be required in these user data directories.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/home.
The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from user home directory partitions.
The usrquota mount option allows for the filesystem to have disk quotas configured.
Add the usrquota option to the fourth column of
/etc/fstab for the line which controls mounting of
/home.
To ensure the availability of disk space on /home, it is important to limit the impact a single user or group can cause for other users (or the wider system) by intentionally or accidentally filling up the partition. Quotas can also be applied to inodes for filesystems where inode exhaustion is a concern.
Add the sec=krb5:krb5i:krb5p option to the fourth column of /etc/fstab for the line which controls mounting of
any NFS mounts.
When an NFS server is configured to use AUTH_SYS a selected userid and groupid are used to handle requests from the remote user. The userid and groupid could mistakenly or maliciously be set incorrectly. The AUTH_GSS method of authentication uses certificates on the server and client systems to more securely authenticate the remote mount request.
The nodev mount option prevents files from being interpreted as
character or block devices. Legitimate character and block devices should
exist only in the /dev directory on the root partition or within
chroot jails built for system services.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
any non-root local partitions.
The nodev mount option prevents files from being interpreted as character or block devices. The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails, for which it is not advised to set nodev on these filesystems.
Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of
any NFS mounts.
Legitimate device files should only exist in the /dev directory. NFS mounts should not present device files to users.
The nodev mount option prevents files from being
interpreted as character or block devices.
Legitimate character and block devices should exist only in
the /dev directory on the root partition or within chroot
jails built for system services.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
any removable media partitions.
The only legitimate location for device files is the /dev directory located on the root partition. An exception to this is chroot jails, and it is not advised to set nodev on partitions which contain their root filesystems.
Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of
any NFS mounts.
The noexec mount option causes the system not to execute binary files. This option must be used for mounting any file system not containing approved binary files as they may be incompatible. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.
The noexec mount option prevents the direct execution of binaries
on the mounted filesystem. Preventing the direct execution of binaries from
removable media (such as a USB key) provides a defense against malicious
software that may be present on such untrusted media.
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
any removable media partitions.
Allowing users to execute binaries from removable media such as USB keys exposes the system to potential compromise.
Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of
any NFS mounts.
NFS mounts should not present suid binaries to users. Only vendor-supplied suid executables should be installed to their default location on the local filesystem.
The nosuid mount option prevents set-user-identifier (SUID)
and set-group-identifier (SGID) permissions from taking effect. These permissions
allow users to execute binaries with the same permissions as the owner and group
of the file respectively. Users should not be allowed to introduce SUID and SGID
files into the system via partitions mounted from removeable media.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
any removable media partitions.
The presence of SUID and SGID executables should be tightly controlled. Allowing users to introduce SUID or SGID binaries from partitions mounted off of removable media would allow them to introduce their own highly-privileged programs.
The nosuid mount option can be used to prevent
execution of setuid programs in /opt. The SUID and SGID permissions
should not be required in this directory.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/opt.
The presence of SUID and SGID executables should be tightly controlled. The /opt directory contains additional software packages. Users should not be able to execute SUID or SGID binaries from this directory.
The hidepid mount option is applicable to /proc and is used to control who can access the information in /proc/[pid] directories. The option can have one of the following values:
0: Everybody may access all /proc/[pid] directories. 1: Users may not access files and subdirectories inside any /proc/[pid] directories but their own. The /proc/[pid] directories themselves remain visible. 2: Same as for mode 1, but in addition the /proc/[pid] directories belonging to other users become invisible.For example, if you choose the value 2: Add the
hidepid=2 option to the fourth column of
/etc/fstab for the line which controls mounting of
/proc.
Users should not be able to see and access directories within /proc, which are not related to their own processes in a system. Otherwise, sensitive information from other users could be seem.
The nosuid mount option can be used to prevent
execution of setuid programs in /srv. The SUID and SGID permissions
should not be required in this directory.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/srv.
The presence of SUID and SGID executables should be tightly controlled. The /srv directory contains files served by various network services such as FTP. Users should not be able to execute SUID or SGID binaries from this directory.
The nodev mount option can be used to prevent device files from
being created in /tmp. Legitimate character and block devices
should not exist within temporary directories like /tmp.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/tmp.
The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails.
The noexec mount option can be used to prevent binaries
from being executed out of /tmp.
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/tmp.
Allowing users to execute binaries from world-writable directories such as /tmp should never be necessary in normal operation and can expose the system to potential compromise.
The nosuid mount option can be used to prevent
execution of setuid programs in /tmp. The SUID and SGID permissions
should not be required in these world-writable directories.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/tmp.
The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from temporary storage partitions.
The nodev mount option can be used to prevent device files from
being created in /var/log/audit.
Legitimate character and block devices should exist only in
the /dev directory on the root partition or within chroot
jails built for system services.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/log/audit.
The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails.
The noexec mount option can be used to prevent binaries
from being executed out of /var/log/audit.
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/log/audit.
Allowing users to execute binaries from directories containing audit log files such as /var/log/audit should never be necessary in normal operation and can expose the system to potential compromise.
The nosuid mount option can be used to prevent
execution of setuid programs in /var/log/audit. The SUID and SGID permissions
should not be required in directories containing audit log files.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/log/audit.
The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from partitions designated for audit log files.
The nodev mount option can be used to prevent device files from
being created in /var/log.
Legitimate character and block devices should exist only in
the /dev directory on the root partition or within chroot
jails built for system services.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/log.
The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails.
The noexec mount option can be used to prevent binaries
from being executed out of /var/log.
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/log.
Allowing users to execute binaries from directories containing log files such as /var/log should never be necessary in normal operation and can expose the system to potential compromise.
The nosuid mount option can be used to prevent
execution of setuid programs in /var/log. The SUID and SGID permissions
should not be required in directories containing log files.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/log.
The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from partitions designated for log files.
The nodev mount option can be used to prevent device files from
being created in /var.
Legitimate character and block devices should exist only in
the /dev directory on the root partition or within chroot
jails built for system services.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/var.
The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails.
The noexec mount option can be used to prevent binaries from being
executed out of /var.
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/var.
The /var directory contains variable system data such as logs, mails and caches. No binaries should be executed from this directory.
The nosuid mount option can be used to prevent
execution of setuid programs in /var. The SUID and SGID permissions
should not be required for this directory.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/var.
The presence of SUID and SGID executables should be tightly controlled.
The /var/tmp directory is a world-writable directory. Bind-mount it to /tmp in order to consolidate temporary storage into one location protected by the same techniques as /tmp. To do so, edit /etc/fstab and add the following line:
/tmp /var/tmp none rw,nodev,noexec,nosuid,bind 0 0See the mount(8) man page for further explanation of bind mounting.
Having multiple locations for temporary storage is not required. Unless absolutely necessary to meet requirements, the storage location /var/tmp should be bind mounted to /tmp and thus share the same protections.
The nodev mount option can be used to prevent device files from
being created in /var/tmp. Legitimate character and block devices
should not exist within temporary directories like /var/tmp.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/tmp.
The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails.
The noexec mount option can be used to prevent binaries
from being executed out of /var/tmp.
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/tmp.
Allowing users to execute binaries from world-writable directories such as /var/tmp should never be necessary in normal operation and can expose the system to potential compromise.
The nosuid mount option can be used to prevent
execution of setuid programs in /var/tmp. The SUID and SGID permissions
should not be required in these world-writable directories.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/tmp.
The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from temporary storage partitions.
If any files are not owned by a user, then the cause of their lack of ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate user. Locate the mount points related to local devices by the following command:
$ findmnt -n -l -k -it $(awk '/nodev/ { print $2 }' /proc/filesystems | paste -sd,)
For all mount points listed by the previous command, it is necessary to search for files which
do not belong to a valid user using the following command:
$ sudo find MOUNTPOINT -xdev -nouser 2>/dev/null
Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account, or other similar cases. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed.
It is recommended that the /boot directory resides on a separate partition. This makes it easier to apply restrictions e.g. through the noexec mount option. Eventually, the /boot partition can be configured not to be mounted automatically with the noauto mount option.
The /boot partition contains the kernel and bootloader files. Access to this partition should be restricted.
The /dev/shm is a traditional shared memory concept. One program will create a memory portion, which other processes (if permitted) can access. If /dev/shm is not configured, tmpfs will be mounted to /dev/shm by systemd.
Any user can upload and execute files inside the /dev/shm similar to the /tmp partition. Configuring /dev/shm allows an administrator to set the noexec option on the mount, making /dev/shm useless for an attacker to install executable code. It would also prevent an attacker from establishing a hardlink to a system setuid program and wait for it to be updated. Once the program was updated, the hardlink would be broken and the attacker would have his own copy of the program. If the program happened to have a security vulnerability, the attacker could continue to exploit the known flaw.
If user home directories will be stored locally, create a separate partition for /home at installation time (or migrate it later using LVM). If /home will be mounted from another system such as an NFS server, then creating a separate partition is not necessary at installation time, and the mountpoint can instead be configured later.
Ensuring that /home is mounted on its own partition enables the setting of more restrictive mount options, and also helps ensure that users cannot trivially fill partitions used for log or audit data storage.
It is recommended that the /opt directory resides on a separate partition.
The /opt partition contains additional software, usually installed outside the packaging system. Putting this directory on a separate partition makes it easier to apply restrictions e.g. through the nosuid mount option.
If a file server (FTP, TFTP...) is hosted locally, create a separate partition for /srv at installation time (or migrate it later using LVM). If /srv will be mounted from another system such as an NFS server, then creating a separate partition is not necessary at installation time, and the mountpoint can instead be configured later.
Srv deserves files for local network file server such as FTP. Ensuring that /srv is mounted on its own partition enables the setting of more restrictive mount options, and also helps ensure that users cannot trivially fill partitions used for log or audit data storage.
The /tmp directory is a world-writable directory used for temporary file storage. Ensure it has its own partition or logical volume at installation time, or migrate it using LVM.
The /tmp partition is used as temporary storage by many programs. Placing /tmp in its own partition enables the setting of more restrictive mount options, which can help protect programs which use it.
It is recommended that the /usr directory resides on a separate partition.
The /usr partition contains system software, utilities and files. Putting it on a separate partition allows limiting its size and applying restrictions through mount options.
The /var directory is used by daemons and other system services to store frequently-changing data. Ensure that /var has its own partition or logical volume at installation time, or migrate it using LVM.
Ensuring that /var is mounted on its own partition enables the setting of more restrictive mount options. This helps protect system services such as daemons or other programs which use it. It is not uncommon for the /var directory to contain world-writable directories installed by other software packages.
System logs are stored in the /var/log directory.
Ensure that /var/log has its own partition or logical
volume at installation time, or migrate it using LVM.
Placing /var/log in its own partition enables better separation between log files and other files in /var/.
Audit logs are stored in the /var/log/audit directory.
Ensure that /var/log/audit has its own partition or logical
volume at installation time, or migrate it using LVM.
Make absolutely certain that it is large enough to store all
audit logs that will be created by the auditing daemon.
Placing /var/log/audit in its own partition enables better separation between audit files and other files, and helps ensure that auditing cannot be halted due to the partition running out of space.
The /var/tmp directory is a world-writable directory used for temporary file storage. Ensure it has its own partition or logical volume at installation time, or migrate it using LVM.
The /var/tmp partition is used as temporary storage by many programs. Placing /var/tmp in its own partition enables the setting of more restrictive mount options, which can help protect programs which use it.
The SUSE operating system audit tools must have the proper permissions configured to protect against unauthorized access. Check that "permissions.local" file contains the correct permissions rules with the following command:
grep "^/usr/sbin/au" /etc/permissions.local /usr/sbin/audispd root:root 0750 /usr/sbin/auditctl root:root 0750 /usr/sbin/auditd root:root 0750 /usr/sbin/ausearch root:root 0755 /usr/sbin/aureport root:root 0755 /usr/sbin/autrace root:root 0750 /usr/sbin/augenrules root:root 0750Audit tools include but are not limited to vendor-provided and open-source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. SUSE operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys to make access decisions regarding the access to audit tools.
Any operating system providing too much information in error messages risks compromising the data and security of the structure, and content of error messages needs to be carefully considered by the organization. Organizations carefully consider the structure/content of error messages. The extent to which information systems are able to identify and handle error conditions is guided by organizational policy and operational requirements. Information that could be exploited by adversaries includes, for example, erroneous logon attempts with passwords entered by mistake as the username, mission/business information that can be derived from (if not stated explicitly by) information recorded, and personal information, such as account numbers, social security numbers, and credit card numbers.
The Amazon Linux 2023 must generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.
Files containing sensitive informations should be protected by restrictive permissions. Most of the time, there is no need that these files need to be read by any non-root user. Check that "permissions.local" file contains the correct permissions rules with the following command:
# grep -i audit /etc/permissions.local /var/log/audit/ root:root 600 /var/log/audit/audit.log root:root 600 /etc/audit/audit.rules root:root 640 /etc/audit/rules.d/audit.rules root:root 640
Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
System-wide library files are stored in the following directories by default:
/lib /lib64 /usr/lib /usr/lib64All system-wide shared library files should be protected from unauthorised access. If any of these files is not group-owned by root, correct its group-owner with the following command:
$ sudo chgrp root FILE
If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.
Verify that the SUSE operating system prevents unauthorized users from accessing system command and library files. Check that all of the audit information files and folders have the correct permissions with the following command:
# sudo chkstat --warn --systemSet the correct permissions with the following command:
# sudo chkstat --set --system
If the SUSE operating system were to allow any user to make changes to software libraries, those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to SUSE operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs that execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components to initiate changes, including upgrades and modifications.
To set the runtime status of the fs.protected_fifos kernel parameter, run the following command:
$ sudo sysctl -w fs.protected_fifos=2To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:
fs.protected_fifos = 2
This parameter is available since Linux Kernel 4.19 and allows to prohibit opening FIFOs that are not owned by the user in world and group writeable sticky directories. It avoids unintentional writes to an attacker-controlled FIFO where a program expects to create the regular file.
To set the runtime status of the fs.protected_hardlinks kernel parameter, run the following command:
$ sudo sysctl -w fs.protected_hardlinks=1To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:
fs.protected_hardlinks = 1
By enabling this kernel parameter, users can no longer create soft or hard links to files which they do not own. Disallowing such hardlinks mitigate vulnerabilities based on insecure file system accessed by privileged programs, avoiding an exploitation vector exploiting unsafe use of open() or creat().
To set the runtime status of the fs.protected_regular kernel parameter, run the following command:
$ sudo sysctl -w fs.protected_regular=2To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:
fs.protected_regular = 2
This parameter is available since Linux Kernel 4.19 and allows to prohibit opening "regular" files that are not owned by the user in world and group writeable sticky directories. It avoids writes to an attacker-controlled regular file, for example, when a program expects to create the regular file.
To set the runtime status of the fs.protected_symlinks kernel parameter, run the following command:
$ sudo sysctl -w fs.protected_symlinks=1To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:
fs.protected_symlinks = 1
By enabling this kernel parameter, symbolic links are permitted to be followed only when outside a sticky world-writable directory, or when the UID of the link and follower match, or when the directory owner matches the symlink's owner. Disallowing such symlinks helps mitigate vulnerabilities based on insecure file system accessed by privileged programs, avoiding an exploitation vector exploiting unsafe use of open() or creat().