On 12/19/2007 07:10 AM, "Ansgar -59cobalt- Wiechers"
<email@hidden> wrote:
>> Christ, it's like getting your leg humped by a chihuahua.
>
> Don't like me gnawing at your ankles? Give proof for the claims you
> make. Don't ever think you're so high and mighty I'd let you get away
> without.
Hypocrisy much? Show me the proof of your claims.
>
>> But, since you haven't stumbled on the obvious:
>>
>> /var/spool/cups
>> /var/spool/PDFMaker
>>
>> Hmm...lots of temp files created by user processes. Unencrypted.
>> Containing useful information to an attacker.
>
> Point. I forgot about print spools. A way to deal with this might be to
> create cups and PDFMaker directories in /tmp and make /var/spool/cups
> and /var/spool/PDFMaker symlinks to the respective directories in /tmp.
Yeah...now you're modifying /var too. That's a real easy one to implement on
a few thousand machines.
>
>> /var/log. Unencrypted.temporary.data.about.user.processes.
>
> FileVault does not protect protect processes.
> FileVault does not protect data stored outside the FileVault.
You said that there's no user temp data stored outside of ~/ and /tmp.
Welcome to being wrong. That sting you feel is your pride deflating. You'll
get over it.
>
>> /var/db. Not strictly temp data, but damned useful, filevault or not.
>
> FileVault does not protect data stored outside the FileVault.
>
> The only potential issue I can see here is Spotlight when configured
> improperly.
The only issue you can see in /var/db being unecrypted is SPOTLIGHT? Do you
actually KNOW what's stored in there?
>
>> /var/samba/gencache.tdb. That's a wealth of information about a network
>> right there, including all kinds of useful IP addresses, like the IP
>> addresses of your domain controllers.
>
> FileVault does not protect data stored outside the FileVault.
>
> Do you get it already? If not I'll repeat it once more just for you:
>
> FILEVAULT DOES NOT PROTECT DATA STORED OUTSIDE THE FILEVAULT.
Your words:
"- Except for swap and /tmp there are no other places where one would
expect user temp files to be created."
" And it also looks like you can't name a location outside $HOME and /tmp
where a user's temporary files would be created."
Gencache.tdb is created by user actions during a login. Suck it up princess,
you're wrong, because your definition of user temp files is FATALLY narrow,
and your "solutions" for fixing it are fragile at best. There are all kinds
of places outside of $HOME and /tmp where user temp files are created. Just
admit you're wrong and move on.
>
>> Filevault all you want. With the information I can pull out of /var, I
>> can delete your home directory and still come out ahead, infosec wise.
>
> That's entirely besides the point. The question is: will you be able to
> somehow access data that was stored inside the FileVault? (And I'm not
> talking about the user's desktop wallpaper or keyboard layout.) If the
> answer is "no", then FileVault did exactly what it was designed to do.
> Period.
That was never the issue. The issue was your claims, incorrect, that there
are no user temp files created outside of $HOME and /tmp. Wait, let me quote
you again, because you know what? Beating a chihuahua is fun:
"- Except for swap and /tmp there are no other places where one would
expect user temp files to be created."
" And it also looks like you can't name a location outside $HOME and /tmp
where a user's temporary files would be created."
>
> FileVault was never designed to protect every kind of data on the
> system. And I don't recall anyone having claimed it would. Yes, even
> with FileVault an attacker may still be able to swipe useful data from
> the machine. However, he will *not* be able to swipe the data that was
> stored in the FileVault.
You also claimed it prevented data leakage...well, no, not really.
>
>> Anything else? Lots of temp files, lots of user temp files, lots of
>> caches. All there for the taking.
>
> We were talking about FileVault and how to prevent a user's data from
> leaking out of it. Not every cache or temp file will lead to leakage of
> a user's data. Up to now we have swap, /tmp and print spools as
> potential leaks, and I explained how that can be dealt with.
That's not what you saaaaaaaid:
"- Except for swap and /tmp there are no other places where one would
expect user temp files to be created."
" And it also looks like you can't name a location outside $HOME and /tmp
where a user's temporary files would be created."
I bet you're REAL glad you brought this back up again, aren't you. Feeling
good? Feeling happy? How'd that work out for you.
> Unless there are more potential leaks FileVault is reasonably secure. No, the
> other examples you mentioned do not count as I already explained, and
> /var/tmp doesn't count either, because it's used for a different kind of
> temporary data.
Oh, actually they do count in the real world. Print spool files, samba
caches, they count, and they count well. You sticking your fingers in your
ears, and yelling "ONLY THE FILES I SAY COUNT ACTUALLY COUNT" does not in
fact change reality. The fact that there are workarounds doesn't change that
reality either. You can work around almost anything, but that's not the same
as the default setup. In a default setup, without hackery, there ARE in fact
user temp files outside of $HOME and /tmp that file vault can't do diddly
for, and in fact, because of that, we see that there is in fact, leakage in
a FV system.
>
> And my original point of FileVault doing on-the-fly encryption still
> stands.
It's not consistent (not that you've offered definitive proof, but having
done my own work, I don't actually need you to. Funny though, how for all
your ranting and raving and demands that *I* provide proof of my claims, you
seem to have forgotten to do so yourself. Wait, let me guess, you have a
Very Good Reason as to why you aren't required to. People like you always
do.), in fact, it can't be. It can only do encrypted writes to the FV image.
Everything outside of that won't be encrypted. There's some indication that
even if you use encrypted swap, if a mobile system goes into safe sleep, the
sleep image is encrypted, but the encryption key is written out in the
header. (this is from <http://crypto.nsa.org/vilefault/23C3-VileFault.pdf>,
take it for what it's worth, which in leopard, may very well be nothing)
There're potential issues with filevault and portable home directories. If
the server side of the PHD isn't encrypted, (and I don't recall if they
are), then writes to the server during synchronization would not be
encrypted either.
FireWire is actually astoundingly insecure and quite simple to pull data
from, although at that point, things are getting a little esoteric, and edge
case-y.
So it does on the fly encryption when writing to $HOME, which still doesn't
cover the significant amount of userspace - created temp data written to
places outside of $HOME...of which there is quite a bit.
--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden
This email sent to email@hidden
