Slashdot Mirror
Additional Security in the Linux Kernel?
nyx asks: "Recently, I was looking for some way to improve security on my linux boxes. I found few linux patches like grsecurity, LIDS (now also as Linux Security Module), Medusa DS9.
I'm testing grsecurity (and it's ACLs) now and I'm quite satisfied with it, but I wonder, what are pros and cons of other solutions. Anybody tried them and can share his experience with us?"
Lock the door when you leave the computer room.
Je t'aime Stéphanie
Let's hear it for NSA Security Enhanced Linux! Whoo!
If the NSA security enhanced your machine, would you even know about it? Suspect it?
[o]_O
http://www.solucorp.qc.ca
You can create virtual servers on your machine, tailored for specific tasks.
For example, you can create virtual server where you'll work on your project, virtual server which will run apache, virtual server in which you'll browse web and read mail.
You then can put them on different IP addresses (or no addresses at all) and make them indepedent, changing information only by means YOU approve (shared directory, TCP sockets under firewall, etc).
It's a kernel patch and some user-mode programs.
Virtual servers can share binaries for saving disk space.
I'm currently using OpenBSD in a work-related project. It's quite good, if not well documented.
You can't ride two horses with one ass
I seem to remember kernel patches happening in Bastille Linux... but then again in these autumnal years .... i remember things that never happened more and more....
The Linux Security Model has been included in the upcomming 2.6
Linux Security module is what adds hooks into the kernel for security. LIDS uses the LSM hooks, and so does SELinux, and (I think?) others. But LIDS != LSM.
You might want to check out Saint Jude - a kernel intrusion detection and response system which detects and blocks 'anomalous' behavior (such as root exploits). The developer first presented it at Defcon 8 and it looked pretty cool. It's been in development for over a year - see its SourceForge page for more.
While we are at the topic of security I was wondering whether there are any similar products to StackGuard (www.immunix.org) available for a newer gcc? StackGuard is commercial and only works with older gcc's. If there were such a thing one could probably do a whole system recompile with it (a la Gentoo). That would beef up the security considerably. The Immunix FormatGuard also looks interesting.
D.
I had a friend who ran all of his INET services through a VMWARE instance on his Linux box. He would get hit by a script kiddie, and then use the ROLLBACK feature to undo the damage. He would patch the hole on the virtual machine and start up the site as if nothing happened.
Bastille Linux is user space hardening (e.g. changing file permissions, disabling telnet and other vulnerable services, setting up IPTables and various other security features), no kernel patches as far as I remember.
"Karma can only be portioned out by the cosmos." -Homer Simpson
It's obvious that the only answer to this question is for all kernel developers to stop all productive activities for one month in order to sit through long and boring security lectures in groups of 500. After this month linux will be fully compliant with the "trusted security initiative" and will be magically bug free. Until such time as another bug is discovered.
They who would give up an essential liberty for temporary security, deserve neither liberty nor security
There's a program called Snort that does packet sniffing and intrusion detection, among other things. It's at snort.org.
That and good ol' P.G.P.
We're Doomed
ACLs (access control lists) are a wonderful technology, but for non-trivial systems they become an administrative pain in the @ss. In principle you would set them up and forget about them, or at least let users maintain their own, but in practice users can't maintain their own, and they will pester you to death with requests for changes.
They also tend to drag the sysadmin into office politics. E.g., Secretary A is out on vacation and Secretary B calls you and says Secretary A did not set up her ACLs correctly and would you please give B access to certain of A's files. In addition to the annoyance of having to babysit the users, there's really no correct response to such a request.
ACLs would be great on a system where everyone is a power user. In practice that usually means your home system where you are the only user, so ACLs aren't very helpful anyway.
Conclusion: wonderful technology, hope I never see it again.
BTW, I speak from personal experience, having formerly managed VAXen with their wonderful ACL implementation. I don't object to ACLs on Linux, I just don't want them.
Sheesh, evil *and* a jerk. -- Jade
This is such an obvious troll. What a shame it got modded up. Just a few of the more glaring errors:
C, a language that provides no security features such as garbage collection
In what sense is garbage collection a security feature? That makes no sense.
It is a very sad fact, but logically Microsoft's programmers are smarter than those in open source, simply because they're able to earn more money
That's not true at all. As someone who makes their living programming I can tell you that there are plenty of dumb commercial programmers and plenty of smart open source programmers. And vice versa. If you really wanted to be "logical" you'll understand that money earnt is not the same as skill. Plenty of people do highly skilled work without payment - ever heard of a hobby?
go for an operating system controlled by one company, who knows what their code does, and how to fix it if it goes wrong. The only option, in that case, is Microsoft.
Er... or Apple?
Like I said, blatant troll.
Sailing over the event horizon
isn't this how M$ got NT certified?
:)
all the above steps.. maybe not in that order
The greatest right given is the right to be wrong...
... you can try PitBull from Argus Systems. It's a very good product and free for non-commercial use (I think). If you can live without the source to their module.
the major problem today is people useing tools
to this end you can use a mac
(big endian so defeats alot of stack smashing targeted at x86)
use bsd
(THE network stack -problems in MS TCP/IP stack have been solved years ago in BSD)
and dont run any silly daemons
http://www.
does a nice job of sorting out things config wise where most problems live
regards
John Jones
I tried that - that solution gives more isolation between your virtual machine and main machine, but it's much slower than vserver patch.
I tried to use vserver patch for Mandrake 8.2 on
P1-200MMX with Apache, DNS, Mozilla, X and it worked perfectly.
Isn't this ingenious? Taking potshots at Linux by appearing to support it? ...clients are willing to reduce their servers' feature set, flexibility, and ease of maintainence by switching from Win2k...
I won't rehash the manyfold reasons you're wrong about those assertions (it's been discussed to death already), but I will point out that you're wrong, and you're just trolling. Knock it off.
Besides, while Linux's security is excellent, it can (and should) be improved. It's good, but by no means perfect. (It's much better than anything M$ can put out, though.)
o/~ All God's children shall be free in Pirates of the Caribbean, when we reach that Magic Kingdom in the sky... o/~
But on the other hand, you know what idealism is ...
From http://www.trustedbsd.org:
The TrustedBSD project provides a set of trusted operating system extensions to the FreeBSD operating system
In other words, it's not an OS, it's a set of patches and extensions... please, check your facts before you post something.
> go for an operating system controlled by one company, who knows what their code does, and how to fix it if it goes wrong. The only option, in that case, is Microsoft.
Er... or Apple?
Yeah. Or, for that matter, RedHat.
And with RedHat (or any of the other linux vendors), not only do they know what their code does, but there are also thousands of programmers scattered around the world who know a lot about it.
So if you have a problem, you don't have to beg and plead with a disinterested CS department of a giant corporation. You don't even have to deal with your vendor.
If it's a small problem, you can probably hire one or two of the linux hackers at your local college. For bigger projects that take experience, you can hire a few of the local linux professionals.
You'll be up and running in far less time than it takes to persuade Microsoft to support your needs.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Read about it in the RELEASE-NOTESe ta/limbo/en/os/i386/RELEASE-NOTES
ftp://videl.ics.hawaii.edu/mirrors/redhat/linux/b
I'd looked on and off at LIDS for a while, and one day decided to go for it. Brought it down to my desktop and began following instructions. The intent was to build the LIDS kernel and utilities on the desktop, and then scp them over to the firewall.
Except that LIDS seems to want to be built on the machine where it's going to be run. So what if your firewall doesn't have a compiler, build environment, etc?
Perhaps I should have RTFM further, but the available time ran out.
I've also read a little about SELinux, but there appears to be one common thing about all of these security enhancements: They make it possible to have tight enforcement of a security policy, but it appears that none of them ship any sort of policies. It would be nice to have a few to choose from, and begin learning. How about a policy that's very little more secure than the pre-LSM box, with a bunch of commented options to tighten down the screws. I guess I've seen some of that with GRSecurity.
But trying to evaluate and use any of these packages for a home system turns into a massive time-sink to do properly. WIBNI Bastille would add LSM to what they already do so well? (I know, join and do it, myself. Maybe when the big-time real world projects are in control.)
The living have better things to do than to continue hating the dead.
It works marvellously when it works. Randomized pid, randomized sequence numbers, and soon to have ACL's that define resource limits on just about anything. Really powerful.
:)
When it works.
I've been trying to run it on an SMP Xeon for a while now, and any time the machine exerts itself I have to go hit the big red button. And it's not really a machine I'd like to do "testing" on, so no, I won't help with debugging. What "testing" I've done so far has been nothing but infuriating.
Another few tidbits: all the security in grsec basically completely prevents any JVM from running at all. Ditto UML. (Though UML may also have issues with SMP. But now that I've removed a big variable in my equation of horror...)
Since Rusell Coker has package SELinux for Debian, I will definitely have to investigate that sometime in the near future. I think I'll rack some uptime first to bolster my self esteem.
I'm suprised no one has pointed out systrace yet. Granted, it's not for linux, only OpenBSD and NetBSD at this point, but it seems to be a very promising move in the ACL world. As one other poster commented, the most difficult challenge with any heavily ACL'ed environment is configuring the ACL's and making sure you didn't miss something. It's an extremely tedious process that requires a lot of reloads until it's done right.
Systrace eliminates much (but not all) of that initial trial period with a method of analyzing processes and watching what permissions for what resources they need and generating ACL's based on 'normal' use. This interactive mode ~greatly~ simplifies the otherwise length process of configuring the kind of security modules being discussed.
Sample here.
What part of "gestalt" don't you understand?
So why aren't we all using Mac OS for webservers? (excluding OS X)
- It's a major PITA to do any kind of remote management. While the lack of a command prompt may make it hard to hack, it also makes it nearly impossible to administer remotely (unless you resort to a VNC-like solution, in which case you are subject to all the flaws of that solution)
- Macs are expensive. Look at XServe. Look at comparable Linux servers. XServe is expensive.
- Lack of software: Mac OS wasn't traditionally a server OS, so many of the tools that we know and love in Linux and even Win32 are missing
- Mac OS 9 Sucks: Memory management, swap maangment, networking, etc. Mac OS 9 makes Windows 98 look like a reliable, stable system.
This is not to say that Mac OS doesn't have a place as a server. For applications where security is critical and remote access, cost, or performance isn't a priority, it's certainly a viable option. It's perfect for the Army: cost and performance are not issues (they have a $300 billion/year budget, and if it's too slow they can just invest in better hardware), but security is a MUST.
This has real potential for locked-down servers, kiosk systems, etc. It's a bit stringent for most desktops. But it's not too hard to use.
Unfortunately this seems to have been the principle result of Microsoft's much vaunted house-keeping. Net result does not seem to be a reduction in the number of existing security bugs.
See my journal, I write things there
1) Agreed
2) No Root users? Bzzz...every user is a root user. This means if/when exploits do happen, the ability for them to ALWAYS be fatal is ALWAYS there.
3) The #1 biggest reason why remote exploits will be rare. This, and only this, is the primary reason.
4) Moot issue since pascal strings minimize that vast majority of these issues to begin with.
6) Pretty much every real OS has this concept. Mac is hardly alone.
7) True, being a minority does help. Other OS's play header tricks too. On the other hand, this also means much fewer selections in available applications which mean odds are automatically reduced in the number of possible exploits. Basically, zero applications means zero odds of being exploited. I think you can follow the logic from there.
8) Security through obscurity can sometimes help but rarely is the solution. In fact, history proves that this often creates more problems than it fixes because fewer eyes ever see enough code to fix it before it becomes a problem.
I used to run lids and grsecurity, but now I feel that the acl system in grsecurity is more powerful that that in lids.
Grsecurity's non-acl options are awesome. No setup, and almost all programs work as before (execept some programs that nedd stack execution, but that is a piece of cace to fix.)
BUT (and here comes my main point) the acl system (both in grsecurity and form my earlier experience from lids) needs more debugging. LIDS once released a version where you couldn't run (almost) any program because of the LD_LIBRARY flags, and grsecurity give me kernel panic every now and then. No problem on my system, it gives me and excuse for poking in the kernel source, but I would never use the acl on a production system.
I don't know the facts about Linux, specifically, but there is a push in the *BSD world for kernel security features to be incorporated as defaults.
The only one I recall off the top of my head is "non-executable stacks" to keep stack overflow attacks from being quite as easy. I'm sure it has other advantages, as well.
All this does is "raise the bar" for attackers. I'm assuming most of the Linux kernel security tweaks do the same.
-- clvrmnky
It seems to me LSM (Linux Security Module) is the former SELinux (Security Enhanced Linux) from NSA. The LIDS (Linux IDS) is totally independent. The news is that LSM has been accepted into the development kernel tree.
- time = money
- knowledge = power
- power = work / time
- knowledge = work / money
- knowledge * money = work
- money = work / knowledge
- therefore, as knowledge --> 0, money --> infinity!
QEDcpeterso
www.kerneli.org
All these add-ons are nice, but you can easily have a very hardened server without installing nor patching anything. Linux, *BSD and probably other operating systems have extended fs attributes for ages.
/" as root, and your system must still be up and running. No need for any integrity checker.
With standard commands like chflags (BSD) or chattr (Linux), you can mark files and directories read-only (immutable) or append-only.
The point is that once you have a working system, and if you have local access to the console, you can set proper attributes to all your files.
You then have the concept of "security levels". Once your box is in multi-user mode, the "security level" can increase, and a lot of thing will be refused by the kernel : changing firewall rules, access to kmem, to raw devices, etc. and changing extended attributes.
So even if an attacker gets root access on your box, he won't be able to alter anything except some ever changing files (something that can be solved by using an NFS mount) . And the append-only log files are really nasty, because he won't be able to hide what he's doing. Patch your favorite shells to always log history files to an append-only file to get even more fun.
On a properly configured box (that you have console access on), you must be able to run "rm -rf
{{.sig}}
Patching the Linux kernel (grsecurity, etc.) and implimenting ACLs is one level of security enhancement one can emply.
Userspace hardening (e.g. Bastille) is another.
Virtual servers sounds like an interesting approach as well (virtual servers running a grsecured, hardenend system anyone?)
But, security for things like web services do not end with kernel patches or even userspace hardening utilities.
As [...] noted here, the 'security' of Slashdot's moderation system has been shot to hell (astroturfers of various ilks, most commonly but not exclusively Microsoft paid lackeys, and outright trolls are posting at +2 and being granted moderator priveleges on a daily basis). As to whether the above troll you reference was moderated up by trolls, Microsoft Astroturfers, or a combination is anyone's guess.
The fix is obviously for the slashdot editors to begin creating a web of trust in a similar fashion to how GPG/PGP keys are managed (complete with revokation if that trust is abused). Initially only the slashdot moderators and some well known friends of theirs would be in the ring of trust, then gradually others (based upon posting content, relationships, what have you). This would at least allow the Astroturfers and trolls to have their moderation and/or +2 posting priveleges removed when they do occasionally slip through.
In the meantime, until such an approach is taken, I'm afraid the astroturfers and trolls will continue to abuse the moderation system for the foreseeable future. Numerical benchmarks such as karma simply do not cut it when trying to filter for quality of content, discussion, moderation, and meta-moderation.
Slashdot security in a discussion of security now rates a -3 Offtopic?
So, by pointing out that security for a web server doesn't stop at kernel patches, and pointing to a real world example to underscore that point (this very site), the comment is somehow now offtopic? I think this thread makes the aforementinoed example even more pointed than it already was.
Or is self-criticism now a taboo subject on this forum? Remarkable.
The Future of Human Evolution: Autonomy
I wouldn't say it secures *nothing*. In fact, I'd say it secures a lot of things many people don't even think about. But you are right, it's not as strong in the "prevent the buffer overflows" category, and most of the things it does a good admin would do by hand anyway.
It's got some pretty good file permission changes that work very well for server environments. And yes, file permissions really do matter. Even on the simplest level it will ask you to remove SUID permissions from ping, dump, traceroute, at, etc. I know for sure there's been at least one local user -> root user exploit for dump that would be foiled if it were non-suid. There was even one this year for at which allowed the same privilege elevation on RedHat versions prior to 7.2:
http://rhn.redhat.com/errata/RHSA-2002-015.html
Of course, a good admin should go through and audit which files are SUID him or herself and kill off ones which aren't used by non-root users. But this makes it a bit easier.
And yes, removing the SUID bits does make fewer commands available to non-root users, but let's face it, do non-root users really need to be able to run traceroutes and backups from your webserver?
-Matt
In what sense is garbage collection a security feature? That makes no sense.
It's not garbage collection as much as direct memory access and management. In C, it's very easy to accidentally write something that allows for the execution of arbitrary code. In Java, it's very hard.
This is similar to the way one should write banking code. For most of the programmers, there should be no way to add money to an account or remove money from an account. Instead, you just give them an API that allows transfers. That way you eliminate a whole class of possible errors.
The OP's confusion probably comes from the fact, that once you remove free(), garbage collection is the common solution.
You may want to look at the fnk (or cipherfunk) kernel tree (no this is not carried on kernel.org). The link at freshmeat for cipherfunk kernels has connections for downloading and so on. His kernel tree contains the GRSecurity patches, a fair number of other patches (eg: FreeS/WAN), and any fixes he's made to get the lot running.
Basically this guys motivation is security and stability. He puts the whole lot through a barrage of tests, and makes sure things work, or at least determines if there is a problem and makes note of it.
Any Open source proyect with more than n lines of code is for almost all practical purposes equally suceptible to backdoors if you dont trust the provider.
Where n is a number that varies depending on the computer language used, the coding styles enforced, the number of people reading the code, etc, etc, etc...
No sig for the moment.
Some kind fellow was running an SELinux box with a guest root account.
The account was powerless. SELinux is a paranoid sys admin's dream. You have to specifically grant ifconfig permission to see properties on each interface. Ping needs raw sockets access granted for each interface it wants to send pings over. etc.
Ehh... any idea how long most Mac or MS software is in development before it's made public? The main difference you see is that 1) most projects at Sourceforge are public even in the pre-pre-pre-alpha stage and 2) the realease-soon, release-often model looks like continuous change when compared to the snapshots you get every two years from MS. In reality, very few software projects, commercial or otherwise, ever declair themselves to be the pinacle of software completeness. Also, very few OSS projects ever officially cancel themselves, so you may see a lot of dormant projects that would have been canceled pre-beta at MS.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
At least an authorizations/privilege security model instead of the anyone/root distinction is absolutely necessary.
The problem is, that many daemons (like Sendmail and such) override *all* security - of course, this is absolutely unnecessary.
For example, on Argus enhanced systems you run Sendmail with the pv_asn_port privilege instead of root privileges.
If someone manages to hack Sendmail, then the attacker can do nothing else than just open port 25, while on other OSs (even OpenBSD) the attacker gains root privileges.
Sendmail does not need root privileges to run, so why should we give Sendmail root privileges?
One key to more security is the 'principle of least privilege'. Modern Unix Operating Systems like Trusted Solaris show, that it is possible to implement fine-grained privilege control in Unix kernels.
Just securing a few dozens of applications (that's what the OpenBSD project calls OS security?) is not enough.
What if I need to run some other application?
An Operating System should be able to protect data even in the case, that an application gets hacked.
Our real problem is 'root' - it should never be used for any kind of server application (daemon), but only for system administration by an authorized user. There should not be any permanent processes running as root.
LIDS, the grsec patch, NSA's sample implementation of MAC and such things are steps into the right direction.
So unless you have a completely homogenous network there is currently no way to my knowledge that you can use ACLs across machines via NFS.
As already mentioned, ACLs give users working in groups more flexibility to share file access, rather than having the admin create a new group for each new permutation. They don't really enhance security.
Idempotent operation: Like MS software, wether you run it once or often, that doesn't make it any better.
This is not specific to FreeBSD. Every BSD variant has this feature for ages AFAIK.
{{.sig}}
for those actually following this as a guideline (if anybody): I forgot to mention: make a /etc/vservers/01.conf and you need IP aliasing support in the kernel (and of course a kernel with the vservers/ctx patch).
--- Hindsight is 20/20, but walking backwards is not the answer.