Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have fiddled around with both SELinux and Apparmor recently and found these tools invaluable for preventing a spread of damage from a compromised context via one process, whereby and attacker could exploit a buffer overflow or underflow, eventually pushing a new return address on the local call stack, which if I am correct can lead to exec() calls or even a root shell via say, su -

Learning Unix & Linux is very interesting to me, and I want some of the more seasonsed people here to please offer me some basic reflection on this topic. Are these tools really overkill for a desktop or non government secure/business context, whereby a serious say, rootkit intrusion can be detected by analyzing the integrity of the System.map file for any rogue entries, and checking of package integrity etc. Say, a remote intrustion on these systems isn't a massive deal following cleanup, so prevention via MAC is overkill?

No system is perfect, but would I be correct in making the assumption that on a basic desktop system, passwordless key based logins/swipe card and disabling remote logins via ssh etc, not to mention patching the system and disabling root work on any console, virtual or similar, except for console tty1, which is physically isolated from rogue user programs like firefox, would this setup be "ok" for most intents and purposes, or should MAC reside on ALL systems?

Keep in mind most Linux distributions out there DO NOT offer MAC as a default. Fedora and CentOS/RedHat appear to be the only two well known ones to offer out of the box MAC.Thanks:)

share|improve this question

closed as not constructive by Gilles, warl0ck, jasonwryan, Michael Mrozek Sep 15 '12 at 23:31

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

I believe you answered yourself in your last paragraph. Since most of distributions do not offer MAC, it is not strictly required and your system may be considered save without it. It's just another level of security. I believe that there is no one valid answer to your question as everybody will probably have hes own opinion. –  Krzysztof Adamski Sep 14 '12 at 20:22
It's a subjective question I will admit, so I guess it really comes down to preference. It's interesting if you consider that Unix is traditionally known for kernel privilege separation. This confuses the hell out of me, that somebody could write a hack to circumvent a local function call, and instead use a payload of code to spawn a root shell for instance. Isn't this situation the opposite of what was intended with OS privilege separation? My guess is that these "flaws" are a result of the flawed design of interrupt handling on x86 systems, but then again, I am no expert. –  bottlefickle Sep 14 '12 at 20:47
It has nothing to do with interrupt handling. Also it's not normally possible to gain root privileges while exploiting some application run as non root user. Unless there's some security flaw in your system. The privilege separation in Unix was a little simplified, however. Root could do everything and normal user could do little and there was nothing in between. This was (and very often is even now) source of many security problems and MAC is trying to address them. –  Krzysztof Adamski Sep 14 '12 at 21:23
I should have clarified better. Assuming that an exploit is a success, and an attacker could execute code where the handler has jumped to, unless there is a form of address space randomisation, it's going to be easy to predict where to place arguments and system text segment string(system call to use) on the stack. Now if we have MAC to compensate for design flaws in x86, such that address space for memory both kernel and userland is generally predictable, why not just bypass Media Access Control entirely by implementing Address space randomisation entirely in hardware? –  bottlefickle Sep 14 '12 at 22:32
I believe it's starting to be discussion instead of Q&A. I just don't see how hardware address space randomization could work nor I can see how this is related to specifically x86 architecture or unix or even MAC. I can't image situation where address space is not predictable for kernel or even userspace. It may differ on each system but can't be random. –  Krzysztof Adamski Sep 15 '12 at 8:52

Browse other questions tagged or ask your own question.