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
