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.
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?
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.
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.
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”
@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!
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.
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?
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.
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.
I would also suggest not to have super-privileged interfaces auto-connected
Are you saying that you agree with @dclane’s suggestion here ?
Regarding the description, would something like this suffice?
Autopsy is a graphical interface to The Sleuth Kit and other open source digital forensics tools.
Disclaimer: due to the system access necessary for Autopsy to perform correctly, this snap is highly privileged and uses the following interfaces:
block-devices, dm-crypt, 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), and hugepages-control to run Solr 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
+1 from my side, I agree with the suggestion made by @dclanehere, it makes sense to have these two interfaces system-files on having read access to /dev and removable-media to be manually connected and remaining to be auto-connect
Thank you very much! Moving forward, when Autopsy has a new release (i.e. we move from 4.21.0 to 4.21.1 or 4.22.0), what is the process for updating the snap? I’ve done some reading here. Ideally from my perspective, we may create a candidate risk level release or possibly multiple candidate releases if we find bugs. Then, when we are satisfied with a particular candidate, we would move a candidate into stable and it would be the default option for users to install from the snapcraft store. Is that workflow possible, and if so, what uploads to the store and store requests would need to be made? I’m assuming we would need to upload all of the candidate releases, but is there a way to move a candidate to stable? I noticed there is a “promote” button next to the release. Would I use that? Also, for any store requests that need to be made, what is the easiest/fastest way to get a new release approved?
Also, I was looking over the page for the Autopsy snap. I noticed that the icon and license were missing. Currently, in the snapcraft.yaml, I have icon: snap/gui/autopsy.png which seems to be a valid path relative to the snap root, and the image is 256x256. For license, I have license: Apache-2.0 which appears to be a valid SPDX license here. Is there something I need to do to have those fields corrected?
Also, is there a way to make the publisher of Autopsy the name of the organization as opposed to my user account and allow multiple people to publish?
