3 ms·
> Threads on Linux can have their own seccomp profiles. Not on Windwows or on macOS. > new thread that will read from the existing FD and only send you simple
by jbk 9y ago
> Threads on Linux can have their own seccomp profiles.
Not on Windwows or on macOS.
> new thread that will read from the existing FD and only send you simple, time sorted messages over a shared IPC/pipe is not that crazy.
Of course that does not solve anything, because your demuxer|decoders|output needs access to the FS, have access to kernel-mode and those are the dangerous parts.
- viraptor 9y agoI'm not sure what you're trying to say. Yes, I meant Linux. Yes, it can solve the issue of separate subtitle files, which this article is about. Read access to an existing FD is not the same as full FS access, and there's no demux involved here.
- jbk 9y ago> Yes, I meant Linux The demo is on Windows. The goal is to do a sandbox that works on most OSes. And, it will not solve the decoder issue, since it is on the decoding side, which still has access to the GPU/Aout and the kernel. > Read access to an existing FD is not the same as full FS access, and there's no demux involved here. You're totally missing the point here. The issue is demuxers/decoders/output, not really the access. Reading from an FD or not would not solve the buffer overflow exploitation (if it was actually exploitable).
- zeveb 9y ago> > Threads on Linux can have their own seccomp profiles. > Not on Windwows or on macOS. It's a shame, then, that Windows & macOS are holding back security improvements for software running on Linux. I understand (& even agree with!) your desire to have a sandboxing mechanism which runs acceptably on all supported systems; it's just sad that this security mechanism in the Linux kernel can't be taken advantage of in vlc.
- jbk 9y agoWell, no. Because you can do it per-process. I don't see the reason of doing it per threads here.