On 2007-12-12 John C. Welch wrote:
> On 12/12/2007 14:21 PM, "Ansgar -59cobalt- Wiechers" wrote:
>>>> You missed the point. Without on-the-fly encryption data might leak
>>>> out of a FileVault due to a power outage (or someone pulling the
>>>> plug or whatever). The possible data leak would make it more than
>>>> just a "physical 'don't let people play in your login' issue".
>>>> On-the-fly encryption, however, takes care of this issue.
>>>
>>> How is it going to be an issue if they don't have access to your
>>> machine?
>>
>> If they didn't have access to the machine you wouldn't need any kind
>> of encryption in the first place.
>
> Incorrect. I can think of a half-dozen situations that call
> for/require FV - style encryption, regardless of physical access.
Then please enlighten me, because I don't.
[...]
>>> Because otherwise, you have problems in various temp directories
>>> that exist outside of the home directory. How do you deal with /tmp
>>> and others?
>>
>> Swap is already encrypted, and /tmp can be taken care of by something
>> like this:
>>
>> ----8<----
>> dd if=/dev/urandom bs=1000 count=1 | hdiutil create \
>> -encryption -stdinpass -ov -size $size -fs HFS+ -mode 1777 \
>> /private/temp.img
>> hdiutil attach /private/temp.img -noautoopen -mountpoint /private/tmp
>> chmod +t /private/tmp
>> ---->8----
>>
>> Which other temp directories outside /tmp and $HOME user-writable?
>> I'm not aware of any.
>
> Swap is not encrypted by default,
Neither is FileVault activated by default. I suppose I should've written
"swap can be encrypted", that would've been clearer.
> and are you going to do that for every user-writable directory on the
> box?
Only for those directories where a user's temporary files are created.
AFAICS that's just /tmp, if any.
> FV is really designed to solve one specific problem, it is not even
> close to a full-on encryption setup.
Protect the users' data from attackers who have physical access to the
box. So? On-the-fly encryption (and AFAICS that is what FileVault does)
still helps to prevent data from leaking. Which still is a good thing,
but comes at the price of reduced performance.
Yes, FDE would be better security-wise, but would have the exact same
cost.
> Secondly, there are many situations where you have data kept outside
> of the user home directory. Applications running local mysql
> databases,
Wow, you mean data that is stored outside a FileVault is actually not
encrypted/protected by the FileVault? Shocking news. Not.
> Adobe Acrobat likes to put things all over the place, etc. You going
> to encrypt all the cache files?
Like where? I'm still waiting for an example that's neither $HOME nor
/tmp.
> There's a lot of non-obvious stuff being written various places, you
> encrypting it all just in case someone steals your machine?
If the data were valuable enough? I most certainly would. Or maybe use
an appropriate solution to encrypt the whole volume or disk. However, I
don't know of an appropriate solution for OS X. If you have a
recommendation I'd be interested.
> At that point, just encrypt the whole thing at the EFI level and be
> done with it.
Yes. So? That's utterly besides the point. Do you believe on-the-fly
encryption would magically become less expensive when done for the whole
disk instead of a disk image?
> FV does exactly one thing...it encrypts your home directory so that
> when you're not logged on, the data *in that directory* is secured.
> It's even reasonably secure if someone else has physical access to
> that machine. There is absolutely no sense in encrypting the writes to
> that directory when it's mounted during login, barring a requirement
> of writing to an encrypted disk image.
There is a reason, and I already explained it several times.
> Once you expect it to do anything past that, you run into problems.
AFAICS FileVault actually does exactly what I'd expect it to do. How
else would it have the performance impact it does have?
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
