Securing Package CGIs?
-
I found the issue with Squid's cachemgr.cgi not working and was ready to submit a patch - however, I found that the authentication in the PFSense GUI is implemented at the PHP level not the web server level. As a result, the cachemgr is visible to anybody with access TCP access to the pfSense port 80.
This seems sloppy to me and I wanted to see if if there were any pre-existing thoughts / past conversations on how this should be handled going forward as it is bound to be a problem that appears again…
My gut reaction is moving auth it into lighty would be for the best since nobody has business in any aspect of the admin gui without authorization...but I have not investigated yet what would be involved in doing that...
- Mike
-
I found the issue with Squid's cachemgr.cgi not working and was ready to submit a patch - however, I found that the authentication in the PFSense GUI is implemented at the PHP level not the web server level. As a result, the cachemgr is visible to anybody with access TCP access to the pfSense port 80.
This seems sloppy to me and I wanted to see if if there were any pre-existing thoughts / past conversations on how this should be handled going forward as it is bound to be a problem that appears again…
Sloppy? How else are we supposed to have multi-level authentication? IE: How can spamd's outlook button ask for a seperate username and password which is outside of the scope of the webConfigurator?
My gut reaction is moving auth it into lighty would be for the best since nobody has business in any aspect of the admin gui without authorization…but I have not investigated yet what would be involved in doing that...
- Mike
No it wouldn't. It will break 3rd party modules such as SpamD's auth. Authentication most likely needs to be added to the cachemgr.cgi or the the right thing should be done which is rewriting the cachemgr.cgi functionality in PHP using our auth.inc framework.
-
My "sloppy" comment was refering to leaving the CGI unsecured…not the current code...sorry if it was taken wrong...
As I had not used these other modules, I was unaware of how they acted - thus the reason I opened the thread in the first place...to learn/discuss what options there might be...
Rewriting the cachemgr in PHP might be cleaner, but is going to require a much larger effort to in code/maintenance...
Would it be feasible to create a directory that is secured by Lighty for the purpose of housing unsecured package web modules?
-
After 1.0, we're moving to PHP session based authentication, so no, moving auth into lighty isn't an option. HTTP Basic auth sucks ass and doesn't allow us to either time out sessions or log users out. Not good. All other applications need to either handle their own auth, or figure out how to use the already existing authentication methods. I may try to use sqlite for the session store so it's "easy" to share session state between apps - we'll see, it's not a high priority for me.
When lighty supports session cookie authentication with RADIUS and LDAP for password verification, then we'll consider moving the authentication into the web server. Care to write a module for that?
–Bill
-
OK - thanks - I have a better sense where things are going now…as you have seen in my other email, I took the first pass option of forcing users to enable the cachemgr so you have to choose to accept the risk...
If I ever find enough free time I am qualified to write the module you propose - but time is always the trick...my hat is off to you - I don't know how you (and many other good OpenSource authors) find the time to do this...
An option I was toying with overnight was how one could make a PHP wrapper so that the cgi was kept outside the web directory and content was in an iframe or similar with the PHP wrapper handlng security - would even allow us to keep the pfsense menus on the screen :) ...unfort my PHP is pretty weak (I'm just an old Asm/C/C++ dev turned Java in the current day/age) - so I don't know how hard doing the CGI calls from PHP would be...can't imagine it's too bad but caveat coder
-
OK - thanks - I have a better sense where things are going now…as you have seen in my other email, I took the first pass option of forcing users to enable the cachemgr so you have to choose to accept the risk...
If I ever find enough free time I am qualified to write the module you propose - but time is always the trick...my hat is off to you - I don't know how you (and many other good OpenSource authors) find the time to do this...
An option I was toying with overnight was how one could make a PHP wrapper so that the cgi was kept outside the web directory and content was in an iframe or similar with the PHP wrapper handlng security - would even allow us to keep the pfsense menus on the screen :) ...unfort my PHP is pretty weak (I'm just an old Asm/C/C++ dev turned Java in the current day/age) - so I don't know how hard doing the CGI calls from PHP would be...can't imagine it's too bad but caveat coder
Hmmm…that's actually not a half bad idea. I dunno about an iframe, but we could probably allow auth.inc to do it's job and use passthru() or something to run a cgi. I'll have to think about that a bit.
--Bill