OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: about the complexity estimate
From: Marc Esipovich (marcmucom.co.il)
Date: Wed Jun 07 2000 - 22:38:01 CDT

On Thu, Jun 08, 2000 at 12:17:52AM +0100, Antonomasia wrote:

[big big big snip]

>
> Part of the reason was to get a measure of people's estimated coding
> speeds. Rather than just lines per day I was looking for the useful
> product per day as the number of lines varies with coding style.
>
> What eventually happened is that the accounts were wanted to be
> be distributed over a number of boxes so I wrote 3 programs.
> Total of 1100 lines in 4 days plus 2 days of self-audit and docs.
>
> 1) client (setuid root)
> This packages a request and sends to the server
> acts on reply from the server by possibly adding
> a local account to match ones made remotely -
> this keeps the 2 passwd databases in sync.
> 2) server (run by root from inetd)
> This receives a request which might be for adding a
> new account - if all is OK it gets added.
> 3) trivial passwd(1) wrapper (setuid root)
>
> Loads of checks (whitelist username characters, lengths, UIDs ...)
> and file locking and logging are involved. setreuid() was used to
> drop privs temporarily for the copying of /etc/skel. I didn't drop
> privs permanently with setuid() because that would make it impossible
> to unlock the passwd file near the end unless I used a child process.
> Because only unique new UIDs are accepted the new user in question is
> not able to signal and leave files locked during that section - I have
> assumed that there is not a stray process active from a deleted account.
>
> The server used ident/auth (internally) to check that the client userhost
> was who he said. This can be spoofed of course - likewise the reply from
> the server to the client can be spoofed to ask that to add a user.
> Because the user accounts are only added with th password field of "*"
> local access is needed to set the password so an attacker doesn't seem
> to gain by doing this. A root-owned config file tells the server the
> "userhost" definitions permitted to use the scheme.
>

        Security of your code aside for a minute, Where's the real authentication?
        You obviously need something secure from a cryptographic point of view.
(you don't want imposters going around adding users, changing passwords...)

 Bye,
        Marc.