Viewing posts for the category Omarine User's Manual
Every day you can do all daily works in the desktop environment as a normal user. Then no need to be the root, even not an administrator, you can power off the machine although really only root has capability to do so. That is because you have used the polkit authorization policy.
As an administrator, you can update passwords for users because you are authorized to an account service in the system. This service has the privileges to handle requests.
All users naturally need a network connection, authorization policy allows this by default. Administrators can even modify the network connection for all users without authentication if there is an authorization rule that allows it (this is the default authorization policy in Omarine).
Administrators can set system time and time zone based on authorization policy.
When you use a file browser, the filesystems on the drives are automatically mounted by the udisks tool, which is governed by the authorization policy.
There are many other applications that use authorization policy to create convenience for users. It also makes administration easy. However, convenience is always accompanied by security concerns. In this article we review and develop security policy in relation to authorization policy. In particular, we practice building an administrator program that updates user passwords applying authorization policy. This program is useful for administrators when the account service is not available.
Normal user, administrator, root, super user, privileged and unprivileged user, restricted user
Before going into the main part, we reinforce some concepts about users. They have different meanings depending on the specific context.
At the kernel level, there are only two kinds of user: root and normal user. root is the privileged user (technically, root has user ID of 0 so processes with an
effective user ID of 0 are privileged processes) and is exempt from all kernel permission checks . Hence it is also called super user. However, since the security policy, root is no longer exempted as before and its "super" ability has also decreased. In contrast, normal users who have a user ID other than zero must undergo full permission checking and the result will, depending on their capabilities, be an unprivileged user.
It is the authorization policy that gives rise to the concept of administrator, who deal with system administration and operating tasks within the scope of the authorization policy. Thus, for authorization policy there are three kinds of user: root, administrator and normal user.
In the same view as the authorization policy, the SELinux security policy has the SELinux
root corresponding to the Linux root,
staff_u corresponding to the administrator and
user_u corresponding to the normal user. In addition, SELinux also has users with lower rights than normal users, which can be classified as restricted user. Those are guest_u and xguest_u. Restricted users are uncommon and can be used for (mapping from) Linux system users. user_u is usually the default user.
Any application that wants to apply the authorization policy needs to ship (or use) a privileged program called mechanism and an unprivileged program called subject. The mechanism is run as root or its process has the effective user ID of 0, while the subject is run as a normal user or its process has the effective user ID other than zero.
Mechanism provides the service and it can accept or deny service to requests from the subject, through the authority implemented by a polkit system daemon, polkitd
There is a domain transition situation where, through a chain of domain transitions, the domain is returned to its original domain. This interesting situation is a typical case of the transition chain so that we have an outline of how the SELinux system works. Thereby we also see much work to be done to develop security policies.
The domain transition circle executing the rpm package manager program
root is the superuser who has the power to manipulate any system issue. So it sounds ridiculous that we restrict its rights. The essence of the problem is that malicious programs can use root privileges to damage the system. A good security policy should prevent all user domains including also the
sysadm_t domain of the root from directly accessing the password file. Access to the password file is only for specialized programs that perform systemized administrative tasks. Thus a crack program running in sysadm_t domain cannot steal a user's password.
We follow the steps below to experiment a password-stealing attack. We create a crack program, which can steal a user's password if allowed to read the password file. Then security policy will make it invalid.
1) Compiling dictionary creation program wordmagic
Download wordmagic and compile the program as follows
Installing Omarine 7.0 from a USB stick is very simple. You just need to copy omarine-7.0-dvd.iso to the USB stick using the command below, assume that the USB device is /dev/sdb:
useradd is a typical program of the shadow package, used to create new users. But it did not work in the secure domain regulated by the security policy. In this article, we add code to solve the problem.
There is a situation where the useradd runs in the wrong domain and cannot write shadow_t files, so it does not work, because the domain it is running is not allowed to do. We consider the following command, create a user named some_name
Can't see mail in Inbox? Check your Spam folder.