>but mostly OSs don't do anything to restrict what an executable can do by default, at least as far as installing.
There is a very mature and very powerful system for this called Jails.
>There are linux installers that are just binary blobs and it would be a lot more work to monitor what they do also.
This is simply not true. If I want to monitor an app in it's entirety I can easily do so on most unixy systems.
Past the default tools that require some amount of systems knowledge to use correctly, you can easily just use Stow or Checkinstall (works on most linux systems).
There is no mechanism for doing this on Windows as even the OS loses track of it sometimes. And if you think I'm being dramatic, trust me, I am not. There is a reason the tools don't exist for Windows, at least meeting feature parity.
> There is a very mature and very powerful system for this called Jails.
No, jails aren't really the solution to the issue I'm talking about.
It's 'a' solution, but not the ideal solution.
> This is simply not true. If I want to monitor an app in it's entirety I can easily do so on most unixy systems.
It is true, but I think you're missing my point. If I wanted to monitor any app on Windows I can do the same, I just need procmon from sysinternals.
> There is no mechanism for doing this on Windows as even the OS loses track of it sometimes.
There is, in fact there are numerous solutions.
The point was simply that there can be hostile installers that you require tools to see what they are doing on both Linux an Windows. Linux isn't special in any way in this regard.
Maybe? What are you envisioning? Some sort of static analysis before a program runs? Explicit opt-in's to what a program needs, from the program itself (and only what it needs)?
I'm just talking about respect for convention. The same way on an FHS respecting distro a software should install to FHS paths and not, for example, make a new root level directory. There's a respect for user preferences there.
It's not about using technical means to restrict software, but about the OS providing certain mechanisms and there being an expectation for trusted software that it will respect those conventions.
That's why I don't consider a jail a solution. It's an extra step the user has to carry out, and I don't think the burden should be on the user if it doesn't have to be. While in one sense it's good security practice to treat every program as malware, most users are not going to do that nor should they have to.
A tool like Sandboxie on Windows solves that problem in one sense, but not the actual root of the problem, which is it being more acceptable than it should be to go against user preferences and convention.
There is a very mature and very powerful system for this called Jails.
>There are linux installers that are just binary blobs and it would be a lot more work to monitor what they do also.
This is simply not true. If I want to monitor an app in it's entirety I can easily do so on most unixy systems.
Past the default tools that require some amount of systems knowledge to use correctly, you can easily just use Stow or Checkinstall (works on most linux systems).
There is no mechanism for doing this on Windows as even the OS loses track of it sometimes. And if you think I'm being dramatic, trust me, I am not. There is a reason the tools don't exist for Windows, at least meeting feature parity.