New Security Module For Kernel 2.5 94
CelestialWizard writes: "After the Linux Kernel 2.5 summit, a new security model is to be created for the next kernel. You can see the post from Cripsin Cowan on BUGTRAQ. " Interested folks should look at the mailing list; my guess is this is gonna be for the techies only.
New security model? (Score:1)
Re:crazy curveballs (Score:1)
I'm currently developing Ultra Secure and Cool Linux for the CIA. It is estimated to be atleast 3.42% more secure than NSA Linux.
One of the things that we had to develop is a "Read this message once and destroy it" feature into the Linux kernel. Our spies were not deleting the messages or were doing it improperly and the Russians were finding out all of our secret plans.
With the new 2.5 kernel it is trivial to implement this new feature so that if someone opens the file once (regardless of which application they use) then we delete it right away. Just like they do in the movies.
Hope this helps.
Re:Ouch (Score:2)
No reboot required (Score:3)
Whaddya think this is, Win95?
Re:This is an unnecessary concession (Score:2)
To you and me that does not matter at all. The guy who runs a web hosting firm has a differet set of issues and so on.
Re:what sort of modules? (Score:3)
Your app is PAM aware. You want someone who is ftping in to be authenticated by RADIUS, you set the pam.d/ftpd file up to allow that. You want SMB also, you add that...and so on. Once your app is PAM aware, it does not care what happens on the back end - it says I have this userid and this password - is it valid? YES or NO.
now, on the kernel end, applications don't really need to be modified. There are C calls which deal with files (fopen/open namely). Unless you deal directly with the FS (you sicko!) your app/shell will eventually use these.
(I get a little fuzzy here.) Basically, the libc will tell the kernel "I have this uid accessing this inode - is it okay" and the kernel then decides. Instead of having pam_modules, it may have ACL modules, or a module that only allows access if they are logged in from a certain IP#, or only if the parent process belongs to a certain program.
Behind the scenes, the kernel file system security can be configured however, and you either get a file pointer or EACCES returned to the open/fopen call.
I think this sounds great and allows a lot more flexability (and complexity) in the rather minimal unix security model.
Back when I just a young Slashdotter... (Score:2)
...we really had to work for our Karma points. There wasn't any of this "whoring" crap going on.
Damn you little bastards!!
We also had to walk to school. Five miles uphill in the snow. Both ways even.
You youngsters nowadays don't know how good you've got it!
well which is it? (Score:1)
--
Re:Security in modules? (Score:1)
The wheel is turning but the hamster is dead.
Re:what sort of modules? (Score:2)
The same way CA_Unicenter implements security as a loadable module in (at least) Solaris. It inserts a few modules that intercept and reruote filesystem access calls, and run them through their security module to see if user X has command Y in their allowed profile, and if so, runs it.
Re:Why not config-option? (Score:2)
Because if it's a permanent code entry, then it has to be changed in the kernel to implement new algorithms and such.
If it's a module, then the API is exported from the kernel in a number of structures, and you can implement whatever type of security thing you want. A few ideas I've seen scroll by:
In fact, there won't have to be anything in the kernel that you will need to explicitly configure. It will be some additional information in the loadable kernel module model that new modules can take advantage of to implement security functions.
Re:crazy curveballs (Score:1)
They aren't talking about 'is my housed securely locked up', they are talking about 'does the door in my house come with holes in the door for locks and strikeplates for the bolt'.
They are trying to make sure you can buy any lockset for your house, without having to mortise in the parts and drill holes in the door.
Linus doesn't care, beyond bug fixes, whether the kerenel is the antithesis of secure OSes, from the kernel side. You can't compare oBSD to Linux because Linux is a kernel and oBSD is an OS distribution.
Security in modules? (Score:2)
Equally obvious is that if someone can put a rogue security module on the system they can probably put a rogue kernel on the system, so this is likely not a real issue. However, it is something that should be addressed to make sure tha the system is as tightly integrated and unabusable as possible.
A Firewall won't hack it (Score:2)
When my web browser connect to port 80 somewhere, I don't really care. When my new email program or game tries to connect to some third world server with no DNS info, I care. The only place that you have any hope of controlling this is in the kernel.
I would love to have this kind of flexibility. Netscape: port 80 only. Mail: 25 and 110. New binary-only game I'm trying out: nothing
Re:crazy curveballs (Score:4)
FreeBSD and OpenBSD may audit their code to make sure that what they have written is secure but that is something completely different from writing code that does what I want it to. Almost all variants of unix are still stuck in a decade's old world view of security, which is ironic since that's what many unix users make fun of Windows for.
Things like implicitly giving uid 0 god like powers, or thinking ports under 1023 are somehow more special than those above.
Projects like SELinux provide Mandatory Access Controls. Granted, I haven't looked at OpenBSD in a while, but I've never heard of any project to provide MACs for OpenBSD. Which is too bad because proper MACs significantly lessen the need for in-depth code auditing. When programs can't misbehave it becomes less important to audit six hundred million lines of code. And what do you do when you don't have enough man power to audit everything that needs to be audited? Have you ever looked at how little code OpenBSD actually audits?
This isn't about patching a hole is a tire. Audits aren't even relevant.
Re:This is an unnecessary concession (Score:1)
Screw the marketing game, that's not the kernel developers jobs. For the most part, I wouldn't be suprised if they don't give a damn about the success of RedHat, VA, SUSE, Caldera or anyone else that makes a commercial Linux distro. Has it crossed your mind that maybe theyr doing it NOT for money, but to have the best product possible? Sometimes that means that we -HAVE- to admit to there being a fault. It's the only way that someone is going to go "Oh SHIT! this needs to be fixed!" and then to FIX IT.
What the fuck are you talking about with a closed source version of Linux???? That's 1. impossible due to the entirety of the tree being GPL'd, and 2. see #1. It's not going to happen. PERIOD. End of story. Security by obscurity DOES NOT WORK. The failures of MS to adequately secure -anything- that runs on Windows is an example of just how poor that philosophy is. Hackers WILL find holes in anything, if those holes exist. The best we to prevent holes is to design the app, and be a bsolutely anal retentive when writing the code that you handle -all- possible security breaches.
Jeseus, what a crock of absolute SHIT.
Re:what sort of modules? (Score:1)
ACLs would not only be for file/directory access but for Sockets and devices as well.
This would need to be linked in to the code that handles permissions now -- sort of like an optional extra step.
--
Charles E. Hill
Re:Security in modules? (Score:4)
Installing the initial modules on a fresh install from trusted sources. There are already definitions of "trusted sources" in the industry -- pick the one that suits you best.
ACLs and user compartmentalization. Right now, root==God. In a "trusted" system, this isn't so. Users, including root, are assigned certain rights and if compromised, only those rights are compromised. There is no one account that if breached, compromises the entire system.
Who can install kernsec modules would be very specific and tightly controlled.
--
Charles E. Hill
The link is a nice list of whats missing (Score:1)
Re:crazy curveballs (Score:5)
A security model is about defining how users will be given permission to perform specified actions. The message gives an example of the POSIX model. Others are possible. You can choose an ACL based model, or a highly restricted class/access or simple user/group/world RWX like unix of old.
Installable security modules allows the user to select what TYPE of security they want to use. Whether any of the implementations of these has holes is up to the implementers. We would prefer that the implementation be well audited as well as well defined.
This has nothing to do with BSD being better audited or better tested. Each of the BSDs has its own model, but just the ONE.
This installable security model is a very good thing for Linux. It allows choice for using linux in areas that require widely different types of security methodology.
Convenience... (Score:2)
Re:well which is it? (Score:2)
Re:No reboot required (Score:2)
Re:No reboot required (Score:2)
Re:crazy curveballs (Score:2)
Security modules are about defining new types of policys. You can go a long way on POSIX file permissions, but sometimes you want the extra level of flexiblity that systems like SELinux and LIDS allow. Perhaps they should be called "Security Policy modules" or just "Policy modules", instead.
Check out the selinux and LIDS web pages for more information on what these patches actually provide.
for the techies only? (Score:2)
And how many of that minority read slashdot?
Hmm... (Score:1)
Trundle back to your hole before you catch a clue.
Re:You forgot: (Score:1)
-----
Yay, permission system that doesn't suck. (Score:2)
1) They're too complex.
Er, no. An ACL can be as specific or as simple as you want - rwx permissions are much more complex than a single line ACL. But when you want to be able to set some fine grained permissions, they have the ability to do that. rwxs doesn't.
2) There's no practical use for them.
Oh please. I have some word processor templates on a Linux server for a client. They document templates which contain business sensitive information. This isn't an unusual case:
* The owner should be my own account
* The software group needs read, write, and SetGID permissions
* The staff group needs read permissions
* All other accounts should not have access to these files, as they contain business sensitive information.
I could get around this in a number of ways, but they're all rather hackish.
3) NT uses them and NT sucks.
Grow up. So does Trusted Solaris, TRIX and Trusted BSD. So does Squid and (IIRC) Bind. Regardless of that though, there's no reason to discount a good idea because a company you dislike uses it. In fact, its pretty childish. Its nice to know this usually comes from trolls rather than anyone who works on major Linux based projects I discussed this with at conferences and on mailing lists.
what sort of modules? (Score:3)
Ultimately, these issues are all going to get discussed in gory detail, but might as well start the discussion here...
Re:Why not config-option? (Score:2)
Re:This is an unnecessary concession (Score:1)
BSD? Secure? (Score:2)
Your OS is only as secure as the tools you use. You could make Linux Really Really secure by running no servers on it. You could make BSD really really insecure by running insecure servers on it. How many BSD servers out there are running vulnerable NTP servers, for instance?
I'm not slamming the BSD practise of auditing their code, mind you. I did source code auditing as part of Data General's DG/UX B2 certification and we caught a lot of problems that way, but security doesn't end there. Claiming any one thing is the Be-All and End-All is just plain wrong. I wouldn't hire a system administrator whose sole security plan was "Install BSD." Nor would I trust auditors to catch every single hole, and it only takes one to compromise a network.
Nice troll (Score:3)
Linux thrives precisely because this kind of experimentation takes place -- because this kind of experimentation is possible. And while the PHB's may believe that a product can be secure enough, any systems guy worth his salt will tell you that no system is ever secure enough. Striving to make code more secure is never a bad thing. I would be much more concerned if the kernel developers came forward and said "We don't need to worry about security anymore -- our system is secure enough."
I would like to see more effort put in to development of interfaces to existing security features, though. There's not be a lot of movement to incorporate linux-privs into anything (The LIDS guys are the only ones I know of who are doing anything with it.) All server code should be using Linux privs at this point.
Re:This is an unnecessary concession (Score:1)
Reid Hochstedler
The actual post (Score:5)
Modules that can be loaded, or not, are the obvious solution, but the current LKM does not export sufficient hooks to support many security mechanisms. Thus many current security enhancements end up existing as kernel patches, which marginalizes their utility by making distribution problematic. The proposed solution is to enhance the LKM with a variety of new kernel elements exported to the module interface, so as to support a reasonable variety of security enhancements.
We have started a new mailing list called linux-security-module. The charter is to design, implement, and maintain suitable enhancements to the LKM to support a reasonable set of security enhancement packages. The prototypical module to be produced would be to port the POSIX Privs code out of the kernel and make it a module. An essential part of this project will be that the resulting work is acceptable for the mainline Linux kernel.
The list is open to all. You can subscribe here http://mail.wirex.com/mailman/listinfo/linux-secur ity-module [slashdot.org] or by
sending e-mail to linux-security-module-request@wirex.com [mailto] with a subject
of subscribe.
Crispin
You forgot: (Score:1)
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Re:You forgot: (Score:1)
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Re:No reboot required (Score:1)
I'll have to download it when it comes out.
Nonsense (Score:2)
--
Re:This is an unnecessary concession (Score:1)
See module/model. They're different. I don't think that there is any sort of unified "security module" for Linux, as you seem to suggest. Are you referring to something I don't know about?
By the way, I don't believe that you are saying that closed source is a way to enhance security. While open source allows security flaws to be diiscovered, that is the point-- that discovered security flaws in open sourde programs are quickly fixable and easier to find than say, closed source binary-only products.
Re: answer some questions (Score:1)
Auditing can help.
Security models can help. For example with SELinux you never have to worry about having a root exploit. Never.
Both are important.
free karma!!! woo hoo! (Score:5)
It's a fairly informative email that describes what the modules would do and what the reasons behind it are.
http://mail.wirex.com/pipermail/linux-security-mo
This should answer some questions people had and also explain how this is different from the "why don't audit everything instead" type posts.
Re:No reboot required (Score:2)
Heh :) (Score:1)
--
Codesnippets in 'design'.. Sure Linus! (Score:3)
(Linus wrote:)
struct security_checks_struct {
...
... selinux had about 140 points they wanted to hook into ..
... others probably have a few more.
...
int (*execve)(struct task_struct *tsk,struct binprm *new);
int (*file_open)(struct file *);
int (*raise_capability)(...
};
Linus, first of all, for this kind of stuff, they invented C++: easy encapsulation of data and methods on that data in simple objects, no functionpointers in structs anymore, and last but not least: polymorphism!
Second, since the mailinglist is about design aspects, why is code popping up? functionality is designed without looking at CODE. It's designed by defining WHAT functionality should be implemented. THEN you dive into a technical designphase and perhaps you come up with pseudocode. Not in THIS phase.
This new security model can be a big part of the kernel, perhaps a lot has to be changed to adapt the security model in every part of the kernel (like it's done in WIn2k f.e.) to have true ACL driven security inside the OS. You can't design that with codesnippets.
--
Re:crazy curveballs (Score:5)
The goal of OpenBSD and Bastille Linux is to develop distributions where it is impossible (well, extremely difficult) for users to gain permissions they were not explicitely granted. I.E., you get root access if and only if you were explicitely granted root access.
The goal of the security-enhanced Linux work is to make the permissions more granular -- more levels of permission, and standard methods for defining and granting those permissions. I.E., your name server can connect to port 53 if and only if you grant your name server access to that port. The backup operator can read everyone's email if and only if he's explicitely given permission to read everyone's email.
This doesn't have jack squat to do with user-land security systems, or code auditing, or how easy the OS is to r00t. These pluggable linux security modules will probably never, ever be used by 95% of even the most hardcore h4x0rs reading slashdot. They'll certainly never be used in any sort of application where stock OpenBSD provides the security model the application needs. Why? Because OpenBSD and stock Linux have (nearly) the same security model, differing only in the amount of auditing. If the OpenBSD security model is good enough for your application, if follows that the Linux security model is good enough for your application. This is for people who need a different security model.
Re: crazy curveballs (Score:2)
Say I run an IRC client and there's a bug in it that allows people access to my files. With a better security model I could not allow the IRC app access to my files and the bug would not cause damage.
Another approach would be to audit all applications you run like OpenBSD does but I guess that limits your choice of applications and you end up with very old versions.
Re:not so fast (Score:2)
Re:Heh :) (Score:1)
Hi Otis!
Re:This is an unnecessary concession (Score:1)
and so did the fscking moderators.
It's a crying shame.
Re:Heh :) (Score:1)
But still, you scored me some kharma, so thanks
Re:Heh :) (Score:1)
Re:Codesnippets in 'design'.. Sure Linus! (Score:2)
OK, so I don't know who's right, but that's not the point
Re:crazy curveballs (Score:1)
While audits are important, these features will go a long way, and we'll have them very soon in FreeBSD 5.0
Re:This is an unnecessary concession (Score:3)
This is not a push to develop a new security model, rather than a push to develop a way for security models to be integrated with Linux. The problem that exists is that everyone wants to roll their own in security... In Linus's own words:
Everybody has their _own_ particular flavour that they want to push, and don't realize that I cannot accept that as a maintainer.
This security module is an effort to make it so that Linux can have an easy way to implement security without actually having to choose a particular security implementation to stick in the kernel. As has been the rule in Linux, this is not an operating system that tries to be all things to all people, rather it tries to give people the ability to choose everything they need and nothing that they don't.
Re:No reboot required (Score:2)
Re:No reboot required (Score:2)
Re:well which is it? (Score:2)
Re:crazy curveballs (Score:1)
Re:Internet security (Score:2)
ZoneAlarm sucks. It doesn't work, it hangs regularly, it trashes performance, it's nagware and it gives wierd error messages at random intervals.
Re:Internet security (Score:2)
I find about 1 in 3 apps crash with it. ICQ, Counter-Strike for example... Oh, it gets very upset if NS6 tries to use SSL over it.
And now for the bit of the last message which got cut off: you want a mini firewall. Linux is really good for that, offers far more than ZoneAlarm even if you only stick in some really basic rules.
BTW, has anyone else had proplems with preview cutting text to bits?
Re:This is an unnecessary concession (Score:2)
Erm, no. Heard of groups? You just need to read up on how to do it, it's not that difficult.
You can't do it at all on NT.
Re:This is an unnecessary concession (Score:2)
--
Matthijs
Re:Why not config-option? (Score:1)
Well.. I think you are missing the point.. you are assuming there is already some security code that is written and reads a flat file for config info. The kernel guys are saying they are going to add hooks for a loadable module for security. i.e. No security exists.. you write the code.. you compile the module.. you tell the kernel to load the module and boom.. you now are testing your security module. Found a bug? Thats fine tell the kernel to unload the module, fix the bug.. recompile the module.. tell the kernel to reload the module. If the security was staticly in the kernel you would have to fix the kernel itself, rebuild the entire kernel, and reboot. It's my opinion that we want to move more in the direction of dynamically loadable kernel modules, and stay far away from statically linking new stuff into the kernel. Idealy everything but the REAL basics should be dynamically loadable modules, and only the things that are required to be a static part of the kernel be there.
Re:This is an unnecessary concession (Score:1)
It sounds to me like you are speaking more with a Microsoft type mentality. They are the ones who have to hide their true intent to protect their market share. With Linux we are more interested in building a powerful, stable and secure system. It is good that we admit are weak points. As we have done before. It then gives everyone in the community driver to improve on them.
Re:This is an unnecessary concession (Score:1)
Who modded this up? How can people fail to see this as the troll that it is?
---
Why not config-option? (Score:1)
Platy
Re:Why not config-option? (Score:1)
One option "turn additional security on" and then you compile your kernel. Afterwards you configure it with some utils or through
Only my 0.02 Euros..
Platy
Re:Internet security (Score:1)
Re:crazy curveballs (Score:1)
Re:This is an unnecessary concession (Score:1)
Of course, I find the model in NT to be too finely grained, so that delegating tasks to underlings becomes an administrative nightmare.
Re: answer some questions (Score:1)
Well Mr. Karma Whore, stay true to your statement and explain to all of us 'good code is secure code' advocates and tell me how any security model can compensate for a bug-ridden kernel?
And before any of you moderators decide that I'm evil and wrong, this is a valid question and squarely on-topic.
Re: Don't say never (Score:1)
code audits are fine but not everything (Score:1)
This is an unnecessary concession (Score:2)
It discredits Linux to admit that the existing security modules aren't good enough. It discredits Linux to admit that security modules themselves are even necessary in the first place.
We must do everything in our power to ensure that Linux thrives. That means playing the marketing game. If it's bad for marketing, then it's bad for the whole project.
Insecurity is simply something that cannot be admitted up front. It must be cloaked in secrecy. If you reveal the cards in your hand, then your enemies will take the pot. It's that simple.
Perhaps it's time to release a completely closed-source version of Linux. One that doesn't let hackers find holes like these. One that'll protect our vital national secrets from the eyes of those who would steal them.
Because if we let them take our secrets, then we're letting them take our lives.
It's then a short trip in a handbasket to the abyss of anarchy and hell as we know it.
Crime breeds more crime. Criminal hacking contributes to murder and mayhem. We must take a stand, here.
crazy curveballs (Score:1)
Sounds rather ironic when you think about, but here's my <rant> on it all.
Supposed I was CTO of a company, what would make the Linux developers think for a second, that I would want an add on for security. This may sound as flamebait to most, but think about it for a quick second, without getting into an OS envy thread.
With the BSD's per se, security has been improved on the FreeBSD side of things, and Open is a martyr of security, without having to "add on" any modules.
Thinking os the LKM I think that the developers are slipping when programming and this is their solution for this miscalculations on security.
So the OS is not secure, but if you download X patch add on for rev XXX of version XXX, you may maintain a level of security for a while.
Maybe their approach should be as that of the anals of the OpenBSD team with regards to security. If you check it before releasing it, your bound to have less issues in the future. Sure many are gonna bitch, but think about it, with the analness of source code checking done by the developers at OpenBSD, there hasn't been a remote compromise for 3 years on a default install, and thats hellishly good.
What should be implemented is an in-depth code audit of the kernel before its released. Instead of attempting to release a new kernel revision every other week, they should take an extra step, and some extra time to weed out the issues instead of focusing on an add on module for security purposes. This defeats the whole security scope of thinking Linux will be secure, since there are many administrators who wouldn't know a patch if it hit them upside the head.
For those who do their best to maintain a level of security on a Linux based network, it must at times be hard to address security issues when they come out many at a time. Its unfair to think that an administrator under pressure in a large Linux based environment has the time to address everything at once, and many times things will slip by.
Again if the audits were done prior to the releases, the problems would be solved, and once someone began an in-depth review, and got it over with, it would be easier to maintain second, and third times around.
Patching a hole in a tire will only get you so far until you'll eventually will have to replace it.
George Bush's secret meetings with Japanese officials [antioffline.com]
not so fast (Score:2)
Nonsense and here is why. With a secure OS installed you're less likely to worry about issues until you begin to install third party sw, this is one of the biggest problem with security, and often there are limits to even most third party security issues.
Administrating a machine isn't just kill -HUP'ing a daemon, or
With OS's like Free, Open, Net, again many security risks are minimized, and sorry to say but I truly feel tihs can be attributed to the fact that people take their time, and try to get it as right as possible before a release IS released, as opposed to a kernel every other week.
Don't be fooled into thinking that you won't be able to run XXX program or XXX version will be obsolete, a good admin can find a fix for most issues, either by finding a suitable program which will work, tweaking code, and ensuring the program is installed in a secure fashion, even if it means chroot'ing every 3rd party binary.
Re:VMS... (Score:2)
Add VMS to that list as well. The first multi-user system I got to program on was a VMS system. It has ACLs (or some form of like) and they aren't hard to learn at all. Unix premissions where totally alien after ACLs. I look forward to using them again.
--
Re:Internet security (Score:1)
Okay, I see the article was about modules instead of file permissions. No, I didn't read it. Kernel articles are usually far too technical to read through. I'm stupid. I'm an idiot...stop me anytime here. :)
Re:Internet security (Score:1)
It works great for me. I don't know what you mean by nagware. It tells you when there is a new version, but you can turn that off. The only time it has ever crashed on me has been when I was running Gozilla. YMMV
Re:Crazy curveballs (Score:1)
Actually the kernel team wouldn't have to do that. Just let there be one distro that dedicates itself to developing a secure kernel. They could do OpenBSD style code reviews and admins could upgrade when they released stable versions. Debian isn't using 2.4 yet because they are waiting for the kernel to become stable. The problem is that everyone wants to get the latest greatest thing. BTW, I am no different. I'm just installed Mandrake 8.0 beta 2. I'm just not a sysadmin.
Re:crazy curveballs (Score:1)
I don't know why this is going to be a module as opposed to say, a compile-time option for the kernel.
Because everyone has a different way they want to do security. If they included all of those into the kernel, you would probably have a 70 Megabyte file. This keeps the bloat out of the kernel. It also frees linus from having to write all these different options into the kernel. (I think that's the big reason.)
This way you can download the kernel compile it, and then you can pick your security module based on you preference. Also you can change security modules on the fly since they are modules.
Re:Internet security (Score:1)
What is it about linux users that lets them completely obviate someone's good point with "it works fine for me".
Actually you little troll, I never said that he wasn't having problems. I just replied that I hadn't had any problems. So it may be something specific to his system like oh...say his modem. As I said YMMV: Your Mileage May Vary.
I seem to see a lot of posts about "Mozilla crashes all the time" and "No it doesn't. It works fine on my system."
Re:A Firewall won't hack it (Score:1)
Kernel level firewall control was what I was referring to. You would get to choose which applications got to have ports. Still it's not just as simple as Netscape: port 80 only. Your browser opens more ports than that. Besides port 80 is actually the port your browser connects to on the web server if I'm not mistaken.
Also just having a firewall like this isn't perfect protection. Most people would give their browser automatic permission. There's nothing to stop some app from waiting till you start netscape and sending off for http://www.133t.com/name=JohnDoe&mastercard=somenu mber&expiration=023001. There really should also be permissions for what applications are supposed to be able to communicate with what other applications and in what ways.
New binary-only game should be able to open my browser for me, but I should see a pop-up before hand letting me know that another app has activated the browser and would like to go to so and so url. I believe that there is some built-in firewalling in kernel 2.4. There is an app over at kde.com to configure it.
Internet security (Score:2)
It would be nice if there was permission for internet or network access. Anyone who has use zonealarm under windows knows how needed this is. In this day of trojans no application should be connecting to the internet on my computer unless I know specifically what it's doing. That would help linux really become a desktop alternative.
Re:Why not config-option? (Score:2)
I'm not a linux guru and I've never compiled my own kernel so don't get worked up if I say something wrong. I assume what your saying why not just put compile options into the kernel. If you did that you would have to recompile the whole kernel everytime you changed security or tested something new. This way you can just compile your own personal security modules. Lots quicker and more easily configurable.
Re:Why not config-option? (Score:1)
Re:This is an unnecessary concession (Score:1)
"Perhaps it's time to release a completely closed-source version of Linux. One that doesn't let hackers find holes like these. One that'll protect our vital national secrets from the eyes of those who would steal them. "
Errr
-CrackElf
*Linux is dying (Score:1)
Linux faces a bleak future. In fact there may be no future at all for Linux b ecause Linux is dying. Things are looking very bad for Linux. As many of us are already aware, Linux continues to lose market share; red ink flows like a river of blood. Slackware Linux is perhaps the most in endangered. Let's look at the n umbers.
MandrakeSoft's CEO Henri Poole states that there are 70000 users of Linux-Man drake. How many users of Debian GNU/Linux are there? Let's see. The number of Li nux-Mandrake versus GNU/Linux posts on Usenet is roughly in ratio of 5 to 1. The refore there are about 70000/5 = 14000 GNU/Linux users. Slackware posts on Usene t are about half of the volume of GNU/Linux posts. Therefore there are about 700 0 users of Slackware. A recent article put RedHat Linux at about 80 percent of t he Linux market. Therefore there are (70000+14000+7000)*4 = 364000 RedHat Linux use rs. This is consistent with the number of RedHat Linux Usenet posts.
Now Linux companies are consolidating, overhauling their business plans, laying off staff, scaling back expansion plans and pushing back profitability schedules. "It would seem there are too many distributions for the market to bear," said Gartner analyst Tom Henkel. (http://www.zdnet.com/zdnn/stories/news/0,4586,269 5638,00.html)
Red Hat, Inc., the leader in developing deploying and managing open source linux solutions, announced on a reported basis, a net loss of $24.2 million. (http://linuxtoday.com/news_story.php3?ltsn=2001-0 3-22-010-20-PS)
Turbolinux, based in Brisbane, Calif., a Linux-based software provider has withdrawn a $60 million initial public offering "in light of current market conditions." (http://biz.yahoo.com/rf/010320/n20215287_2.html) (http://cnnfn.cnn.com/2001/03/20/deals/ipo/)
Clayton-based Linuxgruven.com, a Linux training and service company with 106 employees, laid off 100 employees (http://stlouis.bcentral.com/stlouis/stories/2001/ 03/05/daily41.html)
Lineo withdrew its initial public offering in January. Caldera Systems delayed the acquisition of Santa Cruz Operations' Unix software by a quarter. Linuxcare laid off dozens in February, with Linuxcare co-founders Dave Sifry and Dave LaDuke are among those departing. VA Linux Systems cut 114 people in February and delayed its expected profitability by nine months. (http://www.zdnet.com/zdnn/stories/news/0,4586,269 5638,00.html)
Due to the troubles of Corel, abysmal sales and so on, Corel Linux is going out of business and was nearly taken over by Microsoft who sell another troubled OS. Owing to the GPL, SuSE is laying off almost all of its US staff. Major marketing surveys show that Linux has steadily declined in market share. Even LinuxWorld.com shut down "because of the economy and everything else" (http://www.newsforge.com/article.pl?sid=01/03/13/ 1720254&mode=nocomment)
Linux is very sick and its long term survival prospects are very dim. If Linux is to survive at all it will be among OS hobbyists (i.e. those who dabble with Minix, Xinu, etc). Linux continues to falter. Nothing short of a miracle could save it at this point in time. For all practical purposes, Linux is dead.
Re:One thing that worries me (Score:1)
Re:This is an unnecessary concession (Score:1)
Sure Linux has great file level security, but users are users and admins are admins. There is no mechanism for giving one user administrative control of the Apache and another user administrative control of Bind for example. With Linux it is an all or nothing proposition.
There is no shame in announcing that publicly known and exploited security short comings are going to be addressed.
Re:This is an unnecessary concession (Score:1)
Kernel Hooks (Score:3)
The idea of adding kernel hooks so that a variety of security oriented modules can be loaded at boot time will alow for maximum flexibility and control by admins.
However, the short term consequences may very well be a plethora of security modules releases which could lead to confusion. Fortunately, the OSS community is good at sorting the good from the bad. It will not take long for the best modules to become more standard and make it into the distros.