|
Grex > Coop > #300: Discussion of staff viewing user data. | |
|
| Author |
Message |
| 10 new of 18 responses total. |
tsty
|
|
response 9 of 18:
| 
Dec 13 16:59 UTC 2010 |
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.
|
richard
|
|
response 10 of 18:
|
Dec 19 18:33 UTC 2010 |
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.
|
cross
|
|
response 11 of 18:
|
Dec 20 01:26 UTC 2010 |
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?
|
veek
|
|
response 12 of 18:
|
Dec 20 02:40 UTC 2010 |
resp:10 encryption won't solve the problem. root can always hack your
key. In root you trust :p
|
jep
|
|
response 13 of 18:
|
Dec 20 03:13 UTC 2010 |
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.
|
nharmon
|
|
response 14 of 18:
|
Dec 20 04:02 UTC 2010 |
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.
|
cross
|
|
response 15 of 18:
|
Dec 20 04:06 UTC 2010 |
Exactly.
|
richard
|
|
response 16 of 18:
|
Dec 20 04:34 UTC 2010 |
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?
|
nharmon
|
|
response 17 of 18:
|
Dec 20 07:22 UTC 2010 |
> 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.
|
veek
|
|
response 18 of 18:
|
Dec 20 08:24 UTC 2010 |
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.
|