RBAC Solaris 9 - SUN

This is a discussion on RBAC Solaris 9 - SUN ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: RBAC Solaris 9

  1. RBAC Solaris 9

    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)


  2. Re: RBAC Solaris 9

    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



  3. Re: RBAC Solaris 9

    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.

+ Reply to Thread