Access Control
Security module
senhasegura has its own security module built inside the senhasegura.go for Linux client. It was developed to simplify the access control using the Access Control List at kernel level.
The main benefit of this security module is that any rules registered in the senhasegura server will be applied to any type of execution:
Shell executions
Software executions
Script executions
Parent and Child process controls
This means that even if the user tries to shell scape, outwit, or abuse privileges, they won't be able to.
The security module allows the system administrator to create policies, scan and control files and folders, set permissions, full control of permissions, and so on, all based on Access Policies.
Each type of feature, and how to configure, you can find further in this manual.
Creating the first policies
From this point on, the target device is already informing senhasegura which users it has and requesting blocking and auditing policies. We will then approve the device and register our first policy.
If successful, you will receive the message This device was registered successfully., As in the example below:
root\@debian:/root# secpack-register
senhasegura security pack v1.0.0-1
ERROR: 1002: Registration of pending approval workstation
Adding group gonix \...
This device was registered successfully.
The message ERROR: 1002: Registration of pending approval workstation indicates that this device has not yet been approved by the senhasegura manager to receive lock and audit information. We'll see that in a moment.
Authorizing devices
Through the menu GO Endpoint Manager ➔ Workstations you will have a list of devices that are using the senhasegura.go for Linux policies, devices that have been revoked, and devices that are pending approval. In our example, our newly installed device is pending. See the image.
Notice that the column Status has a yellow circle that represents this state of indecision. This circle can vary between green for approved devices and red for revoked devices.
To approve the use, click on the registration action Approve.
Once approved, this workstation will receive the guidelines that we will register below.
Registering kernel-level policies
Kernel-level policies control the Linux Access Control Lists (ACLs). This feature essentially gives the ability to restrict or allow access at the kernel level.
ACLs allow the system administrator to apply a more specific set of permissions to objects, as well as what operations are allowed on which objects.
These rules will also apply to commands executed within scripts. senhasegura.go for Linux has a security module that will enforce policies in any scenario, we make no distinctions between user or script executions.
Warning! Prohibitive policies can cause major damage to the device. This can lead to total blocking of interactivity.
Through the menu GO Endpoint Manager ➔ Policies ➔ Linux ➔ Access Policies you can view and manage all registered policies. The policies are segregated at three levels.
General: Policies that apply to all devices where senhasegura.go for Linux is active and approved
Per device: Policies applied to specific devices
By username: Policies that apply only to devices that contain the specific username.
To better understand its use, we will present the following problem.
Within a corporation, the DBA is a highly trusted and hired employee. Support for operating systems is provided by a contractor. \par The contractor has a high-privileged user to perform updates and maintenance on the device. As a result, these outsourced employees end up having access to the Oracle ® onfiguration file at the risk of changing it. The Information Security Manager and the DBA would like to protect the writing in this file centrally without having to create several auxiliary groups server to server, at the risk of losing control of the members of these groups.
In this case, it will be necessary to create a policy on senhasegura.go for Linux stating that only the DBA user has permission to write to the target file. Thus, not even the super user will be able to change its content. Even though he has authority over the file.
Follow the steps below to configure this scenario.
Access the policy report through the menu GO Endpoint Manager ➔ Policies ➔ Linux ➔ Access Policies
Click on the report action New Rule to create a global policy
In the form that opens, fill in the fields as follows
Identification name: Name of the policy. Required field. This name must be friendly so that it is easily identifiable. It will not be passed on to the target device. In this example, we will populate it with "Deny TNS changes"
Enable audit: Indicates whether to enable auditing of actions that fall under this directive. The field is mandatory, and by default, it is active. We will keep it active.
Enabled: State of the policy. Required field. If active, the policy will be considered on the target devices. Otherwise, it will not be applied. We will keep it active.
Guideline: Kernel policy to be monitored. Required field. These actions come from the actions supported by the CaitSith10library. We will use the "Write file" directive. This policy will identify the moment that an attempt to write to a file occurs.
Checker: Target of the policy. Although this field is not mandatory, be very careful not to fill it out. Failure to fill in or fill in this field incorrectly may cause the device to become completely bricked.
In this example, we will fill the variable path with the location of our target file. Example:
path=˝/etc/oracle/tnsnames.ora˝Include general denial rule?: Indicator if the deny all policy should be considered at the time this policy is applied. As it allows actions for specific users, it is interesting that other users have this privilege denied. We will keep it marked in our example. Required field.
Up to this moment, we have registered the characteristics of the policy to be registered. We will now indicate the users who are allowed or prohibited from executing the policy.
Allow or deny: Indicates whether to register a permission or deny policy for the user. In our example we will register a Allow policy for our DBA user
Rule text: Now we will place our username
dbawithin the CaitSith11policy format. Example:task.uid=˝dba˝. This indicates that if the process that fits the policy has the UID of the DBA username, that policy will be accepted.
Save the record and observe the result on the target device!
Any commands that go through a filtering process and that a rule has been defined to allow execution within Access Policies (caitsith) or Sudo rules if the command execution was permitted through Access Policies will be recorded.
Once the user runs any command that is in Access Policies, the system will automatically start recording the session.
The start of the session will be linked with the PID of the process, so when that PID and all the processes spawned by that PID are terminated, the recording must end.
Warning! The Checker and Rule text fields, although not mandatory, require attention. Empty values or fill in this field incorrectly may lead to brick the device. And their values must be surrounded by double quotes as shown.
Validating the policy on the target device
We will then return to our example by showing:
that the rule was created on the target device;
that the DBA user has permission to write to the file; and
that the super user will not be able to write to the file
Validating the policy
View the /sys/kernel/security/caitsith/policy file to check the default CaitSith12rules applied to the device.
root\@debian:/root# cat /sys/kernel/security/caitsith/policy
POLICY_VERSION = 20120401
stat Policy updated: 9036 (Last: 2019/12/24 00:31:57)
stat Requests denied: 10 (Last: 2019/12/23 18:55:22)
stat Memory used by policy: 4512
stat Memory used by audit: 63808
stat Memory used by query: 0
quota memory audit 16777216
quota memory query 1048576
quota audit \[1\] allowed = 0 denied = 1024 unmatched = 1024
**1**00 acl write path="/etc/oracle/tnsnames.ora"
audit 1
100 allow task.uid = 1002
200 deny
The above output has some statuses that are not important at this point. But notice that the highlighted text presents exactly the rule that we created earlier. senhasegura.go for Linux even translated the dba username to its correct UID since this will not always be the UID on each device.
Writing to the file as a dba user
Now we will insert content into the target file as a dba user. According to the applied rule, it must be accepted. Notice that the dba user can write to the file.
Trying to write to the file as superuser
The super-user will not be able to write to the file, since this user is in the denial rule of the created policy. Even as a super user, the writing attempt fails.
Event Report
This report is present as a detail in all records of the Workstations, Applications, Uninstallers and Control Panel reports.
In this report, each automatic or intentional action of the user is centralized from senhasegura.go . When accessed as detailing, you have the filtered and reduced view of the source entity. But accessing through the menu, you have access to all filters and the possibility of combinations to identify the events that are occurring in workstations.
In the action field is possible to change permissions of a previously executed application by the user, restricting or allowing the application so that the user will or won't be able to use this tool again in a future moment.
View report command logs
In the GO Endpoint Manager ➔ Reports ➔ Linux ➔ Command Logs module, you can view the report of the commands executed in the application. In this report we have this information:
ID: event identifier number.
User command: command entered by the user.
Executed command: command executed on the machine.
Status: current status of the command.
Event date: when the event occurred on the machine.
- CaitSith (GNU 2) https://caitsith.osdn.jp/↩
- CaitSith (GNU 2) https://caitsith.osdn.jp/↩
- CaitSith (GNU 2) https://caitsith.osdn.jp/↩