[EMAIL PROTECTED] tapota :
> Your statement about not checking if the Savane user account matches a
> pre-existing account on the system got me thinking that perhaps system
> accounts could be deleted by creating a Savane user with a username which is
> named the same as a system service user. Apparently somebody on the project
> thought similarly, because there is a list of names which are checked against
> in include/account.php in the account_namevalid() function.
>
> However, the method in which the list is implemented (simple regexp
> blacklist) guarantees there will be some missing names. While I was unable to
> register a user "root" on my test machine, I was able to register "apache".
> The list includes "httpd", "www", and "web", but not "apache" or for that
> matter any other specific web server one might run. It also checks for
> "mysql" but not "postgres" and so on.
>
> The best solution, as I see it, would be to replace the name check
> by scanning through /etc/passwd for the entered name and seeing if
> it is associated with a user number <500, since 500 starts userland
> users. Alternately the scan could just check for the name's
> existence in the file and deny creation if it is, assuming you might
> want to enforce no accounts could match on the database and local
> system.
We cannot follow that approach for the reason that nowadays, the
frontend is rarely running the same system than the backend.
> For the record I was able to create an account in Savane, and have the system
> automatically delete on the system, the system account "apache" on a Fedora
> Core 2 machine. On Red Hat or Fedora the default user for apache is
> apparently "apache". As you can guess, had I been attacking an installation
> on a similar machine, simply crashing Apache or the Kernel would cause the
> site not to come up again until an administrator could track down that
> "apache" is gone from the system.
I added apache on the defaut ignore list. But there is no way to
prevent with this function any system account to be attacked.
> Even worse than the fact that the system might temporarily not come back up
> is the behavior exhibited when the account is created. sv_users has this:
>
> my $password_home = $etc_password{$user}->[7];
> my $expected_home = GetUserHome($user);
> if ($password_home ne $expected_home) {
> `$usermod -d \"$expected_home\" $user` unless $debug;
> `mkdir -p $expected_home && rm -rf $expected_home` unless $debug;
> `mv -f $password_home $expected_home` unless $debug;
> print LOG strftime "[$script] %c ---- update $user /etc/passwd
> homedir\n", localtime;
>
> Which neatly takes the previous home directory and transplants it to
> where Savane's home directories are. Fedora's default home directory
> for "apache" is /var/www. So it decides to transplant the whole
> default site, cgi-bin and all, and then later delete it. I did it to
> my test machine. It would be potentially catastrophic to a
> production machine. It takes at most a few runs of the cron script.
>
> Furthermore, once apache is in the Savane system the only way to
> deal with that is to go into the database and remove it, update the
> blacklist, and carry on. Suspension or deletion will continue
> deleting the user from the local system, or if the Savane apache is
> assigned to a project then it's home directory will be permanently
> moved, which may or may not present a problem, I'm not sure. Either
> way it isn't pretty.
I see two ways of fixing the problem.
One would be to check whether ~/.savannah exists. The other is to
check to which group belong the user.
The more reliable way is probably the second one. We just check if the
user belongs to the group svusers (2500), we should be safe.
We could be even safer by checking if the uid is < 500 (accounts below
are usually only system accounts).
In both case, we let the account unmodified by sv_users (no ssh key,
no homedir modification, no removal).
>
> At any rate, this poses a danger to people running Savane on Fedora and using
> Apache, though there may be many like minded distros affected as well. Last I
> checked Debian runs apache as user httpd, so gna.org should be safe.
During the installation at Gna, we made sure to block in one way or another
any system account.
Other installation running on redhat-based system I know simply do not
gives unix accounts and so do not run this part of the backend.
--
Mathieu Roy
+
| Thalie : <http://yeupou.coleumes.org/>
| Clio : <http://clio.coleumes.org/>
| Uranie : <http://alberich.coleumes.org/>
| Euterpe : <http://kromaniaks.coleumes.org/>
+-----------------------------------------------------------+
