On 2007-12-18 John C. Welch wrote:
> On 12/18/2007 12:43 PM, "Ansgar -59cobalt- Wiechers" wrote:
>> To sum up the results of our little dipute:
>>
>> - FileVault apparently *does* on-the-fly encryption.
>> - Except for swap and /tmp there are no other places where one would
>> expect user temp files to be created.
>> - On-the-fly encryption does help prevent data from leaking out of a
>> FileVault.
>
> 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.
> 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.
> /var/log. Unencrypted.temporary.data.about.user.processes.
FileVault does not protect protect processes.
FileVault does not protect data stored outside the FileVault.
> /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.
> /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.
> 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.
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.
> 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. 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.
And my original point of FileVault doing on-the-fly encryption still
stands.
Regards
Ansgar Wiechers
--
"Another option [for defragmentation] is to back up your important files,
erase the hard disk, then reinstall Mac OS X and your backed up files."
--http://docs.info.apple.com/article.html?artnum=25668
_______________________________________________
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