This item is for discussion about protocol for Grex staff looking at user's
data, specifically data that is protected from viewing by normal users.  What
are the circumstances under which staff should look at things?  Sometimes it's
legitimate; ie, if the user asks you to look at something, possibly even edit
one of his or her files (say, a shell startup file, if the user is having
problems with it).  On the other hand, reading someone's personal email is
clearly not all right under all but the most extreme circumstances (e.g.,
under court order or something like that).

The policy right now is vague; what should it be?

18 responses total.

  
 http://grex.org/staffnote/sun/privacy.xhtml  
  

  
form above:
  
"When staff does have to look at private information, the basic
  principle is to look as narrowly as possible."
  
which for valisdation p;urposes, and as cross noted HUNDREDS of times, i do.
  

I don't think we should be doing that.  Nor should we be reading any other
type of file --- even if it's world readable --- without good reason.

The way to do this without having any questions about privacy, is to
get permission from the user first.  I think it would be better to do
this than to assume reading private files is necessary.  If our current
process does not give contact information, that would be the place to
start, rather than assuming there is no other way to do things or trying
to justify such.

"You can read other people's files.  Don't."

resp:4 This is another useful thing about asking for an email address in
 newuser; that information goes into a log that can be viewed by staff 
without looking at the users' files.

The process that the board adopted several years ago was straight 
forward and didn't involve any reading of any files at all (except one's
 personal email).  It works as follows:

1. The user sends email to "porters@grex.org."  That email goes into a 
ticket tracking queue managed by the "RT" software.
2. One of grex's porters "takes" that ticket in RT and sends an email to
 the user asking, "How did you hear about Grex?" 3. The user responds
with, really, whatever he or she wants. 4. The porter runs "validate
user" at the Grex command line. 5. The porter "resolves" the ticket.

That's it.  No where in there does it talk about looking at users' files
 or anything else.  No where does it talk about proactively contacting 
users.  If people want to change this process, that's the type of thing 
that needs to be discussed publicly, especially if any of those changes 
involve looking at files that are protected by the user: even the .plan 
file (granted, newuser does say that staff can see that information, but
 staff still shouldn't be poking around in people's directories without 
their permission.  I'd say that even running "finger user" as root is 
qualitatively different).  Then again, none of porters on Grex who are 
not also staff members with root access have the ability to do that.

Speaking of directories, I don't think that staff should be "checking 
up" on users with unfamiliar login names, either.  There was an incident
 last week where I ran "w" and saw a staff member reading an unusually 
named file that I happened to know was a temporary file created by the 
"pico" editor.  Thinking that was odd, I ran "ps auxwwe" and looked for 
the staffer's "more" process, then saw that the PWD environment variable
 in ps's output showed that the file was in another user's home 
directory.  The file was world readable, but a quick scan showed that it
 contained email messages the user had composed to someone else.  At
that  point, I stopped reading, but the other staffer did not.

When I confronted him about it, I was accused of alternately running a 
key logger on his sessions (not true) or somehow snooping on his tty 
(also not true).  The other staff member then went on to say that he had
 seen this user with an unfamiliar - to him - login name and wanted to 
see who he was, so he looked in his home directory, saw these strangely 
named files, and became curious as to what they were, so he read them.

There are many things wrong with this scenario, in my mind.

First, despite the fact that these files were world-readable, they 
clearly contained personal communications: this was obvious upon the 
most cursory inspection.  At that point, regardless of how curious 
someone is as to *why* those files were there, they should have stopped 
reading them.  Unless there's some compelling reason to be reading those
 files, or unless specifically asked by the user, I claim that personal 
communications like that should be strictly *off-limits* for staff 
members, even if root access is not required to view them.  It's one 
thing to stumble on them, but once you determine what they are, stop.

Second, being a system administrator on a large timesharing system 
brings with it certain privileges: having root access basically gives 
you access to anything on the machine.  However, that also brings 
greater responsibility.  Because one has that access, one needs to be 
even more careful than a non-system administrator about respecting the 
privacy of users.  There needs not only to be good judgment, but also an
 air of responsibility when it comes to user data.  Reading people's 
files when you're on staff, unless you've got a real reason to, gives 
the air of being cavalier about privacy.  This is a good way to get the 
users not to trust the staff (particularly when it was so obvious that 
that's what was happening), and right now, we need to get more people 
interested in Grex.

For a long time, the staff has had an almost paternalistic attitude 
towards the system and users.  This was okay, in the sense that it was 
meant to protect the community, but that time is past.  It's not 1991 
anymore; we're swimming in the resources we once so lacked.  Snooping 
around looking for abuse is going to drive users away and isn't going to
 help anybody.  Let's not do it.

Finally, that's just not an appropriate way to learn.  If a staff member
 has a question about Unix, they can ask one of the more knowledgeable 
staffers.  They can do a web search.  They can post in the systems 
conference.  They can email the staff mailing list.  But reading user's 
email (by the way, by my cursory glance, there was nothing in those 
files that would give any indication as to why they had funny names; I 
knew the answer, because I know how text editors work) is not an 
acceptable way to learn.

Amen, Brother.

resp:6 Hmm; backtalk seemed to mess up the formating when I entered that
from Safari.  Weird.

  
re 8 / 6 ... lookis fin in putty.
  
re 2 / 3
  
 "When staff does have to look at private information, the basic
   principle is to look as narrowly as possible."

 which for valisdation p;urposes, and as cross noted HUNDREDS of times, i do.


#3 of 8: by Dan Cross (cross) on Sat, Dec 11, 2010 (08:31):
 I don't think we should be doing that. 


which is exactly why that difference of oopinion is on the next board meeting
agenda.
  
this is not apissing contest.
  

Simply limit root access to one staffer, or two at the most.  Not every
member needs root.  anybody that worried about staff reading their email
wouldn't use email on this kind of board anyway.  Or they'd use
encryption.  Actually couldn't an encryption routine be added, i.e.:

'would you like to encrypt this file? (y/n)'

If yes then the user is prompted to put in a password, the file is
encrypted and the only person who can de-encrypt it is the one who has
the password.  Then even staff couldn't read the files.

You really have no idea at all what your saying means, do you?  "Actually
couldn't an encryption routine be added...."  Really?  Seriously?  Do you have
any idea what you're saying?

resp:10 encryption won't solve the problem. root can always hack your 
key. In root you trust :p

re resp:11: Dan, it's not that bad a suggestion.  It's not practical but
that is not completely obvious.

Richard, encryption of all of a person's data means it would be fully
inaccessible to anyone who didn't know that person's password.  If
someone forgot his password, he couldn't get his data and neither could
anyone else.  Say you tie it to his login password, and he then changed
his login password.  He'd have to keep track of his original password
for all of the data he wanted to access, plus the new password.  Or he'd
have to decrypt and re-encrypt all of his original data.

If he forgets any of his passwords, the data encrypted with it can
*never* be read, by anyone, short of extremely unreasonable efforts.

So what data are we talking about?  The .plan information which is
optionally created, and optionally made public when you first log in? 
What's the point in creating that at all if it's encrypted?  Every file
which he saves?  In his home directory, or in system directories too? 
Conference data which is temporary?  Responses and items?  Does the user
enter a password *every* time he wants to view or change *any* data file?

E-mail?  Outbound mail which is encrypted is un-readable.  Inbound mail?
 *Which* inbound e-mail?  That which enters the system?  Except for the
headers, which are necessary to deliver it?  That which is stored in the
person's mailbox?  You'd have to rewrite the mail system for that?  Mail
stored in the user's home directory?  You'd also have to rewrite *all*
of the mail clients for that.

Keep in mind you're doing all of this in order to satisfy someone who
doesn't trust the roots.  No one else can read most of this data anyway.

re resp:12: No, veek, even root cannot read what your login password is
on a Unix system, let alone any encryption key you come up with on the
fly.  A system admin can see the saved encrypted string in the
/etc/security file, but seeing that is quite a lot different from
knowing the unencrypted string.

A system admin could modify sshd to record users' passwords. They could
also read encrypted e-mail by snooping terminal sessions if they went to
the effort of making the necessary modifications.

The point is the only reason for a user to think they have any privacy
on a system is by trusting the system admins to restrain themselves from
violating that privacy.

And without a clear directive from the board on what staff can and can
not look at, and a staff with a reputation of adhering to that
directive, it is impossible for users to have that sort of trust in Grex.

Exactly.

So then say the encryption password has to be inputted via an offsite 
email so that no record of it exists on the system.  There has to be a way 
for users to fully protect the privacy of their files even from root, if 
they are willing to accept the risk of not being able to access the data 
themselves if they lose the pw.  How else can you protect users from 
snooping roots like TS?

> There has to be a way for users to fully protect the privacy of their 
> files even from root.

Yeah, copy them to their damn computers.

resp:16 we don't know for sure if TS was snooping. 
--
Richard/Jep, re root and privacy of data, root can read all unencrypted 
data.. this includes decrypt-keys, logins, passwords whatever.

The best solution is to let clueless users know this. Awareness.. i 
mean jeeze! if the two of you didn't know this..

ONLY files encrypted on my home-box and copied to Grex will be 
unreadable by Grex-root so long as I don't ever store/transmit the 
decrypt key on/through Grex. Essentially, you'd be using Grex to store 
encrypted data without processing that data.

resp:13 sure he can and I suggest you use a password for Grex that is 
not used anywhere else (yahoo, bank etc). Storing hashes of passwords 
makes it difficult for a person who hacks into the box from instantly 
grabbing all user passwords. But once the hacker has got root, he could 
load a kernel driver to read passwords from memory as users login via a 
tty. Same thing with encrypted blahblah.. moment you type in a plain 
text decrypt key, root can help himself to that.

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss