Which is also why trying to do anything productive on a smartphone is such an uphill battle. Arbitrary programs not being able to exchange arbitrary files is totally crippling for any use-cases that go off the rails of what one single app wants to let you do.
for src in $(find . -type '*.png')
do
sdir="$(echo "${src}" | dirname)"
name="$(echo "${src}" | basename)"
dstdir="/mnt/www/images/${sdir}"
optipng -out "${dstdir}/${name}" "${src}"
convert -scale 120x120\> "${src}" "${dstdir}/small_${name}"
done
You could do literally the same and you didn't even need to drop to the console.
Opening any random file should be reserved to just a few core applications.
The problem is more that I do not believe any distro is shipping a default-deny policy. Unknown programs are simply given the kitchen sink rather than having, say, user friendly prompts saying "this program has no access control and wants to open X or use Y, allow?"
But we definitely have the technology, and it does not take any heavy overhead isolation to do it.
Arch has a grsec kernel in the repos if you want one...
There are two ways to do MAC - applications (or the distro) provides the profiles, that restrict execution to just what the program will use, and if it ever asks for anything else it should be suspect for exploitation. The other one is where you put your programs in learning mode, and that only hardens you against future exploits, not current ones, and you also lose the protection against untrusted software because by default everything is untrusted and you must trust everything on a case by case basis.
Say, VLC team had argued that a video player may need to open a supplementary subtitle file. If application can be only granted access to a single video file - that's impossible. I think there were other examples, but I don't remember those off-hand.
For example, for a text editor like vim, here's a completely reasonable lockdown:
- see none of my filesystem... except `cwd` I launched you in
- you get a homedir that's persistent for this application
- (incidentally, whatever libraries you need are there; network namespaces dropped, clean env vars, clean pid space, etc etc etc.)
The things on this list involve essentially Nothing Special and no changes to the program, and at the same time manages to radically reduce the surface area a malicious program can mess with on my computer. Even if, say, a malicious version of vim somehow made it in $distro's package tree and was signed: this still makes me... well, pretty safe. The scope of damage is confined to... exactly what I just laid out on those two bullet points.
And subuser's configuration does an excellent job of exposing exactly those kinds of behaviors to you with very minimum amounts of fuss.
(A json file with `{"access-working-directory": true, "stateful-home": true}` is all you have to say to subuser to set up an application to get... well, hey, if these aren't self-documenting names, I don't know what is.)
But for anything you install from the main repos, it will almost always have an apparmor / selinux profile installed along with it to prevent this kind of arbitrary filesystem access.