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
