jayv.

Q: What level of journaling does the OS use?

Hi all,

 

I have been searching for a while now and while i can find clear documentation on Linux filesystem journaling i can not find anything on Mac OS journaling. I am trying to find documentation that shows (or some kind of command i can run to verify) what data is included in the Mac OS Journaling. Does it work like most? metadata only, or does it include file data as well?

 

For example when a file is securely erased, can information regarding that file be recovered from the filesystem journal.
Any pointers to some kind of documentation from Apple would be welcome. I have read Apple's website on what journaling is, does and why it's important but it does not provide details.

 

Thanks,

Jay

Posted on Apr 20, 2013 8:23 PM

Close

Q: What level of journaling does the OS use?

  • All replies
  • Helpful answers

Page 1 Next
  • by Eric Ross,

    Eric Ross Eric Ross Apr 20, 2013 8:56 PM in response to jayv.
    Level 6 (11,681 points)
    Apr 20, 2013 8:56 PM in response to jayv.

    Take a look at this link, http://support.apple.com/kb/HT2355

  • by jayv.,

    jayv. jayv. Apr 20, 2013 8:57 PM in response to Eric Ross
    Level 4 (1,290 points)
    Apr 20, 2013 8:57 PM in response to Eric Ross

    Hi Eric, thanks for the reply. That is the article (and only one from Apple) i found. But it doesn't give me the details i need.

  • by etresoft,Solvedanswer

    etresoft etresoft Apr 20, 2013 9:05 PM in response to jayv.
    Level 7 (29,056 points)
    Apr 20, 2013 9:05 PM in response to jayv.

    What details do you want? I hesitate to say "need", because I seriously doubt that you truly need them. OS X is not Linux, nor even similar to it. Whatever assumptions you have from Linux can be safely disposed of before starting.

     

    If you are just curious, you can look at this old Tech Note. It is officially retired although much of it is still relevant. It is sufficient to satisfy any curiosity.

     

    If you need it this information to be 100% accurate because you indent to actually do something on that level, then don't.

  • by jayv.,

    jayv. jayv. Apr 20, 2013 9:13 PM in response to etresoft
    Level 4 (1,290 points)
    Apr 20, 2013 9:13 PM in response to etresoft

    Thanks for the reply etresoft. I both want and need that information. Dealing with what most of my clients consider to be very sensitive information and though i do my part in securing it while in use i want to make sure i do my part in safely deleting it. So if the journal holds any information that could lead to the reconstruction of a file i securely erased i need to know. Thank you for the link to that article, i'll be reading that right away. I will post back after reading it to either close this post or ask for more information if it did not answer my question.

     

    EDIT: the first paragraph already answered my question: "The journal is used only for the volume structures and metadata". Unless i can find documentation that shows otherwise i have to assume this is the way the current versions of the OS use journaling as well.

  • by etresoft,

    etresoft etresoft Apr 20, 2013 9:24 PM in response to jayv.
    Level 7 (29,056 points)
    Apr 20, 2013 9:24 PM in response to jayv.

    That's what File Vault is for.

  • by jayv.,

    jayv. jayv. Apr 20, 2013 9:27 PM in response to etresoft
    Level 4 (1,290 points)
    Apr 20, 2013 9:27 PM in response to etresoft

    I have found filevault to be extremely unreliable when reinstalling a system and restoring a backup. As i use multiple hard drives i had those encrypted and my external drive as well to make sure it was all properly protected. I know better now, encrypting whole drives both internal or external through the Mac OS is unreliable at best.

     

    Thanks for your help

  • by BobHarris,

    BobHarris BobHarris Apr 21, 2013 4:30 AM in response to jayv.
    Level 6 (19,272 points)
    Mac OS X
    Apr 21, 2013 4:30 AM in response to jayv.

    The first article encouraged you to backup your data, implying journaling was not protecting your data, and that was your responsibility.

     

    The Darwin sources are available, which I think include the file system, so you can always examine the code.

     

    My experience with Journaled file systems (developing them at other companies) is that Journaling only refers to metadata. The developers are only worried about fsck (file system check) recovery time on huge volumes (as the first article as stated).

     

    But if the data is extremely sensitive you should work on solving some form of whole disk encryption. File Vault 2, PGP Whole Disk Encryption, or TrueCrypt. Because secure erase only tries to protect data removed, but if Mac or external disks are lost or stolen, all the unerased data is there for all to see.

     

    If for some reason in encrypted files are OK, also make sure encrypted pagefile is enabled.  I think it is by default.

     

    And I'm assuming you have the always use secure erase enabled, so any temp files used by an app get securely erased as well?

  • by etresoft,

    etresoft etresoft Apr 21, 2013 6:05 AM in response to jayv.
    Level 7 (29,056 points)
    Apr 21, 2013 6:05 AM in response to jayv.

    File Vault is very reliable. If you are having trouble with it, I suggest starting a new thread to address that.

  • by MrHoffman,

    MrHoffman MrHoffman Apr 21, 2013 6:46 AM in response to jayv.
    Level 6 (15,612 points)
    Mac OS X
    Apr 21, 2013 6:46 AM in response to jayv.

    If the attackers have access to the journal contents, you're probably already toast.

     

    Have real physical security.  Even better, don't have and don't expose the data.  Use FileVault 2.  Use secure passwords.  Secure your backups.  Encrypt application data. 

     

    Layer on secure delete or use the freespace erase, if your customer really needs that. 

     

    Learn more from the (somewhat stale) Apple security guides and from the NSA guides.  If you or your customers are sufficiently paranoid (or have sufficiently high-value data), wipe the (encrypted) all of your disks/storage at disposal, or physically destroy the disks/storage.  If you're really into this stuff, start reading the Common Criteria stuff and the older Rainbow books.

     

    Even better, just don't have data around that'll get somebody in trouble if it's exposed; have it HIPAA-sanitized or redacted or whatever.

     

    If you want low-level details of the file system, see the OS X Internals book and the new internals book.

  • by etresoft,

    etresoft etresoft Apr 21, 2013 4:22 PM in response to MrHoffman
    Level 7 (29,056 points)
    Apr 21, 2013 4:22 PM in response to MrHoffman

    MrHoffman wrote:

     

    If you want low-level details of the file system, see the OS X Internals book and the new internals book.

    The link for the new book seems dead. I don't know how relevant the old OS X Internals book is anymore. It was obsolete almost immediately and MacFUSE is just a mess.

  • by BobHarris,

    BobHarris BobHarris Apr 21, 2013 4:51 PM in response to etresoft
    Level 6 (19,272 points)
    Mac OS X
    Apr 21, 2013 4:51 PM in response to etresoft

    <http://newosxbook.com/index.php>

    works for me.

     

    And I do not think HFS+ plus has changed all that much since the OS X Internals book was written.

     

    And ifthe OP is worried about the file system changing after some investigation was written up, then they should not depend on any written documentation as the next OS update, security fix, etc... might change the behavior of the file system.  Instead they should invest in whole disk encryption or other means that insure the OP's customers data is protected at all times.

  • by etresoft,

    etresoft etresoft Apr 21, 2013 7:12 PM in response to BobHarris
    Level 7 (29,056 points)
    Apr 21, 2013 7:12 PM in response to BobHarris

    BobHarris wrote:

     

    <http://newosxbook.com/index.php>

    works for me.

    Curious. It is only broken in Canada. If I connect through my USA VPN, it works fine. Turn it off - broken. Back on - running again. I can't even ping the IP address 72.233.65.195. I can, however, see a different DNS setup via the author's "hisown.com" server that I don't see from the US. This is why I don't mess around with DNS.

     

    The question is, would I trust someone with kernel extensions who can't be trusted with DNS configurations?

     

    And I do not think HFS+ plus has changed all that much since the OS X Internals book was written.

    *cough* hard links to directories *cough*

     

    And ifthe OP is worried about the file system changing after some investigation was written up, then they should not depend on any written documentation as the next OS update, security fix, etc... might change the behavior of the file system.  Instead they should invest in whole disk encryption or other means that insure the OP's customers data is protected at all times.

    Alas, the original poster has rejected File Vault as being "extremely unreliable".

  • by BobHarris,

    BobHarris BobHarris Apr 21, 2013 8:24 PM in response to etresoft
    Level 6 (19,272 points)
    Mac OS X
    Apr 21, 2013 8:24 PM in response to etresoft

    And I do not think HFS+ plus has changed all that much since the OS X Internals book was written.

    *cough* hard links to directories *cough*

    Like I said, "I do not think HFS+ has changed all that much"

     

    Hardlinks to a directory are no different from a hardlink to a file.  The only thing preventing it from happing is file system code typically says "Oh No! That is a Directory.  Oh My, you cannot do that!".  You just add a tiny bit of code that checks if the caller has  sufficient privs and then you allow the hardlink just like is done for regular files or mkdir.

     

    See, that is not "much"

     

    The . and .. you see from "ls -a" are hardlinks, and the parent directory gets a hardlink to it from every subdirectory created within the parent, as the subdirectory has a .. in it.  The only difference is that outside of mkdir() system call, the file system has not allowed application programs to use the link() system call to create hardlinks to a directory.  Or I should amend, most Unix implementations have not allowed hardlinks to directories.  However, it was rather common back in the early Unix days.  AT&T System V UNIX (1985 timeframe) allowed the root user to create hardlinks to directories.

  • by jayv.,

    jayv. jayv. Apr 21, 2013 8:40 PM in response to etresoft
    Level 4 (1,290 points)
    Apr 21, 2013 8:40 PM in response to etresoft

    Very interesting book that, i'll check it out.

     

    Alas, the original poster has rejected File Vault as being "extremely unreliable".

    Correct, and it is. In my line of work i see it fail almost on a daily basis specially in combination with Time Machine. I use PGP Whole Disk Encryption (not a big fan of TrueCrypt) which has not yet let me down.

     

    Thanks for all the feedback fellas

Page 1 Next