I would really appreciate help with this question . Your manager wants to implem
ID: 3816311 • Letter: I
Question
I would really appreciate help with this question.
Your manager wants to implement RBAC functionality. Your shop uses a UNIX system. You do not have a system with an implementation of RBAC available to you. You have the basic capabilities of UNIX/LINUX (e.g. groups, permissions, utilities, scripting) at your disposal for access control and implementing your infrastructure. You also have access control list functionality and sudo available.
Discuss how far you can go implementing RBAC functionality with the tools at your disposal. Show some of the constructs you would use.
What RBAC functionality would be difficult or not practical to implement?
This assignment requires some detail so please be as thorough as possible when writing the answer.
Thank You
Explanation / Answer
Nowadays the trend towards role based access control(RBAC) has become apparent. In the real world, security policies are dynamic. Access rights, whether discretionary or mandatory, need to change as the responsibilities of users change. User may be transferred to different units and based on the units access rights to the system should be modified. This can create a problem to management. When a new user is authorized for a system, the appropriate rights for that user must be established. When a user changes job functions, some rights should be deleted, some maintained, and some added.
Roles are similar to groups in Unix file system DAC, However there are two importat distinctions:
1. A group is a set of users, whereas a role is a set of rights.
2. A user is always a member of a group, whereas a subject may activate or deactivate the rights associated with any of the subject's roles.
So this enables finer-grained implementation of the Principle of Least Privilege. Subjects may login with most of their roles deactivated, and activate a role only when the rights associated with the role are necessary.
Following simple procedure one can follow:
1. Design the roles you need
2. Give them each a name in a sensible and consistent naming pattern
3. Create a group account for each of those roles
4. Assign users as members of the groups as appropriate for their role(s)
5. Then, in sudoers, assign the set of permitted commands for sudo based upon the need of the name role ("%group" permissions).
6. Then, assign FACLs the the files and/or directories and/or remote filesystem mounts that pertain to those same groups.
Keep in mind, group == role and role == group
7. Make sure that groups that are role-based are prohibited from having any other meaning in your organisation.
Issues with Unix in implementing RBAC:
1. Access control in UNIX operating systems has historically been performed by using the UID associated with the process to determine access.
2. However, the root UID of 0 has traditionally been allowed to bypass permission checks. Therefore, a process that is running as the root user can pass any access checks and perform any operation. This is a security issue for the UNIX concept of setuid applications.
3. The setuid concept allows a command to run under a different identity then the user who invoked the command. This is necessary when a normal user needs to accomplish a privileged task.
4. An example of this is the AIX passwd command. Since a normal user does not have access to the file that stores user passwords, an additional privilege is needed to change the user's password, so the passwd command is setuid to the root user.
5. When a normal user runs the passwd command, it appears to the operating system that the root user is accessing the file and the access is granted.
6. While this concept does provide the desired functionality, it carries with it an inherent risk. Since the setuid program is effectively running in the root context, if an attacker successfully takes over the program before it exits, then the attacker has all of the powers of root and can then bypass all operating system access checks and perform all operations.