Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
With GRSecurity and similar solutions you get improved security at the cost of more complexity and the risk of breaking some applications if you are not careful. GRSecurity adds some protections against buffer overflowns, it hardens chroot, it adds new firewalling options and a fine permission system. You should decide if you require such a thing and if you are willing to maintain a system with that installed.
Most personal computers do pretty well without SElinuxes or GRSecurities. I think I would only use this kind of things for small systems which are expected to accept connections from untrusted sources (like a personal file server).
I'd chip in to offer the suggestion that, if you need to maintain a network of related systems that need to be able to operate securely in a not-trustworthy environment, the additional strictures that are available in systems like these are in fact quite useful. When coupled with centralized authentication systems like Kerberos they grow stronger yet. Basically, these are integrated-design security infrastructure models that are designed to go well-beyond the rather simplistic security model of "stock" Unix/Linux, and they have good pedigrees.
*BTW recurring problem with your OPs is you tend to be too terse on the nfo... Whatsit for? SOHO machine? Single LAN file server? Hosting perhaps?
Anyway, I agree with the above (you're already aware of certain parties elsewhere using GRSecurity+PAX). Next to the learning curve (which you may or may not view as a burden), the fact it comes with a developer who's dedicated but also rather vocal, the fact that even them ppl seem to use Grsec, one of the practical problems is that only few Linux distributions offer GRSecurity-hardened kernels out of the box. IIRC the earliest adapter was Gentoo Hardened, there's Atomicorp's ASL (IIRC based on CentOS but it's a commercially licensed product) and then there's OpenWall (OWL, based on RHEL and IIRC taking some features from Grsec but correct me if I'm wrong). This means that if yours is not one of the distributions listed you'll have to recompile your kernel each time that's required (security-wise?). Not a problem with Vanilla kernels or sources patched with SELinux except you can't use both MACs at the same time. Good starting points for getting to know GRSecurity and its features would be here and here.
*I don't tend to emphasize my own opinion but when selecting this type of product it would not seem odd to me to question Linux distributions that:
0) are commercially licensed (I don't mean ASL, think water-vapour-suspended-at-an-altitude Linux) and
1) did not or still don't share source code modifications publicly as per GPL requirements and
2) have a CEO whose posts may be colored by the fact he has a vested interest in selling his product.
I'm the author of grsecurity. Just wanted to clear up some information in this thread.
There's nothing stopping anyone from using both grsecurity and SELinux at the same time, some of our users choose to. Grsecurity does not implement RBAC via LSM, so it is not subject to the problems that affect other access control solutions using LSM, particularly the lack of ability to stack multiple access control solutions.
Openwall does not use grsecurity. They predate grsecurity and thus any features they contain that grsecurity also contains were not taken from grsecurity. We inherited those useful features from Openwall.
I understand that kernel compilation can be a barrier to entry for some. For brand new users (in my opinion), it may be a useful barrier. Those users will hopefully read through all the configuration help and have a greater understanding of the additional security they're adding to their systems and under what conditions it's useful. This kind of important learning would not happen for a user installing the kernel from a package. However, I also recognize that once that initial learning is completed once, there's nothing more gained in compiling future kernels (modulo reading config help for new features introduced), so I do plan to offer custom-built kernel packages in the future.
I use grsec features along w/ RBAC. On desktops that need graphics support I disable the intense ACL but still use grsec features. If you want anything more useful than a virus scanner that stops undiscovered threats, then grsec is a good choice. But really it is layering w/ strong ACL implementations that make up a good security policy.
Gentoo offers IMO a straightforward approach to implementation. It has automatic profiles within the kernel menuconfig for server or desktop or custom. I haven't tried anything else and Gentoo in general is a learning curve.
The advantage to grsec in large is prevention of unknown threats. Many exploits and vulnerabilities use similar methods of attacking your system. Although the individual malwares and viruses get their own unique names, how many attacks get carried out are similar in nature and grsec features aim to prevent these methods of attack by addressing the common points of weakness and changing them.
It adds overhead to performance and can hinder the possibility of graphics hardware acceleration. Also it could draw attention more undesired just being utilized.