>>> I would have recommended a USB memory stick, myself.
>>
>> That only works if you *have* a USB stick. :-P
> 
>     If the files are that important, I'm sure he can buy one. They're 
> cheap.

Not in 20 minutes flat, no.

[Recall that we're in the middle of nowhere.]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> I've been saying that for *years*.  I'd get questions every once in a
>> while from managers wanting to keep their IT people out of files on the
>> network.  My first question was always "why don't you trust your IT
>> admins?".
> 
> I see a similar question on the SQL forums all too often.
> 
> How do I prevent the database administrators from seeing the
> views\procs\data in a database?
> Simple answer: You don't

Er... like, WTF?

The sysadmin has absolute power. They can do *anything*. Up to and 
including completely replacing the entire OS with one that will allow 
them to do whatever they want. You *cannot* prevent somebody who wields 
that kind of power from doing whatever the hell they want - so they had 
*better* be worthy of such trust!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Fri, 04 Jul 2008 09:03:49 +0100, Invisible wrote:

> Er... like, WTF?

Well, it's not that difficult to understand - this is what happens when 
technically incompetent people decide how to implement policy.

From what you've seen, you've witnessed some of this behaviour firsthand.

That said, there are ways, for example, to prevent a sysadmin from seeing 
files in a filesystem.  File-level encryption, for example - or directory-
level.  With Linux, this is almost so simple as to be trivial using encfs 
(of course with requisite Linux-foo skills).

But ultimately, yes, you're right - a sysadmin needs to be worthy of the 
trust placed in them.  That's rule #1.  They may not be able to get at 
the encrypted files, but the sure could still nuke them.

Jim

Post a reply to this message

Jim Henderson wrote:

> Well, it's not that difficult to understand - this is what happens when 
> technically incompetent people decide how to implement policy.

What's technical? The sysadmin is, by definition, God. You can't stop 
God from doing things. QED. You don't need to know a thing about 
technology to comprehend this extremely simple principle.

> That said, there are ways, for example, to prevent a sysadmin from seeing 
> files in a filesystem.  File-level encryption, for example - or directory-
> level.  With Linux, this is almost so simple as to be trivial using encfs 
> (of course with requisite Linux-foo skills).

Yeah, sure, but the *key* has to be stored somewhere. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> That said, there are ways, for example, to prevent a sysadmin from seeing 
>> files in a filesystem.  File-level encryption, for example - or 
>> directory-
>> level.  With Linux, this is almost so simple as to be trivial using encfs 
>> (of course with requisite Linux-foo skills).
>
> Yeah, sure, but the *key* has to be stored somewhere. ;-)

Just use Windows built-in encryption, that works off your login password 
doesn't it?  Even if the admin can remotely log in, they won't be able to 
read your encrypted files unless they somehow get your password.

Or just zip things up with a password.

Post a reply to this message

>> Yeah, sure, but the *key* has to be stored somewhere. ;-)
> 
> Just use Windows built-in encryption, that works off your login password 
> doesn't it?

Wouldn't that mean that every single time you change your login 
password, all of your files instantly become unreadable?

What I suspect happens is that it's actually asymmetrically encrypted, 
and the decryption key is encrypted with your login password. That means 
if you change your login password, you gotta change one thing - the 
encrypted decryption key - and all your stuff is still accessible.

> Even if the admin can remotely log in, they won't be able 
> to read your encrypted files unless they somehow get your password.

Do you know what the "use reversible encryption" tickbox in AD does? >:-D

> Or just zip things up with a password.

Now *that* could actually work. Especially if you use that password for 
nothing else. Now all the sysadmin needs to do is install a keylogger... 
oh, wait... ;-)

Anything you can do, the sysadmin can undo. He controls the machine 
you're using. You can't win. [Theoretically at least. In practice you 
can make it too hard to be worth the bother.]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Fri, 04 Jul 2008 10:22:12 +0100, Invisible wrote:

> Jim Henderson wrote:
> 
>> Well, it's not that difficult to understand - this is what happens when
>> technically incompetent people decide how to implement policy.
> 
> What's technical? The sysadmin is, by definition, God. You can't stop
> God from doing things. QED. You don't need to know a thing about
> technology to comprehend this extremely simple principle.

You'd think so, but clearly the evidence suggests it's not that obvious - 
otherwise they *would* have grasped it.

>> That said, there are ways, for example, to prevent a sysadmin from
>> seeing files in a filesystem.  File-level encryption, for example - or
>> directory- level.  With Linux, this is almost so simple as to be
>> trivial using encfs (of course with requisite Linux-foo skills).
> 
> Yeah, sure, but the *key* has to be stored somewhere. ;-)

The key is in my head.  If you can extract my password from my brain, 
you'll have proven that you *are* God.

Jim

Post a reply to this message

On Fri, 04 Jul 2008 11:40:39 +0200, scott wrote:

> Just use Windows built-in encryption, that works off your login password
> doesn't it?  Even if the admin can remotely log in, they won't be able
> to read your encrypted files unless they somehow get your password.

If the built-in encryption keys off the login password only (ie, the 
login password just unlocks the encryption key), then as an admin, you 
just have to change the user's password.  If there is a weakness to 
encfs, that's what it is as well - the key is stored in an encrypted 
keystore that's locked with the password (so I understand).  But it's not 
the login password, so if you root my machine and change my login 
password, you're still not getting at the encrypted files.

Still, you could use something like truecrypt to get around that if it's 
that critical the data be unreadable without the key.

> Or just zip things up with a password.

That's a pain to use, though - used to do that back in the early 90's - I 
even wrote a wrapper program that took a randomization key and generated 
a 256-character pseudo-random pkzip password for that purpose.  Always 
had to purge deleted files from the system after working on the code a 
bit (old NetWare server, 2.15 and then 3.11).

If you don't securely wipe the unpacked files after you're done with 
them, then they can be recovered from the drive with relative ease.  And 
while you're using them, the files are exposed.

Jim

Post a reply to this message

> What I suspect happens is that it's actually asymmetrically encrypted, and 
> the decryption key is encrypted with your login password. That means if 
> you change your login password, you gotta change one thing - the encrypted 
> decryption key - and all your stuff is still accessible.

Yeh that's probably more like it - I just know that if you forget your login 
password you can never get back your encrypted data.

>> Even if the admin can remotely log in, they won't be able to read your 
>> encrypted files unless they somehow get your password.
>
> Do you know what the "use reversible encryption" tickbox in AD does? >:-D

AD? I normally tick the box in "encrypt" box in the file properties window.

> Now *that* could actually work. Especially if you use that password for 
> nothing else. Now all the sysadmin needs to do is install a keylogger... 
> oh, wait... ;-)

You can outsmart a key logger by simply typing in part of your password, 
then clicking the pointer to move the cursor, and typing in another bit, 
click again etc.  On my bank log-in I have to choose the numbers with the 
mouse, exactly to avoid keyloggers working I guess.  But I guess then the 
admin can install a mouse and screen logger too ;-)

Post a reply to this message

> Yeh that's probably more like it - I just know that if you forget your 
> login password you can never get back your encrypted data.

Oh, you need only guess what the password is. ;-)

>> Do you know what the "use reversible encryption" tickbox in AD does? >:-D
> 
> AD? I normally tick the box in "encrypt" box in the file properties window.

Active Directory. (The thing Windoze now uses to manage network user 
accounts.)

There's a tickbox that allows legacy systems to interoperate with 
Windoze. Legacy systems that require you to send the user's password in 
the clear. What this option basically does is allow the sysadmin to know 
what each user's password actually is. (Normally this isn't possible - 
the server only stores a hash *of* the password, not the password itself.)

> You can outsmart a key logger by simply typing in part of your password, 
> then clicking the pointer to move the cursor, and typing in another bit, 
> click again etc.  But I guess 
> then the admin can install a mouse and screen logger too ;-)

...exactly.

And if that doesn't work, a kernel-level debugger can see every octet of 
data in the machine's main RAM and swap file. There really is no escape.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message