now our access control models. This is another element of system design, and we have to think about the degree of security we want our system to provide.
Some systems are designed to be more user friendly and to promote sharing other systems or more designed to protect confidentiality of information. Um, S O, the first system that will look at is called a dak system. A discretionary access control system. This is what your Windows system would be.
Excuse me there. This is what your Windows systems would be. And really, any client based operating systems would be Dax Systems. And when we say dak discretionary access control
and the reason it's called, that is the security of the object is based on the discretion of the objects owner.
So any time you talk about discretionary security, that could be a little concerning.
But the idea is it's designed for an environment to promote sharing in these of use. So think about a window's environment when I create a folder and I'll call that folder Mine.
Who's folder? Is it me
who does it belong to me
who could do whatever they want with it? Meat. I am the owner.
Well, could I give permission to that folder to somebody that shouldn't have access to what's in the folder? Sure, it's at my discretion
and through the use of access control lists, are how we control access in Adak model. So the heart and soul of Adak environment is the access control list, which is why sometimes you'll hear them referred to as Dacca. Lt's discretionary access control list,
because these were primarily used in dak environments.
Now this is an identity. Excuse me, an identity based system.
So you're given a user account based on your identity, who you are. You know you can account Kelly H. Or K Hander Hand or John Smith or whatever that might be, and the user account is bound to you and your identity.
Now, that being said,
um, you know, again think about how Windows is established and created, how you get your account. Ah, how we control access to resource is, but it's not just windows. You know. Most versions of Lynn Nix and UNIX and any of the other operating systems that are out there primarily used back environments.
However, if you want a more secure environment, you have a mandatory access control model, a Mac, and just listening to the names mandatory security versus discretionary security night and day, right? Mandatory sounds much more secure.
Now. You would see this on systems for use in the government or systems that need to enforce. Ah, higher level of confidentiality, the heart and soul of a Mac environment, the heart and soul here labels.
So when I create a user object in a Mac environment, they get a label.
And so I'll create Bob Smith and his label is secret because he has secret clearance.
Then I'll create a folder, and the label for that folder is top secret.
So we don't expect somebody that has secret clearance to access a top secret folder.
So the decision as to access in a mandatory access control environment is made based on, um, evaluating the labels and the objects label. Or let me say this the subject's label must dominate the objects like
so I can't access anything above my level. I can access at my level and below. I have to dominate.
But the big difference here is this is all decided by the data owner. You know what type of classification. The data is and it's enforced by the data custodian or the Security Department.
So ultimately, these labels are written in stone, so to speak. They can't be changed without a very formalized, very stringent process and its operating system. That compares the labels and makes the decision. So this is much more secure.
So ah, secure Lennix Or you might see Solaris with trusted extensions.
Those would be mac environments.
Now, another environment that tends to be a very good environment to, uh, enforce rights and permissions role based access control. You might see this is our back, because in an organization one of the problems we can have something called Privilege Creek.
So, for instance, if I'm a custodian and I work in building A, I get a key to building a,
then I go to building B. I get a key to building B.
I start work in building C. I get a key to building scene.
But what piece have we missed along the lines? We've missed getting those keys to building A and B back
same thing when you have users in an environment. So I'm the database administrator of Database A. When they move me to a different role. We need to make sure that my credentials get revoked well, instead of doing that. One of the things that we can do is use role based access control
as opposed to identity based access control, which DAK is
in a role based system. The accounts are based on function within the organization.
So with that function come a set of privileges and permissions, and they can't be changed. This is a good way to prevent a problem called Authorization Creek,
because your account is based on your role within the organization and the account doesn't change. Permissions and privileges don't get added removed.
You might be given a new role in the organization, therefore a new role account, but you wouldn't have rights and permissions heaped on the user based accounts. So those are the three main security models, DAK, which the securities at the discretion of the owner
Mac Ah, higher level of security, where security decisions are made based on labels and then our back, which is based on the role of a user within an organization. And this is a good means to provide high end tight security as well as preventing authorization creep. So those were the security models
that I would consider when I'm designing a system