Or create threads in other programs? Or debug other programs? etc. etc.? This functionality being available is all part of the DAC model, but it could be overridden internally with stub functions, couldn't it? e.g. Code: #include <unistd.h> int execve(const char *filename, char *const argv[], char *const envp[]) { return 0; } On Linux this can be compiled into a library and injected into programs at load time using LD_PRELOAD. The program then won't be able to launch other programs, because it doesn't see the real execve() provided by the kernel. Sure, there are ways of overriding this override. Even so. Why don't applications that don't need exec. debug, etc. functionality override the necessary functions in their headers? Wouldn't that raise the bar a bit on what was required to compromise a typical desktop?
Probably developers don't want to make their software to inconvenient. Most of them still need to execute other programs (update checkers...). So they will have to somehow whitelist those applications. At the end they would probably have to built whole anti-exe logic in their software. IMO anti-exe is better implemented on OS level than on application level.
..because it makes it easier to load ads and to transfer money from your wallet to their wallet. Ughhh...
Well, this factors into it. This policy alone does little, as an attacker can override that, or do plenty of other things. But, on Linux there's seccomp filters, which would prevent an execve call if you filtered it out. The thing is that browsers need those things you're talking about. Firefox needs to be able to launch and communicate with your torrent program when you download a torrent file, and open it within the browser. Things like that require exactly the type of permissions you find in DAC - arbitrary access to other programs.
... Wait, duh. Even without exec privileges you can write an executable/library somewhere, and make sure it will get executed/loaded later. ("export LD_PRELOAD=~/.config/.libnasty.so" in your ~/.xprofile, or whatever.) So this really would be trivial to circumvent. N/M. Anyway I'm not in the habit of launching stuff directly from my browser, but maybe other people are, I don't know. Seccomp is a step in the right direction though. The typical DAC model of programs inheriting all the user's privileges = broken, IMO.
Or just do what fork does anyways, load up a process and execute it. You could just overwrite your browsers address space with another image. I've been meaning to try this anyways. DAC's really good for some things, and really clearly broken for many others. Just like MAC. Some things just aren't going to make sense in an apparmor profile, or SELinux for that matter. And some things are. That's why there's a lot of different methods for access control on Linux. Read my blog
Anyways on Linux is it not easy enough with Apparmor (MAC), for instance, to restrict the browser to interact with only what is required and no more, with exacting precision?
Well, not without losing some functionality. So when you download a .deb package in Chrome, you can click it and it'll start to install via the package manager. Thta's a nice functionality for most people. But the problem is that that is obviously dangerous behavior. So Apparmor could allow Ux on the software-center but then that's a huge hole and makes the whole profile a bit useless. So you either get security or usability with Apparmor. The nicer approachis brokered, which is what chrome does, where it'll only send that .deb pcakage to the software-center if it knows it makes sense to do so.
Well, no. If you want to install it from just clicking the download in your browser, it does. But if you click from the folder it dowlnoaded too then it's not handled by the browser.
That makes sense and what I thought was the case. I guess I'm just thinking about typical browsing and something, let's say a malicious script, on an exploited webpage attempts to somehow, someway, utilize the browser in one of the attack steps, and this is where a tightly restricted Apparmor profile should prevent this from happening.
Scripts shouldn't be too dangerous in regards to an apparmor profile. They can only work within the confines of the renderer, and this is the case in any browser. The issue is more when the script is able to gain control over the renderer, and then a sandbox is helpful.
I believe that Google Chrome on Windows uses job objects (operating system feature) to stop certain Chrome processes from launching other programs. On Windows, you can use RunInsideLimitedJob to do this with whatever processes you want to.
This pdf document seems to be referencing that, at least with regards to the sandbox... -http://seclab.stanford.edu/websec/chromium/chromium-security-architecture.pdf
Yes exactly, isn´t it true that all apps can act like a "parent process"? That´s the way that Windows is designed. I do know that a while back, the Maxthon browser had this feature that could white-list certain apps that could be launched (the "external utilities" feature) while all others are blocked. In theory that could have stopped certain type of exploits. @ wat0114 When you read the document (about the Chromium sandbox), you can also get an idea of how Sandboxie works, quite interesting.
