Request for Autopsy auto-connections

store-requests
#1

Autopsy (website, GitHub) is a Digital Forensics and Incident Response (DFIR) tool that allows users to process data sources (i.e. logical file sets, disk images, local disks, etc.), analyze the files in the file system, and view files and artifacts on the file system.

I would like to request the following for auto-connection for autopsy:

  • dm-crypt, block-devices, fuse-support, removable-media, mount-observe, and system-files-dev (system-files read access to /dev) to find and ingest data sources.
  • system-files-hugepages (system-files read access to /sys/kernel/mm/hugepages), hugepages-control because we run Solr locally for indexing keywords in files, which in turn uses hugepages for performance implications.
  • desktop-launch to launch file manager to view autopsy log folders, web browsers online/offline help, and user default applications for opening extracted files in external applications.
#2

Hi @gregd,

Thanks for making the request. Many of those are super-privileged interfaces, which means that extra scrutiny is required before granting access to them at all (not just for auto-connection) as well as publisher vetting. The aggregate effect of using so many super-privileged interfaces must also be considered.

It would be helpful if you’re able to provide a bit more detail about why some of these are required. I’ll start things off with a couple of questions but other @reviewers might like to chime in too.

  • Does hugepages-control not give enough read access to /sys/kernel/mm/hugepages/ ? (negating the need for system-files-hugepages)
  • Read access to all of /dev/ - are you able to elaborate on how this is to be used / why it is needed?
  • I see in your snapcraft.yaml (although not requested here) that you have browser-support with allow-sandbox: true which is also rarely granted (and requires vetting); Is that something you’re planning on keeping/requesting too?

Thanks,

#3

Hi @dclane, Thanks for looking into it. To answer your questions:

Does hugepages-control not give enough read access to /sys/kernel/mm/hugepages/ ? (negating the need for system-files-hugepages)

I have issues getting hugepages-control working by itself. I talked about it in a forum post starting here. As best I can tell from source, open jdk is looking for directories in /sys/kernel/mm/hugepages matching hugepages-[0-9]*kB. I may be misinterpreting the AppArmor rules, but I believe hugepages-control's allowed directories don’t allow the subdirectories to end in kB.

Read access to all of /dev/ - are you able to elaborate on how this is to be used / why it is needed?

Currently, Autopsy scans for any readable device in /dev starting with hd, sd, or disk. If I just enable block-devices, I can see /dev/sda. If I enable the read access to /dev, I can also see the partitions like /dev/sda1, /dev/sda2, etc. I think the users would likely appreciate the flexibility. Is there a better way of doing this?

I see in your snapcraft.yaml (although not requested here) that you have browser-support with allow-sandbox: true which is also rarely granted (and requires vetting); Is that something you’re planning on keeping/requesting too?

No, that’s a mistake on my part. I can take that out. Initially, I was concerned that the JavaFX webview might not work without it, but after further review, I think I was wrong about that.

#4

It seems you are correct. That’s probably worth updating but in the meantime your system-files-hugepages will have to do.

I don’t know a better way for the /dev access you need. raw-volume looked promising but is only suitable for Ubuntu Core which I’m guessing isn’t the target for this snap. Given the specific purpose of the snap and the intended use/users, perhaps the /dev/* access may have to be granted. I think we would need a disclaimer in the snap description warning users that the snap is highly privileged.

#5

Ok. Makes sense. I will update the snap removing browser-support, and adding something in the description along the lines of “Disclaimer: due to the system access necessary for Autopsy to perform correctly, this snap is highly privileged”

#6

@dclane, I uploaded a new version of the snap removing browser-support and added a disclaimer to the description. If there is anything else I can do on my end, please let me know. Thanks!

#7

Hi @gregd

As an occasional user of Autopsy, I appreciate your request and understand the need for these plugs, so that I will definitively support the decision to grant them the ability to connect.

However, as a store reviewer, I also need to consider that most of these interfaces are superpriveleged, and given that the target audience of this software should not face major difficulties to manually connect them, I would suggest to not grant them auto-connect.

Thanks

#8

Hi @jslarraz, just to make sure I understand, you are suggesting that the super-privileged interfaces should have the ability to connect, but not granted auto-connect? So dm-crypt, block-devices, desktop-launch, and system-files access to /dev could be left in the snapcraft.yaml for the user to connect if they desire, and fuse-support, removable-media, mount-observe could be auto-connected? Based on the conversation with @dclane, it seems that system-files read access to /sys/kernel/mm/hugepages is comparable in behavior to hugepages-control. Given that hugepages-control is not super-privileged, is this system-files read access super-privileged in your mind?

#9

I like the suggestion of @jslarraz to allow connection of these super-privileged interfaces but not to auto-connect them. The concern I have with the original proposal is that it is very permissive and when considering the voice of the user it doesn’t seem unreasonable to ask them to connect the interfaces allowing these access themselves.

What I think would satisfy the review team and not be too onerous for users would be:

auto-connect:

  • dm-crypt (super-privileged)
  • block-devices (super-privileged)
  • desktop-launch (super-privileged)
  • fuse-support
  • mount-observe
  • hugepages-control
  • system-files (hugepages) (super-privileged)

manual-connect:

  • system-files (/dev) (super-privileged)
  • removable-media (super-privileged)

The reason I propose breaking them into these categories would be that these two interfaces that would still require manual connection are likely the easiest for your users to understand, and of course they’re highly sensitive.

I’ll ask @Igor to chime in too, because we will need to complete publisher vetting in order to allow the use of the super-privileged interfaces, so perhaps it is worth kicking that off now.

#10

I will kick off the vetting process. @gregd Can you please DM the official email for autopsy?

#11

Hi @dclane,

I think what you and @jslarraz are proposing could work. We can update our documentation regarding how to properly setup connections in the Autopsy snap for the manual-connect plugs.

1 Like
#12

Excellent. This gets my +1 then, once the vetting process is complete.

1 Like