Hey, On Mon, 2016-12-05 at 16:42 +0100, Carlos Garnacho wrote:
On Mon, Dec 5, 2016 at 3:01 PM, Hanno Böck <hanno hboeck de> wrote:On Mon, 5 Dec 2016 13:44:40 +0000 Sam Thursfield <ssssam gmail com> wrote:The design of Tracker takes the risks into account. Metadata extraction is isolated in its own process (tracker-extract) which can crash without (theoretically) causing any harm.I don't see how that helps against security vulnerabilities. Having an isolated process probably helps in a way that a crash won't cause the whole tracker service to malfunction. Thus parsing broken files won't cause a service disruption. But as long as this process runs with normal user rights this doesn't protect in a security sense.I think there needs to be a wider discussion about this and the fundamental design choices done here need to be questioned.What questions do you have in particular?Quite frankly, I don't claim to have all the answers here, that's why I formulated it in an open "needs discussion" way. I think sandboxing the tracker parser (which you already indicated in your mail) is probably the most reasonable way to go forward. This isn't exactly my area of expertise, so I can't comment on which technique here is most promising.It indeed sounds possible to lift extraction into a separate process with limited access to the filesystem, we essentially need to pass an fd to mmap() and an output one to receive sparql back. There's just two things to consider: - The extraction process sometimes needs access to misc files (eg. CUE files, XMP sidecar files, ...), those might be passed along too, but then we need detecting those cases beforehand. - Ideally we wouldn't spawn one process per file being extracted, although if we go to defcon 1 level of paranoia, that's probably what should happen.
I would suggest a single sandboxed extraction process, which has read- only access to the whole of ~/, and write access to the Tracker database. No network access. That means that regardless of whether or how the extraction process gets compromised, it cannot compromise the integrity of any of the files in your home directory (except the Tracker database, which I assume people aren’t too precious about), and it can’t compromise the confidentiality of any of your data (except by leaking it through the Tracker database — can we assume the database format is sufficiently prescribed to be able to prevent this?). This should be easily accomplished by using an AppArmor (or equivalently, SELinux) profile for tracker-extract. seccomp-bpf could also be used to achieve much the same thing, regardless of whether an LSM is enabled. The Apertis project has such an AppArmor file already, and it would be great if that were pulled upstream: https://git.apertis.org/cgit/packaging/tracker.git/tree/debian/apparmor .d/usr.lib.tracker (I am not claiming this profile is perfect, but it’s a start.)
Anyway, this goes IMHO too much on the technical side for this ML, we already have https://bugzilla.gnome.org/show_bug.cgi?id=764786 filed to Tracker, and it's already high in my list for fixing on 1.12, feel free to join there. And I should add... Tracker is not alone here, if it's not Tracker stumbling on infected content, with varying but still rather low levels of interaction it may be a thumbnailer, a previewer like sushi, or the web browser itself streaming content which hit this. So there's more places in need of further isolation when dealing with untrusted content. And still, the chain is only as strong as its weakest link, as soon as there is anything opening that file with wide enough permissions to cause any harm, you're essentially screwed. This might sound like an argument to running every app through flatpak, although I think the long term answer always is "fix the vulnerability!".
Agreed. Thumbnailers are another big target here.
The other issue I think is that the quality of huge parts of the foss ecosystem needs to be improved. The good news here is that we got some powerful tools in terms of fuzzing (afl, libfuzzer) and memory safety bug detection (asan) in the past years. Ideally all free software devs should be aware of those tools and use them in their development process. I'm trying to help here where I can, see e.g. also my recent post on this list [1]. If our libraries would be better tested we could be more comfortable feeding it with untrusted inputs.I agree some more active prevention would be positive, sounds like something to tackle in the libraries dealing with file formats though, Tracker is a strawman here, in the sense that filesystem extraction it's only exploitable through its tracker-extract's modules, and those are for the most part implemented using external libraries.
I think the point here is that Tracker will start extracting things from files when they appear on the file system. So while a malicious file could have caused problems eventually (when the user opens it), the presence of Tracker means it can start causing problems a lot earlier, without the user necessarily realising. But as you say, Tracker is not necessarily where the exploits are. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part