Multiple User Admin mode 🔗 link

Today I am using BigBrother/BBgen 3.6. One of the custom features I have
hacked into our system is the ability to have multiple admin users that
can put servers into maintenance mode. In our BB configuration we made
extensive use of the the HostGroup function. Basically creating an
aliasname for a list of devices. This came in handy when writing alert
rules, I could do one alert rule for a series of devices.

Now for maintenance mode, I hacked the maint.pl script found on deadcat.
That script was then put into a directory that apache password
protected. When you logged in, the maint.pl script compared your login
name to any HostGroup that was defined, and if the login name matched a
HostGroup the maintenace device listing only listed the devices that
were defined by the the HostGroup.

Now I did see the archived mailing list article, Re: [hobbit] New
Features #2 (the 'publish-cookie' option)
(http://www.hswn.dk/hobbiton/2005/05/msg00369.html). That solution
really only limits users from viewing different pages. The maint option
under the device info report is located under the /hobbit-cgi/ and I do
not see a way to limit users from disabling devices they shouldn't. If a
user has an admin password, they seem to have admin rights to all of
hobbit.

Under Hobbit I do not see anyway to define HostGroups, so my old method
will not work. Using HostGroupings seemed ideal in that it linked alerts
being sent to users and the user's ability to disable devices/tests.

 ~Steve

On Thu, Jul 13, 2006 at 11:16:12AM -0400, Aiello, Steve (GE, Corporate, consultant) wrote:

It's not entirely correct that the "maint" option on the info page is
freely accessible. Even though there's a link to disable tests directly
on the info page, doing so still goes through the normal maintenance
script in the secured hobbit-seccgi area, so a login is required to use
that function. But as you point out:

That's true. Hobbit in itself doesn't implement any security mechanisms.
Neither does BB, by the way. Your modifications to maint.pl were needed
to implement this.

What I do at work is to require logging in just to view stuff. No anonymous
access allowed; and then I control access to the webpages so users can 
only see the pages with the hosts they are allowed to touch. This does
keep users from doing something by accident, but it will not prevent a
determined attacker from getting access to view information about hosts
if he knows the hostname (you can manually enter the URL's for e.g. the
hostsvc CGI to get at the information you want). And if he has an admin
password, then yes - he can disable anything he likes.

It only solves part of the problem, really. In most cases where my users
need to disable something, it isn't because of an alert - it's because of
planned maintenance. I personally don't think systems should be disabled
because something breaks; the alert should be acknowledged, not
disabled. But I guess there are different ways of using the system.


I don't have a ready solution to this. Solving this "the right way"
would require implementing a true user authorization system inside Hobbit;
some way that you could assign access right to various parts of the
system based on the identity of the user. That's a pretty big chunk of
stuff to put into the Hobbit UI - but I'm pretty sure it will become
necessary at some point. Certainly if Hobbit drops all of the statically
generated webpages that you can control access to via your webserver
access controls; dropping the static pages would be nice because you
would eliminate the overhead of generating webpages that are not used,
and what you see will always be up-to-date. So it's something that I 
have considered doing, and when it happens - then we'll need to
implement authorization and access controls in Hobbit.

In the mean time, it would be possible to hack something together like
what you've done with maint.pl. When a user tries to disable/enable
a test, the hobbit-enadis.cgi tool could look up the list of alert-recipients
for this particular host+test combination, much like hobbitd_alert
does when you use the --test option. It's a reasonably simple call to 
one of the Hobbit library routines. If the user is not on the list,
then deny his attempt at disabling the test.


Regards,
Henrik