Minutes of SRCF Committee meeting of Saturday 2010-02-20
Venue: Starbucks Market Square
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
Malcolm couldn't come as he was involved (since those responsible tried to access his account) and Kristian is currently in Dubai, Ian is in Scotland, Ross is in Sweden. Others are busy.
We need more Sysadmins.
The recent issue with spam being sent from the SRCF made this abundantly clear.
Recent flamewars on #srcf have reduced its usefulness as a communication medium as some sysadmins and committee have ceased to read it as a result.
[For this reason I (drt24) may apply /kick et al. in future.]
Password Harvesting + ToS violation Incident involving Oliver Stannard (os289), Matvey Soloviev (ms900) and Frankie Robertson (fr272)
Daniel summarised what had happened based on discussions had and the recollection of the following information from sysadmins.
(10th Feb, 11:39) os289 logs in from 188.8.131.52
os289 su's to ms900
ms900 runs a password search (terminating it early)
...and finds, alas, an unimportant world-readable password in mas90's home directory (that password won't provide access to anything on the SRCF)
(11:49) fr272 logs in from the same IP address, 184.108.40.206
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.
fr272 then runs another (simpler) password search in /home (terminating early again)
...and then starts reading through various PHP files found by the search
...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)
fr272 then starts the search again in the background, redirecting to a file in his home directory
fr272 then copies one other user's data into his home directory for good measure, and logs out
fr272 logs back in from Girton (220.127.116.11) at 21:52 and 23:09 to check on the status of his backgrounded search
Another user noticed the search running when looking at the output of 'top' this morning (2010-02-11), and notified the sysadmins
Daniel has had discussions with both Frankie and Matvey.
Oliver Stannard (os289) only provided access to the SRCF
Matvey's actions were essentially equivalent to Ximin Luo's actions
Frankie's actions were worse.
Fergus suggested that the same actions should be applied to both of them as were applied to Ximin.
Daniel suggested that Frankie's actions were worse and so he should have his membership terminated and be allowed to reapply after two years.
Malte suggested that it was better to apply the same actions to both as to Ximin as this is in-line with precedent and shows that we are being completely fair.
Oliver Stannard did not appear to have been involved and the other two have admitted to all actions.
He should have his account reinstated and be given a stern warning to be more careful who he allows to su from his account in future.
Vote on this motion: Motion passed unanimously
As per standard procedures, the matter was reported to CERT
Matvey and Frankie will both have the same punishment applied: their membership will be terminated and they will be allowed to reapply for membership at the start of the next academic year (subject to the approval of the committee at the time).
Vote on this motion: Motion passed unanimously
Questions to be resolved:
Are failed su attempts emailed to sysadmins?
Has Ian emailed CERT?
What is CERT's response.
World-readable /home - security risk?
Michael Darling's (md510) proposal to improve user's security
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:
solution has not been discussed at length because it's achieves
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.”
This indicates there are good technical reasons why Michael's proposals do not work in practice.
Richard Whitehouse (rjw201) has indicated that he may submit a more complicated solution that might work. This involved having twice as many groups such that there are socname-apache and crsid-apache groups which have the apache user in them as well as the normal users. He will submit a proper proposal in due course.
Fergus suggested it might be possible to do something using mod_suexec involving apache serving files as a different user and group
We should ask sysadmins to investigate possible solutions
Cron job that looks for world readable files containing passwords?
Concerns about false positives
surely people will ignore them
We would need a .password_ignore to deal with false positives (or people would be spammed every week).
We have had 4 detected cases of people searching for passwords in the past two years.
We should politely request that the sysadmins write a script to deal with this problem.
Our next email to users should remind them to check that any files they have containing passwords are not world readable.
If such a script is written we should not publicise the fact that we have done this
If we did we would have problems with false negatives as people might rely on it finding any world readable passwords that they might have.
Such as script would not be equivalent to what Ximin did as it would not quote the password in the file and would not cc sysadmins (or anyone else) only the society or user in question and it would quote only the file name not the password.
This solution doesn't need to be perfect but there should be something
Ask the sysadmins to implement this basic script as a matter of semi-priority as a possible (imperfect) solution preferably before the AGM and to investigate a more complicated or complete system to replace it as time allows.
Motion Passed unanimously.
Appoint Nick Stenning (nhs27, borior) as a sysadmin?
Kristian has spoken to him and approves of his becoming a sysadmin however as yet none of the other sysadmins have.
Approve of Nick Stenning becoming a sysadmin pending approval of a majority of the sysadmins (which should be sought as a matter of urgency).
Motion passed unanimously.
AGM 18:00 on 9th March.
We must ensure that there are no uncontested positions at the AGM
We should encourage potential sysadmins to come to the AGM (committee/sysadmins can talk to them at the curry afterwards about becoming a sysadmin).
Encourage potential committee people to come to the AGM and to stand for positions.
We will announce the sale of old servers at the AGM as we have the blessing of Third Light to sell them (It should be noted that Third Light are awesome).
We may announce upgraded desktop service at the AGM if the sysadmins have time to implement it by then.
Should srcf.net be on the agenda of the AGM?
Do we need to book anything?
Work out where we are going?
No: Ask the AGM.
Malte noted that the place we went to last year was no particularly good or cheap.
Meeting closed at 11:39
Obtain more sysadmins
Ensure that there are no uncontested positions at the AGM, encourage potential committee people to stand and potential sysadmins to come (in order to discuss this with them over curry afterwards)
Finish the agenda of the AGM this weekend.
Ensure that #srcf is a useful communication channel.
Email Oliver Stannard (os289) informing him that his account has been reinstated and that he should take care who he allows to su from his account in future
Email Matvey Soloviev (ms900) and Frankie Robertson (fr272) informing them that their membership has been terminated and they will be allowed to reapply for membership at the start of the next academic year (subject to the approval of the committee at the time)
Reinstate the account of os289 (as a matter of priority)
Agree on whether Nick Stenning should be a sysadmin and if agreement is reached appoint him as a sysadmin (preferably before the AGM)
Please could a basic script to inform users of world readable password files be implemened as a matter of semi-priority as a possible (imperfect) solution preferably before the AGM and a more complicated or complete system to replace it be investigated as time allows.
Inform the committee as to whether failed su attempts are emailed to the sysadmins.
Please could possible solutions to reducing the use of world readable permissions on user files be investigated.
Inform the committee as to whether the CERT have been emailed and what their response (if any) is.