Re: (mis)using RBAC...

From: Glenn M. Brunette, Jr. (Glenn.Brunette_at_Sun.COM)
Date: 04/15/05

  • Next message: Glenn M. Brunette, Jr.: "Re: (mis)using RBAC..." 
    Date: Fri, 15 Apr 2005 11:43:23 -0400
To: Jonathan Katz <jonathan.katz@gmail.com>

    Jonathan,

    Jonathan Katz wrote:
    >
    > My questions are, is this a normal practice (are there other people
    > doing it) and is it supported? What unintended consequences am I

    This is what RBAC was designed for. Yes, it is supported and is
    widely used by many of Sun's customers.

    > missing? I understand that if a user's account is compromised, the
    > webserver services can be stopped and started at-will. I also

    This is why many organizations prefer to assign authorizations
    and rights profiles to Solaris roles. roles are the same as
    regular users except that they are not permitted to log directly
    into the system (either remotely or from the console). You can
    only "su" to a role. Attempts to do so are audited and will
    result in a message like:

    # telnet localhost
    Trying 127.0.0.1...
    Connected to localhost.
    Escape character is '^]'.
    login: webadm
    Password:
    Roles can only be assumed by authorized users
    Login incorrect
    Connection to localhost closed by foreign host.

    By placing your authorizations and rights profiles into a
    role, then the user must first authenticate to the role
    before being allowed to use the privileges assigned to
    that role.

    Further, roles can only be assumed (via su(1M)) by authorized
    users as the message above suggests. This means that you could
    assign your web server administrators to a role like webadm and
    no other user could attempt to assume that role. Attempts to
    do so would yield a message like:

    $ id -a
    uid=105(joe) gid=1(other) groups=1(other)

    $ roles
    roleA

    $ getent passwd roleB
    roleB:x:108:1::/export/home/roleB:/bin/pfsh

    $ su roleB
    Password:
    Roles can only be assumed by authorized users
    su: Sorry

    In this case, user "joe" was permitted to assume "roleA" but
    not "roleB".

    > understand that our sysadmin group will be restricted to using
    > pfcsh/pfksh/pfsh and cannot use bash or tcsh (although we can still
    > leave those set, type 'exec pfsh' and then do what we need to do as
    > the Profile.)

    By default, roles are created with a profile shell (pfsh). You
    do not need to use profile shells however in order to execute
    commands with privilege. You can use the pfexec(1) command if
    you like. For example:

    $ id -a
    uid=106(john) gid=1(other) groups=1(other)
    $ profiles -l

           Crypto Management:
               /usr/sbin/cryptoadm euid=0
               /usr/sfw/bin/CA.pl euid=0
               /usr/sfw/bin/openssl euid=0
           All:
               *
    $ /usr/sbin/cryptoadm stop
    cryptoadm: failed to stop cryptographic framework daemon - Not owner.

    $ pfexec /usr/sbin/cryptoadm stop
    $ pfexec /usr/sbin/cryptoadm start

    Hope this helps. Let me know if you have any questions.

    g 

    -- 
Glenn M. Brunette, Jr.
Distinguished Engineer, Chief Security Architect
Client Solutions, Global Data Center Practice CTO
Sun Microsystems, Inc.
  • Next message: Glenn M. Brunette, Jr.: "Re: (mis)using RBAC..."