Re: (mis)using RBAC...Apr 15 2005 03:43PM Glenn M. Brunette, Jr. (Glenn Brunette Sun 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:
$ 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
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.
[ reply ]