With Wayland and dbus and all the techs going into a modern Linux desktop, it is probably very doable to prompt users when a program tries to open a file with a simple "Application X wants to open file Y in location Z, let it? Yes / No / Allow for all contents of Z / Allow All Locations".
That would be a misnomer, because "important" file locations like ~/.config, ~/.share, etc would always prompt user acknowledgement when a program tries to open something in those and it is not the originator program (ie, VLC can open something like ~/.config/vlc or ~/.share/vlc, but if it tried to open ~/.config/mplayer or ~/.share/mplayer you would get a prompt notification of it.
> access (and unique probably) to raw devices read-only
I don't think this is hard at all, device permissions are something that mostly already works. Just say "App X wants to access device Y, allow? Yes / No / Always".
With good package management and distributors, you could have most of these "prompts" configured with sane defaults so you don't get spam when VLC opens files - the distro can just trust VLC in ~/Music and ~/Video all the time, and any user made directories, so just give it access everywhere except the config and share dirs, so on and so forth. When you install something it would make sense to tell users what it uses in the same way Android does upon installation, and if it tries to access something post-install you get a dialog about it (ie, VLC could say at install it uses the network, or it could ask at runtime if it tries to access the network).
Why would VLC need raw audio out? Route through pulseaudio, nobody should be opening raw audio devices anymore unless you are Ardour.
I think the real problem is nobody gives a shit about desktop security. I mean I run Archlinux where there isn't a single working MAC solution that does not require days of prep work. But having delved a lot into Mac and such, I have no faith in Apparmor or SELinux when PAX and Grsec is doing a much better job and nobody is using it. And they all have holes somewhere, either they don't have fine grained device permissions, or lack tunables, or don't harden the kernel enough to avoid simple exploits. Its a mess nobody is really trying to solve upstream of security implementations and distros are doing a half assed job about it across the board.
That would be a misnomer, because "important" file locations like ~/.config, ~/.share, etc would always prompt user acknowledgement when a program tries to open something in those and it is not the originator program (ie, VLC can open something like ~/.config/vlc or ~/.share/vlc, but if it tried to open ~/.config/mplayer or ~/.share/mplayer you would get a prompt notification of it.
> access (and unique probably) to raw devices read-only
I don't think this is hard at all, device permissions are something that mostly already works. Just say "App X wants to access device Y, allow? Yes / No / Always".
With good package management and distributors, you could have most of these "prompts" configured with sane defaults so you don't get spam when VLC opens files - the distro can just trust VLC in ~/Music and ~/Video all the time, and any user made directories, so just give it access everywhere except the config and share dirs, so on and so forth. When you install something it would make sense to tell users what it uses in the same way Android does upon installation, and if it tries to access something post-install you get a dialog about it (ie, VLC could say at install it uses the network, or it could ask at runtime if it tries to access the network).
Why would VLC need raw audio out? Route through pulseaudio, nobody should be opening raw audio devices anymore unless you are Ardour.
I think the real problem is nobody gives a shit about desktop security. I mean I run Archlinux where there isn't a single working MAC solution that does not require days of prep work. But having delved a lot into Mac and such, I have no faith in Apparmor or SELinux when PAX and Grsec is doing a much better job and nobody is using it. And they all have holes somewhere, either they don't have fine grained device permissions, or lack tunables, or don't harden the kernel enough to avoid simple exploits. Its a mess nobody is really trying to solve upstream of security implementations and distros are doing a half assed job about it across the board.