Question about directory for Application Caches

  • Hello All,

    I'm a little unclear about this... maybe one of you has some ideas?

    Currently, the call to

      NSSearchPathForDirectoriesInDomain(NSCachesDirectory,
    NSUserDomainMask, NO);

    returns the path ~/Library/Caches. The FSFindFolder(...) call also
    returns the same thing. I noticed,
    however, that a number of other applications (including XCode itself)
    are using the cache directory
    returned by

      confstr(_CS_DARWIN_USER_CACHE_DIR, path, len);

    instead of the old directory in ~/Library. In the XCode 3.1 release
    notes it even mentions that it now
    uses this cache directory for "added security"... is there a
    recommended move to this directory
    structure under /var/folders? Or do we listen to the return value of
    NSSearchPathForDirectoriesInDomain(...)?

    I also noticed that NSTemporaryDirectory(...) returns the temp
    directory in /var/folders so I'm wondering
    if there is a move to put all discardable files back into /var (where,
    IMO, they belong anyway... but hey). So...
    do I use the result of the POSIX call or the Cocoa call? If Apple
    weren't starting to use the result of the
    POSIX call themselves, I wouldn't care, but I'm curious now... any
    thoughts?

    /Jason
  • Jason,

    See the following threads for some discussion of these issues:

    http://lists.apple.com/archives/Macnetworkprog/2008/Apr/msg00033.html

    http://lists.apple.com/archives/Xcode-users/2008/Jul/msg00283.html

    -Jeff

    On Aug 15, 2008, at 8:56 AM, Jason Coco wrote:

    > Hello All,
    >
    > I'm a little unclear about this... maybe one of you has some ideas?
    >
    > Currently, the call to
    >
    > NSSearchPathForDirectoriesInDomain(NSCachesDirectory,
    > NSUserDomainMask, NO);
    >
    > returns the path ~/Library/Caches. The FSFindFolder(...) call also
    > returns the same thing. I noticed,
    > however, that a number of other applications (including XCode
    > itself) are using the cache directory
    > returned by
    >
    > confstr(_CS_DARWIN_USER_CACHE_DIR, path, len);
    >
    > instead of the old directory in ~/Library. In the XCode 3.1 release
    > notes it even mentions that it now
    > uses this cache directory for "added security"... is there a
    > recommended move to this directory
    > structure under /var/folders? Or do we listen to the return value
    > of NSSearchPathForDirectoriesInDomain(...)?
    >
    > I also noticed that NSTemporaryDirectory(...) returns the temp
    > directory in /var/folders so I'm wondering
    > if there is a move to put all discardable files back into /var
    > (where, IMO, they belong anyway... but hey). So...
    > do I use the result of the POSIX call or the Cocoa call? If Apple
    > weren't starting to use the result of the
    > POSIX call themselves, I wouldn't care, but I'm curious now... any
    > thoughts?
    >
    > /Jason_______________________________________________
    >
  • On Aug 15, 2008, at 11:11 , Jeff Johnson wrote:


    Interesting... thanks, Jeff. So I guess the answer is for speed/non-
    sensitive cache
    data, maybe confstr(_CS_DARWIN_USER_CACHE_DIR, path, length) is the
    appropriate
    call... and maybe for data that may need to actually reside in the
    filevault, regardless of
    speed, the return value from the Cocoa call is more appropriate (~/
    Library/Caches)?

    I would like to point out a couple of interesting things, though...

    1) ~/Library/Caches is world writable too... so as long as you're
    logged in, even if you have
        your filevault armed, you're still gonna be somewhat vulnerable
    to cache attacks.
    2) The new temporary directory (returned the same by
    confstr(_CS_DARWIN_USER_TEMP_DIR,...)
        and NSTemporaryDirectory(...) is also outside the sphere of
    filevault /and/ your files there
        are not necessarily erased on log-out. I think it's cleaned up
    with the computer boots (although it
        may be deleted on shutdown, but I don't think so)... so if any
    sensitive information were written to
        the temp dir and the application relied on it being cleaned by
    the OS, that could be an issue too if
        your physical drive were compromised...

    Too bad these aren't sysctl variables that could be set if security
    were more important to the user
    than performance... I checked the darwin source and the directories
    returned by confstr(...) are
    hard-coded into libc...

    /Jason
  • On Aug 15, 2008, at 10:33 AM, Jason Coco wrote:

    > On Aug 15, 2008, at 11:11 , Jeff Johnson wrote:
    >
    >> Jason,
    >>
    >> See the following threads for some discussion of these issues:
    >>
    >> http://lists.apple.com/archives/Macnetworkprog/2008/Apr/msg00033.html
    >>
    >> http://lists.apple.com/archives/Xcode-users/2008/Jul/msg00283.html
    >
    > Interesting... thanks, Jeff. So I guess the answer is for speed/non-
    > sensitive cache
    > data, maybe confstr(_CS_DARWIN_USER_CACHE_DIR, path, length) is the
    > appropriate
    > call... and maybe for data that may need to actually reside in the
    > filevault, regardless of
    > speed, the return value from the Cocoa call is more appropriate (~/
    > Library/Caches)?

    That sounds reasonable.

    > I would like to point out a couple of interesting things, though...
    >
    > 1) ~/Library/Caches is world writable too... so as long as you're
    > logged in, even if you have
    > your filevault armed, you're still gonna be somewhat vulnerable
    > to cache attacks.

    This is incorrect, FileVault or not. Where do you get that idea?

    > 2) The new temporary directory (returned the same by confstr
    > (_CS_DARWIN_USER_TEMP_DIR,...)
    > and NSTemporaryDirectory(...) is also outside the sphere of
    > filevault /and/ your files there
    > are not necessarily erased on log-out. I think it's cleaned up
    > with the computer boots (although it
    > may be deleted on shutdown, but I don't think so)... so if any
    > sensitive information were written to
    > the temp dir and the application relied on it being cleaned by
    > the OS, that could be an issue too if
    > your physical drive were compromised...
    >
    > Too bad these aren't sysctl variables that could be set if security
    > were more important to the user
    > than performance... I checked the darwin source and the directories
    > returned by confstr(...) are
    > hard-coded into libc...
    >
    > /Jason

    Frankly, I've come to the conclusion that while FileVault is a nice
    idea in theory, there's just no way for the FileVault user to protect
    from developers -- whether Apple or third parties -- writing files to
    the wrong place. Thankfully, it seems that we're finally getting some
    full disk encryption solutions for the Mac. There is at least one
    already on the market (Check Point), and apparently others are
    working on it too (e.g., PGP announced something, but it's currently
    vaporware, perhaps to stop people from buying Check Point).

    -Jeff
  • On Aug 15, 2008, at 12:21 , Jeff Johnson wrote:

    > On Aug 15, 2008, at 10:33 AM, Jason Coco wrote:
    >
    >> On Aug 15, 2008, at 11:11 , Jeff Johnson wrote:
    >>
    >>> Jason,
    >>>
    >>> See the following threads for some discussion of these issues:
    >>>
    >>> http://lists.apple.com/archives/Macnetworkprog/2008/Apr/
    >>> msg00033.html
    >>>
    >>> http://lists.apple.com/archives/Xcode-users/2008/Jul/msg00283.html
    >>
    >> Interesting... thanks, Jeff. So I guess the answer is for speed/non-
    >> sensitive cache
    >> data, maybe confstr(_CS_DARWIN_USER_CACHE_DIR, path, length) is the
    >> appropriate
    >> call... and maybe for data that may need to actually reside in the
    >> filevault, regardless of
    >> speed, the return value from the Cocoa call is more appropriate (~/
    >> Library/Caches)?
    >
    > That sounds reasonable.
    >
    >> I would like to point out a couple of interesting things, though...
    >>
    >> 1) ~/Library/Caches is world writable too... so as long as you're
    >> logged in, even if you have
    >> your filevault armed, you're still gonna be somewhat vulnerable
    >> to cache attacks.
    >
    > This is incorrect, FileVault or not. Where do you get that idea?

    Oh my... I came to this conclusion because /my/ Caches directory was
    world-writeable. I checked
    another local account on my machine and that Caches directory was also
    world-writeable. Finally,
    I created a new account and checked, whereupon I discovered that it
    was read-write-exec only by
    the owner. Hmm... seems like some dumb application is messing with my
    Caches directory permissions...
    I'll have to check that out!

    Thanks again, J
  • On Aug 15, 2008, at 11:21 AM, Jeff Johnson wrote:

    > Thankfully, it seems that we're finally getting some full disk
    > encryption solutions for the Mac.

    Oops, I should have said full disk encryption of the boot volume,
    considering that I developed a full disk encryption solution for non-
    boot volumes!

    -Jeff
  • On Sat, Aug 16, 2008 at 3:33 AM, Jason Coco <jason.coco...> wrote:
    > 1) ~/Library/Caches is world writable too... so as long as you're logged in,
    > even if you have
    > your filevault armed, you're still gonna be somewhat vulnerable to cache
    > attacks.
    > 2) The new temporary directory (returned the same by
    > confstr(_CS_DARWIN_USER_TEMP_DIR,...)
    > and NSTemporaryDirectory(...) is also outside the sphere of filevault
    > /and/ your files there
    > are not necessarily erased on log-out. I think it's cleaned up with the
    > computer boots (although it
    > may be deleted on shutdown, but I don't think so)... so if any sensitive
    > information were written to
    > the temp dir and the application relied on it being cleaned by the OS,
    > that could be an issue too if
    > your physical drive were compromised...
    >

    Also consider the case that the user has a network home directory. If
    your caches are going to be very large and frequently accessed (off
    the disk), then there may be some performance penalties.

    Phil
previous month august 2008 next month
MTWTFSS
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Go to today