Minutes of SRCF Committee meeting of Saturday 2010-02-20

Venue: Starbucks Market Square

Time: 10:00-11:39

In attendance: Daniel Thomas (drt24, PR Officer), Malte Schwartzkopf (ms705, Chairman), Fergus Ross Ferrier (frf21, Junior Treasurer)

Apologies: Han-Ley Tang (crisis (via Malte, received 04:24))

Minutes taken by Daniel Thomas.

Absence of Sysadmins from the meeting

Password Harvesting + ToS violation Incident involving Oliver Stannard (os289), Matvey Soloviev (ms900) and Frankie Robertson (fr272)

  1. (10th Feb, 11:39) os289 logs in from

  2. os289 su's to ms900

  3. ms900 runs a password search (terminating it early)

  4. ...and finds, alas, an unimportant world-readable password in mas90's home directory (that password won't provide access to anything on the SRCF)

  5. (11:49) fr272 logs in from the same IP address,

  6. fr272 immediately re-reads the file containing the password then tries to su to mas90 (Malcolm's unprivileged account) and then mas90-adm (Malcolm's privileged sysadmin account), presumably using that password -- unsuccessfully of course.

  7. fr272 then runs another (simpler) password search in /home (terminating early again)

  8. ...and then starts reading through various PHP files found by the search

  9. ...and then successfully logs into MySQL several times using one society's account (CUPS, the Physics society - Their password has been reset and the account admins have been notified)

  10. fr272 then starts the search again in the background, redirecting to a file in his home directory

  11. fr272 then copies one other user's data into his home directory for good measure, and logs out

  12. fr272 logs back in from Girton ( at 21:52 and 23:09 to check on the status of his backgrounded search

  13. Another user noticed the search running when looking at the output of 'top' this morning (2010-02-11), and notified the sysadmins

World-readable /home - security risk?

Michael Darling's (md510) proposal to improve user's security

"To: committee@srcf

Subject: World-readable /home - security risk?


I'd like to put forward the issue of /home being world-readable by default. It seems there's been at least two cases of people running password searches on said open directories, and thus being banned as a result. I'm not arguing in terms of rules, but evidently this kind of thing does happen, so you can't just trust your users not to do anything wrong.

The problem I can see is that there’s no foreseeable reason to allow every user to see every other user’s files by default. Many society admins hosting on the SRCF doubtless don’t have enough technical expertise to know how to make stuff private, and so they’re at risk just by signing up for an account and uploading some files. I can’t imagine it being too difficult to implement either – a default install of apache won’t mind /home having 711 permissions (which is what I’m doing on my own personal server, with multiple users and vhosts, so can attest to it working). Failing that, having a 755 public_html and a 711 ~ would do, though would take a little more effort to implement. At the moment it seems just like a security risk, though I’m open to hearing why the current setup helps.



Response from sysadmins:

This particular solution has not been discussed at length because it's achieves nothing.
Making /home 0711 helps nothing; guess a CRSID and you've got past the "security".

Making each person's ~ 0711 (well, presumably 0771 for society accounts) is even worse. You can still index within public_html, which is where the world-readable passwords will be.

Basically, this is a non-starter; Apache must be able to read public_html, so unless Apache gets special rights (very hairy) everyone else must be able to as well.”

Cron job that looks for world readable files containing passwords?

Appoint Nick Stenning (nhs27, borior) as a sysadmin?



Meeting closed at 11:39

Actions arising