Seems like a plausible approach. I'd like to see a working version of it
:-). We should really classify usage scenarios ie.
1. Ganglia behind the firewall no access controls needed or Ganglia
protected using Basic Auth
2. Grainy access controls like the ones you have outlined
Beyond that we have potential issues like
1. Whether person has access sanitize input. Exposure here is on the Edit
Optional Graphs and Views and using things like ../.. etc. I already have
parts of input sanitization in edit optional graphs.
2. XSS and CSRF are dangers with XSS likely easy to fix.
Vladimir
On Thu, 14 Apr 2011 10:17:24 -0500, Alex Dean <a...@crackpot.org> wrote:
> Here's what I've been working on:
>
> 1. Create a login.php script. This is protected by Apache
authentication
> so you can use htpasswd, LDAP, or whatever you want for authentication.
If
> you're able to access this page, your username + a shared secret is
hashed
> & stored in a cookie. The shared secret is stored in Apache config
> ('SetEnv ganglia-secret myreallysecretphrase'), so it can be read only
by
> root. Users w/o root access could still set it in .htaccess, but it
> wouldn't be as secure.
>
> 2. Using Zend_Acl to set up access controls.
> - Anyone can view any public cluster without logging in.
> - Private clusters don't appear until you log in and have permissions
to
> view them.
> - You cannot save views or otherwise make changes unless you log in and
> have appropriate permissions.
> Basically, there are only 'view' and 'edit' privileges, applied on a
> per-cluster basis. There's a 'guest' role which applies if you're not
> authenticated, and there's an 'admin' role which has full access.
>
> 3. A ganglia-specific authorization system compares your cookie to the
> Zend_Acl list, and decides whether you can or can't do a certain thing.
>
> 4. User-editable files like view definitions get moved to
> /var/lib/ganglia/data. Keeping them out of the web root reduces the
danger
> if the code which does the writing is ever exploited.
>
> I've got a lot of this created. It's rough, but coming together fairly
> quickly.
>
> Should we maybe release a 'preview' of the new web UI without this
stuff?
> I agree we should get the new UI out in front of more people. But I do
> also think we need to address the security implications of what we've
> currently got before making an official release.
>
> thoughts?
>
> alex
>
------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and
improve
> application availability and disaster protection. Learn more about
> boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Ganglia-developers mailing list
> Ganglia-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ganglia-developers
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
