Hi to all.
I have a question:

In my company is a Security Officer
and i'm going to revoke from account root possibility to
change or delete system logs (only viewiewing must be available for root )

Only one person who can delete or change system logs will be user
called Security Officer with root privileges (for example user "sofficer")

Is there any way to do it with RBAC on the Solaris 9?
Can somebody help me?

I'm still digging in the Google but nothing can help me

--
Artur Dêbski
http://pl.solaris-x86.org (under construction)

Artur Dêbski wrote:
> Hi to all.
> I have a question:
>
> In my company is a Security Officer
> and i'm going to revoke from account root possibility to
> change or delete system logs (only viewiewing must be available for root )
>
> Only one person who can delete or change system logs will be user
> called Security Officer with root privileges (for example user "sofficer")
>
> Is there any way to do it with RBAC on the Solaris 9?
> Can somebody help me?
>
> I'm still digging in the Google but nothing can help me
>
no you cannot take any privileges away from root, root is god, there is
nothing root cannot do, (your security officer should know this).

what any role based access control enables you to do is "create roles".

that is create an account that is able to do what that individual has
been authorized to do according to his job role.

in an ideal situation that means that the root account is there only for
break glass occasions and is not used on a daily basis by anyone.

its password is set by a segregated role/group and stored safely away
from system administrators, but can be retried at a time when it is
needed, ie the systems on its back with its legs in the air.

these roles if designed correctly will allow each user the ability to
carry out all his/her daily functions unhindered.

the problem with the root account is that as soon as a user is root,
there is no accountability. all logs can be deleted to cover the tracks
of that individual, while her or she are on the system. by not allowing
anyone access to root except in a controlled situation, ie a problem has
occurred, joe is the sysadmin, he has broken glass to get the root
password, we know everything that has happened on that system during
that time is down to him.

hope this helps.

ps you can use any role based access control system to achieve this,
from sudo, powerbroker, boks, RBACS etc.

regards peter

On Tue, 13 Jun 2006 08:14:10 +0200
Artur Dębski wrote:

> Hi to all.
> I have a question:
>
> In my company is a Security Officer
> and i'm going to revoke from account root possibility to
> change or delete system logs (only viewiewing must be available for
> root )

The super-user account always has full privileges, which is why it
should never be used directly, and as sparingly as possible.
Use one of the tools to grant selected privileges to non-root accounts
(RBAC, sudo) to extend the privileges of "normal" users, rather than
try and reduce those of the super-user.

First identify all the tasks executed by the sysadmins, and configure
access to them using the tool of your choice (sudo is widely used and
available for all Unixoid systems, RBAC is much more fine-grained but
more complex to set up, and to all intents and purposes limited to
Solaris). Get the security officer involved, and have him endorse the
solution (that way he gets to carry the can if things go awry).

Have the security officer select a very complex password with lots of
special characters (so that he cannot remember it), write it on sheet
of paper and seal it in the safe. Note that the SO himself should not be
trusted (if the SO pretends that only he can be trusted, get him fired,
if he's any good he should trust not even himself). _Never_ use the
root account directly, unless there's an emergency. Determine the
emergency procedure, and make sure that it is the SO alone who has
access to the safe (that way, he'll have to get out of bed himself .
Change the root password after every use.

> Only one person who can delete or change system logs will be user
> called Security Officer with root privileges (for example user
> "sofficer")

Under no circumstances should a security officer have root access. He
might be trusted security wise, but even he's also the system
administrator (and so trustworthy technically) he should have strictly
controlled and limited access. If the SO suggested this (sofficer ==
root) approach, get him to reconsider (remember that a good SO doesn't
trust himself). Or get another security officer.

Take care,

--
Stefaan A Eeckels
--
Q: If ignorance is bliss, why aren't there more happy people in the
world? A: Because they don't know they're ignorant.