In some systems we have what is called, Role-Based Access Control.
Role, sort of, is what you do, your function perhaps that may
learn what kind of files you can access if your human resources or
payroll, or you are in the different department.
The set of files you can access would depend on what
your role in the organization is.
So there is role-based access control or RBAC that is implemented,
it's a little difference so
I thought we'll just spend just a couple of minutes talking about it.
In role-back Access Control, remember, rights are for
being able to access different resources, so those are access rights.
Those are associated with the role, they're not associated with the user.
So the way to think about the way you going to define your policy,
access control policy is you're going to say, what roles do I have in my system?
And for each role,
what kind of resources do they need to have access to?
So I would say people in this role can read these files or
write these files and things like that.
So this part of the policy basically says, access rights are defined for
roles.
And users who going to log into the system or
authenticate themselves to the system can then take on some roles.
So RBAC, the way to think about this is that we don't have
direct access rights for users.
Users must be activated into one or more roles.
And once they assume one or more roles,
based on what those roles give them access to, that's what the user, or
the process running on this behalf of this user, can access.
So we're talking about enterprise setting.
Access may be based on job function or role of a given user.
That's where this might make sense.
Project manager may have access to all the files.
The developers or people doing QA or
something like that may access files in different ways and so on.
Payroll manager and HR function may be able to look at files that have people's
salaries and so on because they are payroll managers and things like that.
So this is how roles will be defined.
Access rights associated with roles, as we said before, and
users when authentication happen and then we know the user is was
logging into the system, we have to then so to start with authentication, but
then be able to activate one or more roles for them.
So role activation is something else that has to be added to this process.
The policy defined here and there are two stages, activating a role for
a user and based on that deciding what the user can access.
Now there's some benefits that come when we have role-based access controls.
What could be some of these benefits?
So first of all we said our policy defines
what roles have kind of access for resources in the system.
So the policy doesn't need to change when,
let's say a certain person leaves the organization.
Policy is associated with roles.
It's not associated with users so users coming or
going they don't require changes to the policy the organization has.
When a new employee comes,
basically we think about what role is appropriate for them.
And as soon as we decide their role, based on their function and
what resources they should have access to automatically happens,
because that role, along with it has had an access right to various resources.
And that, as I said, happens automatically
as soon as we decided what role this new employee can take.
An interesting thing, least privilege, remember,
is one of the design principles that we had, which said you should
always execute with the smallest number of privileges or
access rights that you need to do what is being done at that time.
And it's a really damage containment thing.
If something goes wrong, you don't negatively impact
resources that you have no business having access to at that point.
So how does RBAC help you with that?
Well actually it does, because user can start in one role and
access a subset of the files that are only available to that role.
The user can then switch roles and then go access a different set of roles,
a different set of files associated with a new role.
If you don't have RBAC and a user has a UID and has access to everything, he or
she can never access.
Roles sort of give you this ability to control,
saying if you're in a certain role at a given time only the resources needed for
that role should be available at that point, and we can do that with RBAC.
Being able to implement least privilege is a good thing.
That the design principle for
systems we want to trust, so RBAC actually enables that.
So there are actually systems that implement RBAC.
SELinux, we're going to come back to it, is Security-Enhanced Linux
actually supports RBAC, and there are others as well.