-
Notifications
You must be signed in to change notification settings - Fork 64
Secure File And Path
Starting with openSeaChest's v24.08 release many new security enhancements were made.
The most noticeable for users is that files must only be accessed from secure directories.
The most noticeable case for a user will likely be when trying to perform a firmware update as it may fail to open the file. When openSeaChest is attempting to access the file, it now checks the permissions to every directory in the path to this file to make sure it is secure.
This security improvement was made by following the SEI Cert-C Coding Standard which defines a way to ensure secure practices with files and directories for C applications. See the References section for more information.
Some tools output files such as log files which are then read as input files by other tools. This introduces a risk that the files may be tampered with between the writing and reading these files back which may cause software to behave in an unexpected manner and potentially lead to exploitation. With tools that require administrator/root/sudo level permissions, this can raise the risks even higher if an attacker were to find a way to cause the software to behave in an unexpected manner and become exploitable. Seagate’s software that communicates with HDDs or SSDs requires these elevated permissions because the operating system requires elevated permissions to access the storage devices to capture the information these tools use.
The summary of the rules for a secure directory is that the destination directory and all the other directories in the path to the destination directory should only be accessible by the administrator/root/system and the current user. A directory must not be writable by any other system user as that user could change the permissions for the subdirectories, making them insecure. There can be no more than 5 symlinks in the canonical path to the directory as well.
A secure file has the same requirements for accessibility plus a few others. If possible, a file can be uniquely identified before reading it, it should be uniquely identified before reading the contents of the file to ensure it is the same file as expected and not a link to some other file which is not expected to be read by the software. The unique ID requirement may not always be possible, but when it is available, it should be handled in this way.
It is easy to define permissions for a POSIX environment and easy to verify permissions of a file or directory using the ls –la command. The output from this command can even be piped to grep to make it even easier to view: ls –la | grep “directoryname”
Files and directories have permissions as user-group-root indicated as rwx for each of these categories. The meanings of these letters are r = read, w = write, x = execute.
The simplest way to determine the directory causing a file/directory to not be trusted is if a directory has the group write permission set.
Changing the permissions for a directory is easy to do:
chmod 0755 <dirname> will set user permissions to rwx, group permissions to rx, and root permissions to rx. This is recommended for Seagate software that runs as root/sudo to access hardware (SeaChest, openSeaChest, etc.).
If a directory is not owned by either the root user or the current logged in user, this may also create an insecure directory. A directory owned by another user or group will not be trusted since these other users may be able to tamper with the file in this directory between the time it is written or read.
There is one modification to how directory permissions are evaluated in Seagate software from the Cert-C recommendation: Allowing sudo.
When a user has been granted permission to run an application using sudo, they have already been granted permission to run that software at an elevated level. The default code implementation in Cert-C's wiki does not allow for this case though.
In order to continue trusting the directories without error when a user has executed software using sudo, the environment variable SUDO_UID is read securely using another Cert-C rule to detect a tampered environment variable list. Once this UID has been read, it is then put into a second round of validation to check if the directory being accessed is the user who executed sudo belongs to the user or not before deciding it is to be trusted or not.
Windows has much more complicated permissions than POSIX environments and validation is a bit trickier to describe, but Seagate has implemented a similar process to determine if a directory or file is secure in Windows.
In Windows, every user has a SID (Security Identifier) as does the system, administrators, Windows update service, etc.
There is no single “administrator” with permissions like root, but there are lots of similarities with what are called “Well known SIDs” that can be easily identified in Windows.
In Windows, the directory C:\Users\yourUsernameHere where “yourUsernameHere” is your currently logged in user will have permission to access for only the Administrators, System, and the User. This is a trusted directory, as are the default Documents, Pictures, Videos, etc. folders that are set up by default for a user.
C:\Users\UsernameHere and subdirectories are the only directories that can be evaluated for trust (and they should be safe by default Windows permissions that are applied to this directory and the subdirectories). If a user’s folder or subfolder is granted permission to share to others, it will not be trusted, just like in POSIX systems.
The C:\ directory, where Windows is usually installed (although the tools will also support other volume letter identifiers, ex: G:\) is set up with permission for Administrators, System, Authenticated Users, and Users (meaning ALL users).
C:\ is NOT a trusted directory by Seagate software since this directory is accessible by everyone on the system by default and this set of permissions CANNOT be changed.
Creating a new directory on C:, even as your logged in user automatically assumes some permissions from C:\ that cannot be removed as well! It is possible that at some subfolder depth these permissions can be removed, but this has not been verified.
C:\Users\ is another special case that is only trusted by Seagate software to get to the current user’s directory because it is also accessible by “Everyone”.
This directory cannot and should not be used to save files to by Seagate’s software and the current logged in user’s directory should be used instead.
If customers run into issues with these rules or have other customizations to their permissions, they will need to be evaluated on a case-by-case basis to see if they can be supported under these security rules.