[SUCS Devel] Sanity of the signup scripts

Chris Jones rollercow at sucs.org
Tue Jul 10 21:33:19 BST 2007


On 10 Jul 2007, at 17:55, Andrew Price wrote:

> On 10/07/07 17:25, Chris Jones wrote:
>> On 10 Jul 2007, at 16:45, Andrew Price wrote:
>>
>>> My slightly less paranoid and more practical self
>>> says there should be a separate user adding system that runs as  
>>> root and
>>> just processes validated requests from apache to add users.
>>
>> Separate user adding system? run as root? kinda like the
>> useradd.apache.ldap script perhaps? ;)
>
> Perhaps, but spawned by a separate system (daemon? cron job?) that  
> isn't
> running as apache. As I said, I'm being paranoid, but I intuitively
> don't like the idea of apache doing the root work.
>
>> Validated how exactly?
>
> By passing on the signup slip user/pass pair possibly.

The root problem here is apache being able to add users, thus any  
person that can cause stuff to be run as apache can in theory add users.

As long as we allow users to signup though a website form there is no  
way to close this hole. Its a measured risk. Sudo is a tried and  
tested method of providing limited root powers for such things.

>>> My lazy self
>>> says we should just implement the shell script in a php and use  
>>> one of
>>> those crazy php su systems to get root instead of using sudo. I'd  
>>> like
>>> to hear more opinions of how to do this in the least kludgy way  
>>> possible.
>>
>> Seriously, why?
>
> Because kludges are bad? More flexibility? Reduce the amount of places
> the ldap password is kept in plain text, perhaps... Previous
> conversations have certainly led me to believe the current system  
> needs
> an overhaul.

There is no reason the useradd.apache.ldap script could not load the  
password in from /etc/ldap.secret i was simply in a rush when i threw  
it together.

Sure it could (and indeed should) be more flexible, but that's a  
trivial change at this level, the major lapses in sanity are all  
within the higher up stuff, input validation, database, and such.  
Equally most of the inflexibility stems from higher up the chain.

>
>> What's wrong with using sudo like the current system?
>
> See above. I'm probably just being paranoid/careful, and that's why I
> asked for comments. But if you're sure that the current system's
> security is sturdy enough and doesn't need to be improved on then  
> that's
> my concerns put to rest and less work for me to do.

Its as secure as it can be whilst we allow users to register using a  
web form, In my view its an acceptable risk. Plus there is enough  
reporting/logging around the execution of the member adding stuff  
that we have a audit trail should somebody attempt to exploit it.

--
Chris Jones, SUCS Admin
http://sucs.org






More information about the Devel mailing list