Velko wrote:
For example, if Facebook somehow manage to set a cookie while I was visiting "website1", browser process should not even be able to read that while I'm visiting "website2".
How would that work? The organization of the cookie database is very definitely an internal part of the browser. In this case, neither AppArmor nor SELinux could do anything, since the identity of the process reading the cookies is the same as the process that wrote them. In both cases it is the web browser. Unless the browser were to change contexts on each site call, but then it would be an opt-in thing for the browser, and they could just choose not to.
AndrewAPrice wrote:
When it comes to single user systems (personal computers, smart phones, even game consoles) - my most valuable files are my personal files (code, documents, save games - things I've put hundreds of hours into), and my least valuable files are binaries and operating system files that are an inconvenience but I can re-install. User based permissions give the opposite effect - they lock down system files, but any program you run has free rein on your personal files.
Yeah, I should probably implement something akin to AppArmor (SELinux is for people with too much time. That would allow you to lock down your file system better. And indeed, much of Android's security system seems to go in that direction, requiring direct user consent for each permission for each app on installation, and then giving each app their own file systems (with the capability to browse the whole FS being a capability listed on installation). Implementing something like that might also be interesting.
Doesn't have anything to do with executable stacks, though.
Brynet-Inc wrote:
Other operating systems have a misfeature called PT_GNU_STACK which has lead to the problem of infectious executable stacks, meaning a miscompiled dynamic library (e.g. PAM) can contaminate things in such a way to force the process to have an executable stack.
Erm... how does that work? The main stack is mapped by the kernel, and the kernel doesn't see any library dependency other than the dependency on the program interpreter (dynamic linker). Unless GNU ld were to set the attributes of the main program's PT_GNU_STACK according to the stack attributes of the dependent libraries... but that would be dumb, as the library present at run time does not have to be the same as the one present at link time.
Yeah, anyway, that is precisely why I'm asking. So apparently I would be breaking GNU C local functions. Oh well, I shall survive. I rarely see those used at all.