Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Focus-Sun
[Top] [All Lists]

RE: (mis)using RBAC...

Subject: RE: (mis)using RBAC...
Date: Thu, 14 Apr 2005 10:01:22 +0930
To answer a question that you didn't ask, sudo is an excellent
alternative to su(1m), with the ability to selectively allocate root
commands to users. 

It is also much simpler than RBAC for the scenario you've described.
Here's an example sudoers file:

        User_Alias      WEBADMIN = user1,user2,user3
        WEBADMIN        ALL = (root)
/opt/app/iplanet/https-myserver/start, \
                        /opt/app/iplanet/https-myserver/stop

And an example usage:

        host> id
        uid=1001(user1)
        host> sudo /opt/app/iplanet/https-myserver/start
        Password:
        [ . . . command runs . . . ]

By default, sudo prompts for the user's own password. This means that
you can lock the root password in a safe, and only get it out for
single-user mode. You can also configure it to prompt for the target
user's password, or no password at all (on a per-command basis).

Sudo requires no special shells or any other changes to your user's
environment. It's available on the Companion Software CD since Solaris
8.

-----Original Message-----
From: Jonathan Katz [mailto:jonathan.katz@gmail.com] 
Sent: Wednesday, 13 April 2005 4:50 AM
To: focus-sun@securityfocus.com
Subject: (mis)using RBAC...

All,

I was recently charged with setting up RBAC so that the group I work
with will 'su to root' less often.

The first project I've picked is to either establish a role and/or
profile that will allow a normal user to start and stop our
webservers. Here is what I came up with, bypassing the concept of a
'role'...

1) I created a profile called "Web Administration" 
in /etc/security/prof_attr
Web Administration:::Role for restarting webservers::

2) I gave the profile the ability to run the start and stop webserver
scripts as root:
in /etc/security/exec_attr
Web
Administration:suser:cmd:::/opt/app/iplanet/https-myserver/start:uid=0
Web
Administration:suser:cmd:::/opt/app/iplanet/https-myserver/stop:uid=0

3) I then added the role to my account on the server in /etc/user_attr:
jkatz::::type=normal;profiles=Web Administration,Basic Solaris User

4) Finally, I changed my shell to /bin/pfcsh. Now, with my regular
user account I can start and restart our webservers.

My questions are, is this a normal practice (are there other people
doing it) and is it supported? What unintended consequences am I
missing? I understand that if a user's account is compromised, the
webserver services can be stopped and started at-will. I also
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.)

Thanks!

-- 
-Jon
Jonathan Katz -- J. Random BOFH

<Prev in Thread] Current Thread [Next in Thread>