RBAC

Hi, as yu might know in UNIX-like operating systems, file permissions are
determined per object. For each file the permissions for three classes of
users ("user", "group", and "others") are registered. My question is: can I
consider this as a role-based access control mechanism?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

the snake wrote:
> Hi, as yu might know in UNIX-like operating systems, file permissions are
> determined per object. For each file the permissions for three classes of
> users ("user", "group", and "others") are registered. My question is: can I
> consider this as a role-based access control mechanism?
>
>
>
As I read the description of "role-based security" (see
http://csrc.nist.gov/rbac/NIST-ITL-RBAC-bulletin.html ), the answer is no. Unix
file permissions do not constitute a "role based access control mechanisn".

- --
Lew Pitcher
IT Consultant, Enterprise Application Architecture,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFBSeo4agVFX4UWr64RAtR+AKCd6Kv6OsvZyrxeotKJQA aCGG2VPQCgkAq6
qppAZyiWjK4W48MTVmYILFE=
=fsJ9
-----END PGP SIGNATURE-----

the snake wrote:
> Hi, as yu might know in UNIX-like operating systems, file permissions are
> determined per object. For each file the permissions for three classes of
> users ("user", "group", and "others") are registered. My question is: can I
> consider this as a role-based access control mechanism?
>

The idea of "roles" is that a collections of users can perform certain
tasks associated to one or more "roles". So.. it is POSSIBLE to use
group bits to control USER-LEVEL resource access to a limited extent.
However, the fun begins when you need higher/other priviledges (primarily and
mostly meaning root... though certainly could be other user ids as well).

It's possible with to at least handle program execution using a
front end tool like sudo. If you have extended ACLs, you can
probably get 70-80% of the rest with that.

With SELinux and other security efforts, role based security will
eventually become commonplace in Linux. But... you can fake it
(with a good set of configs) for the most part today.

Chris Cox wrote:
> the snake wrote:
>
>> Hi, as yu might know in UNIX-like operating systems, file permissions are
>> determined per object. For each file the permissions for three classes of
>> users ("user", "group", and "others") are registered. My question is:
>> can I
>> consider this as a role-based access control mechanism?
>>
>
> The idea of "roles" is that a collections of users can perform certain
> tasks associated to one or more "roles". So.. it is POSSIBLE to use
> group bits to control USER-LEVEL resource access to a limited extent.
> However, the fun begins when you need higher/other priviledges
> (primarily and
> mostly meaning root... though certainly could be other user ids as well).
>
I would not call root privileges "higher level". Root is too
powerful---that is, too dangerous---and so many systems
(eg. Linux) divide the root level privileges in subsets which
are called capabilities.

> It's possible with to at least handle program execution using a
> front end tool like sudo. If you have extended ACLs, you can
> probably get 70-80% of the rest with that.

Not really. The Unix privileges are fairly crude. They
cannot control (overt) information flow---eg. "who can see
my credit card number". The are also unnecessarily complex
for the protections provided. (Eg. multiple uid credentials
per process).
>
> With SELinux and other security efforts, role based security will
> eventually become commonplace in Linux. But... you can fake it
> (with a good set of configs) for the most part today.

In general, RBAC supports administrative controls which enable
you to control how the system evolves over time. The idea here
is to remove the all powerful root as system administrator.
SELinux does not have such general purpose administrative
controls.

(PS. I don't want my security faked :-)

Jon