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
I've been useing the grsecurity patch on the medium level. Seems to help out a bit, haven't had any problems. Performance does not seem to be affected.
If you need absolutely secure linux, use OpenBSD or Trusted BSD with the linux-compatability library.
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.
http://www.nsa.gov/selinux/
adds some intresting security features, but doesnt support x so i didnt install it on my workcomputer.
Also adds the question do we trust the NSA even if the source is avalible
Buy a Mac. ;-)
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
I was thinking about Microsoft's current activities with .net set tops, xboxes, palladium and so forth and it occured to me.
Microsoft sees a transition from stand alone pcs to portable and set top computers designed as multifunction multimedia/communication stations. Its plan is to be the only option as far as MPAA RIAA is concerned, the only software / hardware with full DRM security. I saw Linux should embrace DRM because if they don't even computer geeks like me won't buy machines running linux that won't play broadcasted digital content(cable, internet, etc) because it won't authorize.
Sorry, random thoughts.
Anybody tried them and can share his experience with us?
:)
I have a lot to contribute to this, but since I'm a hot chick, I guess nobody's interested!
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.
"kernel were written in x86" ??
is x86 a language? You mean if the kernel were pure Assembly it would not have the problems it does because its written in C?
You know C was designed more or less as a "portable assembly language" for the PDPs. That is WHY it has the buffer-overflow type problems it does.
Morphing Software
Critical systems shouldnt be on the net! If there is something that you need to insure remains safe dont put it on a machine with an internet connection. The linux Kernel is as secure as it gets most of the patches you list are useful mostly against local exploits not remote. Linux has relatively few remote problems most bugs relate to local explots. Lock your door! Run a firewall (linux makes this sooo easy!) and encrypt, encrypt, encrypt! Anything under 512 bits isnt secure and I use 1024 just to be safe. Make sure you manage file permissions properly and change your password from time to time. Thats all I can say.
There is also SElinux,
Mandatory Access Control, is also a better security Model than
Discretionary Access Control, of witch is the current model of most network OS's "out of the Box"
With MAC you have policey's the control access to services,files anything and if "something' trys to access a services it must be part of the policey that tells it what it is aloud to do, if it trys something out side the policey it fails:
kind of like a firewall's deny by policey,
here is a link to some more info about it:
http://www.nsa.gov/selinux/docs.html
Nex6
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
Feature gaps like a fox!
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
You probably wanted to be flamed, at least I hope to God for your sake you did this to intentionally draw flames, but I'm not going to flame.
Instead, I'm just going to state clearly and concisely: Look at the huge amounts of problems the security holes in Winblows has caused, and look at the problems the security holes in Linux has caused.
The proof is in the pudding, the actual track record of each OS, everything else is hypothetical bullshit.
- Do not connect the Linux box to the Internet.
- Remove your floppy drive.
- Remove the power switch.
- Lock the computer away in a safe.
Of course this has the disadvantage that you cannot use your computer anymore. But that's the price you have to pay for security...This way you'll be safe from DoS attacks, as well as other attacks from the net.
Before the days of the net, floppies were the main way to spread virusses.
All measures above only protect from the danger of remote people. But by removing the power button (and therefore the possibility to turn the computer on), even people who get physically to the computer can't do anything evil with it.
All of the above measures could be circumvented with a simple screwdriver and other normal equipment. But by putting it into a good safe, you're safe from the average intruder.
The Tao of math: The numbers you can count are not the real numbers.
YEAH! that's telling 'em. man you're right, users are so stupid. when will they learn that us sysadmins are SO smart that we deserve the reputation as pompous jerks who look down at them?
what i find disturbing is that there are STILL people like you out there, and someone's paying you to be a jerk.
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
"...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..." Did you know that a McDonalds manager makes $26 an hour and a starting computer tech makes about $8. Who is smarter? The guy wearing the paper hat or the geek..... I'll just let you think about that one.
This is how you know you're a geek the power goes out and you are unemployed and unemployable. Yes I know I can't spell
Microsoft has taken all the hard work out with Windows 2000! There is a cool GUI you can use to point-and-click your way to a safe and secure system. Now I don't have to keep up with recompiling the kernel, all I have to do is apply the occasional service pack.
People often forget that the things that make unix multiuser are great security tools. For example, for local security, people who should be able to run certain suid programs can be put in special groups, and then the admin can chown and chmod the executables appropriately.
Running applications in a chroot'ed environment is also helpful. A bit hard to setup, but once you do it, no problems.
Use tools such as iptables to restrict access. For instance, if you know that all your connections will come from *.host.com, change the rules accordingly.
Kernel patches are ugly. They try to get at the root of the problem, but they miss it completely.
The point is that vulnerable code is written by bad coders, who for some unknown reasons think that C is the best language in the universe. Clearly, they can't handle the power that C gives them and should use languages that provide memory handling for them.
... 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.
For every new protection that emerges there are people that can reverse it. Atleast if its usable. A totally safe system wont be a good tool to use since it will be locked down and hard to manage. To completely avoid remote exploits the only thing you can do is to turn all remote capabilities off or use an encryption that is too strong to break with a normal computer. The problem is that all this sucks much cpu cycles and renders the box rather slow. Use secure wan links and no connection to the internet whatsoever. As for servers go sandboxing with absolute minimal rights to memory and HD. Best would be to have completely walled off memory but current hardware or palladium doesnt allow this.
HTTP/1.1 400
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
so if we're adding kernel hooks that enable access controls lists, does that mean that a few years down the road, when Palladium hits, the Linux kernel will be able to easily implement a "sandboxed" ACL in order to become the ultimate in computer security / DRM madness?
Similar to the vserver idea is the concept of running another kernel of linux in 'User Mode Linux'. This allows you to run a virtual linux machine within you current install. This allows you to test kernel modules and patches in your vitrual system with out affecting the real system. This way, if your fake system gets rooted, the underlying system is ok.
If you restrict strace in grsecurity you cant seem to be able to debug your application under gdb as normal user but root can still debug. Its a good idea to not to play with strace option if you are in a software engineering environment.
Other than that it works like a charm.
Never learn by your mistakes, if you do you may never dare to try again
You all talk about things like linux security, and SELinux and the patches that exist to enhance linux kernels, Then theres OpenBSD, yes reknowned for its secure by default stance. Well little known to most is a project called MicroBSD, which is actually a fork from OpenBSD, but with all the systems hardening and posix1 additions available currently! Though its young in existance, like 10 months, We have been using it on our boxes here for 6 months with no problems. I think their url is microbsd.net
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 ...
There is something almost treasonous about a linux kernel hack whose documentation's primary format is msword+ppt. Particularly when the html links are broken.
nod...wink...wink ...and cost has nothing to do with this...
> 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
Actually, the rule is usually the more you make, the more stupid you are.
-- Jason
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.
I say forget trying to patch up Linux, or OpenBSD and its exploitable SSH... try archetectures like the mac for trusted web servers taht are unbreakable based on historical evidence.
:
The MacOS running WebStar as a server has never been exploited.
In fact in the entire securityfocus (bugtraq) database history there has never been a Mac exploited over the internet remotely.
That is why the US Army gave up on MS IIS and got a Mac with WebStar.
I am not talking about BSD derived MacOS X (which already had a couple of exploits) I am talking about Mac OS 9 and earlier.
Why is is hack proof? These reasons
1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT
2> No Root user. All mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stufff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root their is no false sense of security.
3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The mac avoids C strings historically in most of all of its OS. In fact even its roms originally used Pascal strings. As you know pascal strings are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits.
4> Stack return address positioned in safer location than intel. Buffer exploits take advantage of loser programmers lack of string length checking and clobber the return address to run thier exploit code instead. The Mac places return address infornt of where the buffer would overrun. Much safer.
5 : Macs running Webstar have ability to only run CGI placed in correct lodirectoy cation and correctly file typed.
6> Macs never run code ever merely based on how a file is named. ",exe" suffixes mean nothing. For example the file type is 4 characters of user-invisible attributes, along wiht many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For ecxample file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable of creating an executable file. the file type is not set to executable for hte hackers needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if the y had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually.. TOTAL security.
7> There are less macs, though there are huge cash prizes for craking into a MacOS based WebStar server. Less macs means less hacvker interest, butthere are millions of macs sold, and some of the most skilled programmers are well versed in systems level mac engineering and know of the cash prizes so its a moot point, but perhaps macs are never kracked because there appear to be less of them. (many macs pretend they are unix and give false headers to requests to keep up the illusion, ftp http, finger, etc).
8> MacOS source not available traditionally, except within apple, similar to Microsoft source availability to its summer interns and such, source is rare to MacOS. This makes it hard to look for programming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.
Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is.
One 3rd party tool created the only known exploit backdoor in mac history and that was back in 1995 and is not, nor was, a widely used tool. I do not even know its name.
Other than that event ages ago, no mac web server has ever been rooted,defaced,owned,scanned,exploited, etc.
I think its quite amusing that there are over 200 or 300 known vulenerabilities in RedHat over the years and not one MacOS 9.x or older remote exploit hack.
Not one. And that includes Webstar and other web servers on the Mac.
--- too bad the linux community is so stubborn that they refuse to understand that the Mac has always been the most secure OS.
BugTraq concurs.
you sir, are an idiot. Funny, but still an idiot.
don't apply every single patch you find on the internet to your kernel.
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.
actually http://www.nsa.gov/selinux is great for a kernel module, or even compiled into it itself. True linux has proven itself better than it's (non-exzistant) competitor from Redmond. But with this security addon it makes it on the top of it's field. I think this is why the NSA has given it it's name SELinux: Security _enhanced_ linux. To define that would denote that linux had a lot of security before, and now with this add-on is _enhanced_ in many ways. Too bad I haven't been able to find anyone who can audit the NSA's work and help verify it for obvious & hidden flaws. nzru
Oops! I did it again
Virtual machines are not perfect... they can be detected by the way they fragment memory and visible from ring 0 commands.
:
but I would say just use a mac server instead if you want security that is by far the most secure.
The MacOS running WebStar as a server has never been exploited.
In fact in the entire securityfocus (bugtraq) database history there has never been a Mac exploited over the internet remotely.
That is why the US Army gave up on MS IIS and got a Mac with WebStar.
I am not talking about BSD derived MacOS X (which already had a couple of exploits) I am talking about Mac OS 9 and earlier.
Why is is hack proof? These reasons
1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT
2> No Root user. All mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stufff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root their is no false sense of security.
3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The mac avoids C strings historically in most of all of its OS. In fact even its roms originally used Pascal strings. As you know pascal strings are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits.
4> Stack return address positioned in safer location than intel. Buffer exploits take advantage of loser programmers lack of string length checking and clobber the return address to run thier exploit code instead. The Mac places return address infornt of where the buffer would overrun. Much safer.
5 : Macs running Webstar have ability to only run CGI placed in correct lodirectoy cation and correctly file typed.
6> Macs never run code ever merely based on how a file is named. ",exe" suffixes mean nothing. For example the file type is 4 characters of user-invisible attributes, along wiht many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For ecxample file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable of creating an executable file. the file type is not set to executable for hte hackers needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if the y had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually.. TOTAL security.
7> There are less macs, though there are huge cash prizes for craking into a MacOS based WebStar server. Less macs means less hacvker interest, butthere are millions of macs sold, and some of the most skilled programmers are well versed in systems level mac engineering and know of the cash prizes so its a moot point, but perhaps macs are never kracked because there appear to be less of them. (many macs pretend they are unix and give false headers to requests to keep up the illusion, ftp http, finger, etc).
8> MacOS source not available traditionally, except within apple, similar to Microsoft source availability to its summer interns and such, source is rare to MacOS. This makes it hard to look for programming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.
Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is.
I think its quite amusing that there are over 200 or 300 known vulenerabilities in RedHat over the years and not one MacOS remote exploit hack.
not one ever.
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.
No Debian package... :(
Buy an abacus and a typewriter.
Sample here.
What part of "gestalt" don't you understand?
This past January-June, I worked on a project involving LIDS. I was responsible for all the setup/maintenance. Setup for LIDS is extremely easy. The difficult part is setting up the ACL's. For a complex system with many daemons running, this might be a difficult task. Fortunately, you can find plenty of people who make their ACL lists public, so you can see how to setup common things such as Sendmail, Apache, SSH, etc. With a good ACL list, your box will be as secure as it can get. With constant attacks on our LIDS box, no one ever got total control. The one time we let someone get root (for research purposes), that person was not able to do anything (even root can be made to not have certain accesses). I highly recomend LIDS to anyone looking for a more secure linux.
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.
I work in a small company, with a small server room. It has two RS-9000, one compaw tower, and one HP LH-somthing. The information isn't really worth stealing, and you would have to walk through the entire IS department to get the hardware out.
Yet, we got slapped by our corporate owner's internal audit for leaving the door open. We now have to keep it closed at all times. Unfortunately the IT department is so understaffed that everyone has reason to be in that room, we don't have the resources for a dedicated operator that can serve our development needs and the actuall day to day needs of the company.
So there is one key, where everyone knows where it is. This isn't protecting anything, ever. Sure physical security is important, but should you weigh the risk?
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
do you have that weird, queasy feeling in your stomach? wonder what it is? you've been trolled, fool....
By taking the time to respond to it, what does that make you?
You can find the site at MicroBSD>Net
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.
You can find the Site at MicroBSD.Net
Macs have astounding performance...
For example.. a stock Dual 1 Ghz G4 mac performs over TWICE as many RC5 keys per second as the fastest dual AMD MP motherboard.
And that mac is under 2999 dolalrs and comes with DVD-R burner (a 300 dollar value).
TWICE as many RC5s per second than an AMD, probably because Macs have huge L3 caches, and no AMD have a L3 cache.
Also Macs can read and write simultaneously to a cold page of ram faster than any AMD mother board can. Perhaps RC5 benefits from this as well.
Mac file system is fast too... very fast compared to most UNIX filesystems.
http://projectfiles.com/firewall/ It looks simple...potentially a good thing. Anyone have experience with this yet?
One of the best ways to keep your system secure is to keep it simple: remove daemons, remove kernel modules, remove software you don't need, etc.
he's saying that OBSD IS well documented if anything (you seemed to interpret the negative), that is in addition to his saying he thinks that it is "quite good"
What are you? A moron or something? Let me guess. The only reason you can possibly use a computer is because you have a mouse. This is such a bunch of bs. Security at Microsoft is like white shit. It doesn't exist until it's so old as to be un-needed. Personally, I believe in the right tool for the right job. MS or Unix(Linux), doesn't matter. I do what the customer wants. Security wise, I know better than to trust anything M$ does or says about security. Their track record speaks for itself. As far as Linux goes, no flames here, I like it, I started with it, but BSD makes my life easy, and you can't beat the security auditing that OpenBSD goes through. Not to mention; lately, OpenBSD runs better on antiquated hardware than Linux used to.. So much for keeping the kernel small and lightweight.
Goes post on MS newsgroup you asshole. Maybe you can find some dumbass to believe you long enough for you to get paid.
at sourceforge has been in dev for years
Opensource is great, but takes way too much patience to get anything done...Linux is coming along great, but look how hold it is
LOL
XServe is a better compared to a Sun Netra T1 than a "linux server".
Most linux servers are junk. VA made some of the biggest piles of junk. Those 1st gen boxes? LOL. FullOn? BAH, garbage.
Penguin Computers? junk.
Compaq makes nice boxes, and they do run Linux.
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
i'm going to make a point
weather you listen or not is up too you
number one reason a mack server has never been hacked ? what companies run them ? like the other poster said there internal memory management sucks. and yes for most people running a server PERFORMANCE MATTERS.
next is the interest level, what l33t hacker would be even the slightest bit interested in this ? i have not yet seen or heard anybody in the community talking about how 'hard' or 'interesting'a mac hack would be. because nobody who matters (big companies, banks etc..) run them.
and source being availible or not doesnt matter , it never has the problem with bugs being easier to find is offset by the speed a fix is availible. look at NT4 it has an estimated 65,000 bugs. nobody can find them because the source isn't there right? WRONG ! all it takes is some creative testing and reverse engineering and you can find them. conversly look at red-hat 300 known bugs right ? how many of them are patched ? 99% ? and of the ones that are not how easy are they to exploit ?
either way it comes down too one thing. intelligence of the admin. servers were nt and are not made for joe schmoe to run. PERIOD all these people who complain about how 'hard' it is too admin a unix server SHOULDNT be doing it in the first place.
oh and i'd also like too point out that unless a blackhat wants to go corporate he wont go for a cash prize because it puts the spotlight onto him. and that is a BAD THING (tm) when your are doing "illegal things"
"Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." --Albert Einstein
I quote from Usenix88:
Indeed there are ways to do closures without an executable stack, usually by modifying a stub that resides in the text segment of a binary, but it's much nastier.Better would be to use other existing tools for buffer overruns IMHO.
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.
Think... What is the single most unreliable "trusted" element of your security setup? Your staff.
Be nice to your PFY(s) people! :)
Ali
Ph33r m3!!!
And -- I'm sorry to break you the news. But I used to work at an ISP whose pages where served in a WebStar... Till somebody erased all the clients' pages twice... And then I put an RedHat/Apache/Intel in its place. Worked like a charm...
Nice troll.
In what sense is garbage collection a security feature? That makes no sense.
I'm sorry I can't give a better reference, but search google for "virtual machine halting problem". Vaguely, if a virtual machine does not have garbage collection, proving that some code is "safe" (in the sense "will not dump core") is tantamount to solving the halting problem. So GC is relevant to the security of VMs. For java, at least, this form of security is most important for applets running on the client side. For C, garbage collection would be useful simply to discourage use of static fixed-size buffers by encouraging the use of lots of dynamic memory management. But that's an issue of practical code habits, not computer science.
- 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
EOF
You must feel kinda silly now that the recent OpenSSH ChallengeResponse bug can root a default OpenBSD remotely in seconds...
I don't consider myself a full-on security guru, but from my experience, Immunix has a very good track record. Crispin Cowen has published many white papers concerning the stackguard compiler and how it will prevent buffer overflow attacks. Combine this with FormatGuard, and a resonable price ($100, free for non-commercial use. Check it out at http://wirex.com/Products/Immunix/purchase.html.
Don't forget to use Bastille to harden it after you install. Or you could do it manually, than you will need to remove SUID crap, use CHATTR to make your critical conf files immutible, and many, many other tricks. You can read about it http://www.bastille-linux.org/. Hope that helps.
I may be bad with names, but I'll never forget your IP address
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}}
...their existance points at a deeper problem. The linux security model is based off of the unix security model which basically expected users to do two things:
1. Log in through a text mode terminal.
and
2. Run programs (i.e. use cpu time and memory).
Since the demands of computer users began to expand beyond those original expectations (graphical interface, selective access to administrative abilities, etc...) the solution has always been to write a suid program that simply snags root priveleges and tries not to let the user do anything bad while it's running. Sure, it works, and linux-based systems have come a long long way, but the fundamental problem remains: to the OS, a user is a user is a user (except root). The linux security model hasn't expanded to meet new challenges, it's been circumvented by suid programs and as a result instead of a single point of possible penetration (a problem with the kernel) there are hundreds of possible ways to take over the system and hundreds of programs that must be maintained in order to keep the system secure.
Yes, chroot is an absolutely beautiful solution in many cases. No, I'm not saying linux is terribly insecure. What I am saying is that a new philosophy needs to be employed in designing security models: if a program has to become root (or the equivalent) to perform its function, something is wrong with the security model. It seems to me that this kind of thinking, combined with an elegant system to keep track of who is allowed to do what, would do wonders for the maintainability and usability of linux based OSs.
Like we all buy computers to leave them around running RC5 code... A single cpu AMD will smoke your dually G4 at mpeg encoding by 70%, and that will cost you less than $800.
One of the biggest problems with SELinux is the non-trivial effort involved in creating policies. It took me a couple of nights just to get to grips with the concepts...
There's a real need for some sort of tool that just builds and manages simple policies for daemons, apps & utilities. Problem is, that sort of thing is best built upon a sound model of the policy. apol (http://www.tresys.com/selinux.html) has something, and there's work going on at IBM (Alphaworks?) and at MITRE, all of it very cool stuff, but it's a) geared towards analysis, and b) proprietary.
Bastille linux is a hoax.
It doesn't secure anyting at all.
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
Erasing pages is one thing.
But turning your linux machine into a staging point for going after other targets is another, more serious problem.
The only reason one would consider using a pre-Mac OS X server is
1) Without memory protection, a random buffer overrun attack may lock up the computer, a better situation than just crashing the app and letting the system go on.
2) If the attacker does manage to subvert the program, it's impossible to start up a remote command shell.
3) If the attacker does manage to get a remote command shell going, it's impossible to find command-line applications installed on the Mac that will allow downloading of files and the installation of backdoored programs.
4) Making a compromised Mac a dead end deal, ie. nothing much else can be done.
Issues with webpages being deleted can be easily worked around with a good backup/replication/etc. Hell, have the webpages served off a read only AppleShare that's connected to the actual webserver, the attacker won't be able to alter your web data.
I know you're all too lazy to read the entire release notes, so jump directly to the source of these tools. RedHat's release notes say:
This beta contains a kernel providing EA and ACL support for the ext3 filesystem based on the patches and user-level tools from http://acl.bestbits.at/
So, check them out directly. They have more information than the RELEASE-NOTES, and some useful examples.
don't just make an assertion, back it up. unsupported claims are pointless.
you may have a point to make, but you didn't make it here; you didn't teach us anything.
if i'm a grammar nazi, you're an illiteracy nazi.
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
1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT
Macs have AppleScript which allows a script to do basically anything a shell could. If someone breaks in, they need only activate an AppleEvent to download some trojan code and execute that trojan code.
3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes.
This is an excellent point, but buffer overflows can occur with arrays and other data structures. Furthermore, while the OS may use Pascal strings, applications that run on top of the OS can use any type of string they choose.
5 : Macs running Webstar have ability to only run CGI placed in correct lodirectoy cation and correctly file typed.
Where is this enforced? If Webstar is enforcing this, once someone breaks into the system, it will make no difference. The intruder is already root.
6> Macs never run code ever merely based on how a file is named. ",exe" suffixes mean nothing.
It is a trivial matter to change a file type.
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.
Owl is something that I admire and would even run if it wasn't based around RPM. They've managed to create a system that could probably be run without any suid programs.
/etc/shadow into a tree, and each user has its own fragment that is only writable by that user. There's a bit of glibc/nsswitch magic to use that tree instead of the usual flat file, and the rest of the system just works as before.
Even chfn and passwd work, since they have split
There are other "duh, why didn't I think of that" changes, too. Think about it - why do syslogd and klogd keep root after starting? klogd needs to open a socket from the kernel. After that, does it need root? Nope. syslogd needs to be able to open logs and sometimes bind to a privileged port. Guess what, a user called 'syslogd' can open log files owned by syslogd, and it can drop root after it grabs that port. Owl also chroots klogd into a jail to keep it out of trouble once it starts.
I look forward to seeing this kind of cluefulness in other distributions, since it's obviously correct.
I wonder if this person works for StarNine?
Same post, different topic...
[RIAA] says its concern is artists. That's true, in just the sense that a cattle rancher is concerned about its cattle.
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.
1. Add a sys call to disable insmod to prevent crackers from inserting Trojans and Root Kit obscuring modules.
2. Disable processes from listening on high ports (above 1023, except possibly socks, NFS, or X if you're crazy to allow these on a server). It would be trivial to add this to the kernel.
3. Disable other than low numbered processes from listening on ports, if all of your servers start at boot time and don't need restarting.
4. Prevent creation of symlinks in dirs (such as /tmp) with the sticky bit on unless they point
to files owned by the creator. This reduces
popular symlink attacks. It might be possible to
block all symlinks here with most servers' mix
of processes.
5. Disable fchdir() and mknod() to prevent root's common way to break out of a chroot() jail. (Disabling /proc, /dev/mem and /dev/kmem, etc.
also will be needed but those aren't kernel mods.)
Keeping up-to-date w.r.t. security patches, running different servers on different systems to limit damage from an intrusion, using a good Adaptive Firewall and IDS, etc. will go a long way to conventional security as will using the LIDS, WireX's SubDomain, or NSA-enhanced kernels.
Those worrying about a NSA-planted bug in their kernel need only put a non-NSA Linux based Firewall in front to detect unexpected packets.
These and other ideas are from my book.
Bob Toxen, Author, Real World Linux Security, 2nd Ed.
Security Consulting,
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.
It is stupid, but it means that even if someone does have an exploitable buffer overflow, their easily available rootkits are unlikely to do anything useful.
There was an example a couple of years ago where a Mac running Linux was left up in a default install with a "crack me" contest. (The prize being the Mac. After a couple of days they also handed out the root password.) After much effort and publicity (it got a lot because the contest mocked a parallel Microsoft stunt to test Windows 2000), the machine was eventually broken into, by someone using a well-known buffer overflow that had been public when it was first set up. Even though there were standard rootkits to exploit it, they were all x86 based, and wouldn't work until someone rewrote the necessary assembly code for the Mac.
In other words, using non-x86 hardware raises the bar. A lot.
Here is an Idea for easier security management through ACL's.
/bin and /usr file systems would automaticly be traversable, but directory listings,file reads, and file writes would be impossible for such a proccess.
Add a file system capability mask. This would be similar to the Group and Other file permissions, but would block those permissions.
For instance droping the "rw" capability from the "other" and "group" masks would cause this proccess, and all it's children to be denied access to files that it doesn't own (services should not be run as root of course), but still access files owned by it's user or files/directories explicitly given access vi ACL's. This way a user could grant access to everyone for his/her directory, but system process couldn't be coerced into reading that directory, or any directory. An admin would have to explicitly grant access for a system service. The whole
Is there any project doing this? Is this even a good idea?
LIDS is a great second defense. It comes into play when some cracker manages to get on your machine. If you set up the rules correctly, they won't be able to install their rootkits or will be easier to spot.
The only problems with LIDS is setting it up. Since every Linux distribution writes files to different areas. If you declair a directory as readonly or append only and a program wants to delete a file, you might have problems.
If you have a webserver or a machine in production that is contect to the internet, LIDS can be a good investment (time that is, it's free)
>What sort of problem were you having?
As I walked through the instructions, at some step or other it became apparent that the LIDS build process was wanting to modify the machine it was currently running on, or at least it sure looked that way. Since the build machine wasn't the target machine, I immediately stopped, and haven't ever had time to fiddle with it, again.
I'll also have to check out the sample SELinux security policies another responder mentioned. That is, once I get that increasingly rare commodity called "time" again. The dishwasher went on the fritz tonight and leaked, so after a little work tonight, tomorrow night will be repair, then some bin and paint in the basement ceiling after that. Then back to the scheduled home projects backing up.
The living have better things to do than to continue hating the dead.
RBAC is the most adequate solution to manage security of collaborative environment. Read more here:
"The principal motivation behind RBAC is the desire to specify and enforce enterprise-specific security policies in a way that maps naturally to an organization's structure.". Briefly, it's like a RDF graph: you have subjects and privelegies mapped to each other (M:M) using roles, which, in other relationships, hierarchically describe users.
They have some example for Linux. I've tried its concepts in few applications and found really it very naturally and intuitevely reflects security requirements in commercial systems. Oracle and NT security models have something similar, although NT domains are not nested while in Oracle the role graqph is not really hierarchical (acyclic though).
I've read about NSA SElinux and found they show a very good progress, but it's just a beginning. I believe that RBAC eventually will come to Linux (and to BSD after that?). Nothing is impossible in Linux (and in BSD, lol).
Less is more !
NOO! Microsoft definitely does not know what thier code does.
OpenBSD not only has more security, but you can leave it out for longer without having to remotely upgrade. Ever remotely patched/installed a kernel? It's quite, quite annoying. Why is it you can do this? Less holes AND more highly integrated code... plus, once you add in that the memory allocation routines in OpenBSD are quite extraordinary (try running X at a high resolution in linux, then run the exact same thing in openbsd... you'll see the difference in magnitudes ^_^), so its harder to overload your memory. Just a thought.
The dream reveals the reality which conception lags behind. That is the horror of life- the terror of art. -Franz Kafka
Try this. Go to http://www.hp.com/security/products/linux/eval/ and get it. Or wait for version 2.0 prob. this fall. Set up "compartments". Run applications in compartments, by default nothing is allowed except local console on reserved sys compartment. Communication between compartments is only allowed by explicit rule sets (IP, port, file access, etc). Network interfaces are compartmentalized. Compartments are chrooted, no raw sockets, no telnet, lots of other goodies. Includes default setup for Apache, Tomcat and other stuff.
Yes, but my linux box, can handle much more traffic than your Mac box. sorry buddy, in the real world, macs just don't cut it.
--p06
-- p06 "On religious wars: They're essentially wars over whoo's imaginary friend is better"
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.
A totally paranoid OS is rejected by paranoid people. ITs also funny how people say how nuts you are to run NSA linux while recommending installing LIDS (built by China).
:)
People can be so entertaining at times
-- "of course thats just my opinion, I could be wrong." --Dennis Miller
Not EXTERNALLY. All the points about why no mac in HISTORY has been remotely exploited is because of those original points.... no way to get executable code into the machine.... at least historically.
If you want ,speed,and do not care about security run
Apache on a mac, because Apple demonstrated 20 months ago that the mac ran apache in a benchmark far faster than any other computer similar
in cost.
The Mac OS running Open Transport, based on open protocols, and bilevel protocol stack declaration order is amazing. It avoids lots of famous TCPIP hacks and it also allows end-to-end file transfer from ram to ram without copying a single data byte! (only pointers to buffers are passed end-to-end in the most ideal situations) There are also papers that discuss proper tuning of open-transactions vs queued transactions and how to get the most astounding hits per second from dynamic webstar content.
It does not raise the bar.. all intel stack exploits for LINUX can be trivially rewritten into PowerPC, and tutoraials have been written.
.exe extension can be executed!
1> There is no command line shell to allow redirection. No shell, no shell exploits or redirection of scripting.
2> Everyhing is 'root' at all times so programmers do not get lazy and fantacize about the existance of a more secure root to help protect them. The Webstar server, and other servers, as most mac programs, is written knowing that security is is important and that the code is running at root. Truthfully, PowerPC apps run at user-level, and Gary Davidian's birthdate needs to be passed in a register to gain true supervisor level, but no normal benefit is gained on a mac from running in the microkernel space or debugger-nub space.
3> Macintoshes do not suffer from stack exploits based on buffer overruns of C style strings. The mac uses Pascal style strings, instead of slow null-terminated strings in most all aspects of the entire operating system and in most users code. ANSI-C libraries are traditionally shunned. Pascal style strings are not only faster, they prevent the vast majority of buffer overrun problems.
4> Macintoshes do not EVER exucute code from file that are simple data files, no matter how the file is named or no matter how the file suffix is generated or set. Macintoshes use dual fork files, and text files and data files traditionally cannot easily become executables, and firthemore would typically need to have their 4-byte FILE-TYPE set to a value to even begin to allow a hackers file to be blessed for execution. Webstar and other tools do not typically allow any hacker or rougue tool to set file types by accident or on purpose. On a wintel system a text file saved with a
5> Source to mac os (pre os X) is not typically available outside apple corp. This is not a valid argument for security, (obscurity) but the appologists for the copious amount of linux redhat exploits use this as one reason for the many bugtraq exploits coverred.
6> The Mac OS weservers running Webstar do not automatically allow errantly saved files from executing out of the CGI bin merely because they are stored there.
7> The Mac OS has other good multi-homing multi-domain tools that run on it for robust free email (SIMS), DNS (QuickDNS Pro), FTP (Rumpus) and all have nice user interfaces to configure them and though these commercial tools may not be technically as secure as Webstar itself is, or the MacOS, I prefer them over running any open source tools on FreeBSD,NetBSD,OpenBSD,Linux, etc. Free is only free if you value your tech support at 0 dollars an hour sometimes. Plus, these other non Webstar related tools seem to have mostlty unblemished histories, unlike BIND.
8> People on the mac tend to use scripting languages based on Applescript rather than perl for os level dynamic work and protecting against some minor perl problems, or unix scripting (no command line on a mac, thankfully). I cannot attest to java as being swell, but the fact is many mac people tend to do dynamic content in straight C. Happlily Webstar includes a rich variety of trusted dynamic content assist tools.
9> Stack return address positioned in safer location than intel. Buffer exploits take advantage of loser programmers lack of string length checking and clobber the return address to run thier exploit code instead. The Mac places return address infornt of where the buffer would overrun. Much safer.
In fact in the entire securityfocus (bugtraq) database history there has never been a Mac exploited over the internet remotely.
A rare set of documentation tutorials and exercises on rewriting all buffer LINUX exploits from INTEL to PowerPC was published less than a year ago. The priceless hacker tutorials were by a linux fanatic : Christopher A Shepherd, 3036 Foxhill Circle #102, Apopka, FL 32703 and he wrote the tutorials in a context against BSD-Mach Mac OSX.
He was motivated by Phrack issue 49 (an intel article).
Believe it or not, I do lock the computer room door.
But the Ruskies still hack into my systems !
Looks like the do know some (undocumented ?!)BACKDOORS of Linux systems.
Where to find the info on those (undocumented ?!) backdoors in Linux ?
I am interested to know !
Muchas Gracias, Señor Edward Snowden !
Citing from their page: Key features:
Will NSA's Security Enhanced Linux stops the Ruskies from hacking into my systems?
I'm tired of searching high and low for security tips, applying patches and such, and still having the Ruskies prying open my systems with no problem.
Methinks there's a list of "undocumented Linux vulnerabilities" out there, and the Ruskies (amongst the others) are using it to hack Linux systems.
If there's such a list, I'd like to take a look at them. I'd like to close all those holes.
Anyone has the list ?
May I borrow it, please ?
Muchas Gracias, Señor Edward Snowden !
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.
Oy vay, mod down oredi ?
Oy vay, mod down oredi ?!
This is not specific to FreeBSD. Every BSD variant has this feature for ages AFAIK.
{{.sig}}
Medusa http://medusa.fornax.sk/English/project.shtml
is a set of patches that help you secure your Tux kernel. I donot have an indepth knowledge of the workings, but there was an article in LinukJournal http://www.linuxjournal.com/article.php?sid=3811
I think this might help
Incorrect -- There are fewer explots for MAC OS[anything] because frankly the security community couldn't care much less about how may ways you can exploit all of the three MACs connected to the internet :-)
For testing we have a Red Hat 6.0 based demo server running various services with known and unknown security holes: sshd 1.5, qpopper, wu-ftpd 2.6, Apache, BIND 8, and so on. These are original unpatched services, no firewalls, the only extra thing there is SecMod. The module has been configured to "sandbox" these services, and has done well enough to protect it for over two years from daily compromise attempts. We also offer free user accounts on the server for anyone who wishes to try local exploits too.
Creating the rule chains to configure the module is quite simple. The most common way is of course to define rules saying "this daemon program can't read any file except this and that, it can't execute anything but that, and can't do any syscalls except those, and can only write to this file. If it tries anything else, deny it and add an entry to syslog.". This has proven an effective protection against security vulnerabilities.
You can do many other things with these rules, for instance define ones saying "no-one is allowed to read these files (even root), except the file owner and users in group X", or "no-one can read this file with other program than 'pico'"... It's also possible to easily define chroot operations to be done in wanted circumstances, in other words "when user Z runs this program, create a chroot jail here".
For anyone interested there's more information available on www.secmod.com. The demo site address is demo1.secmod.com. --Jouko Pynnonen , Online Solutions Ltd, Finland
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.