Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
In Defense of United Linux

By Miniluv in Op-Ed
Thu Jun 06, 2002 at 05:02:09 PM EST
Tags: Security (all tags)
Security

Recently an article appeared on Security Focus discussing the so called security nightmare that "United Linux" presents the world with. This article is a response to that on a mostly point by point basis.


Jon Lasser, author of Think Unix and project coordinator of Bastille Linux wrote what had the makings of an excellent piece. He's written several columns in the past which raised awareness of a variety of security related issues. Unfortunately this piece revolves around several weak concepts, which will be discussed in varying degrees of depth below.
For starters, identical configurations, binary compatibility and identical libraries are good for hackers.
While this is correct in essence it is hardly a reasonable picture to paint, in that it leaves out an awful lot. This is nothing new in the world of Linux, as several distributions are widely used in virtually default configurations by numerous sites. At the same time, many sites are run by capable administrators who don't use default packages, configurations, and so forth. What this means is that sane default configurations, while malicious hackers may know what they are, don't create a security flaw. Saying anything else is advocating a seriously flawed concept of security through obscurity.

Furthermore, the concept of "binary compatibility" is somewhat misleading. From an ABI (Application Binary Interface) standpoint, all machines running Linux with the same version of the kernel are absolutely "binary" compatible. This still leaves a potentially large number of unresolved dependencies, based on what the binary is, however his does not introduce any greater risk of hacking. Hackers do not typically run dynamically linked binaries, which means that as long as the kernel interface hasn't changed for any necessary system calls, the binary is more than likely going to run completely unhindered no matter what Linux system you put it on. Just as "binary compatibility" is an advertising scheme when distributions use it as a hook, so is it an advertising scheme when security gurus try and make it out to be a sin.

Identical binary builds are an even more serious issue. Many exploits, such as buffer overflows, need to hard-code magic numbers like system calls and addresses that vary by Linux distribution, and by builds of the binaries.
This is true again, on the surface, however it is a most definitely overblown claim. Currently Red Hat is one of the most popular, if not the most popular, distribution in use worldwide. This means that there are a large block of users who're already using "identical" binaries in most cases, as they run whatever comes from the RPMs provided by Red Hat. The same is true of users of Debian, who most use apt-get to install their software, and of Mandrake, SuSE, and so forth. The only major distributions that do not suffer from the "identical" binary problem are Gentoo and Sourcerer, and that is only because of the fundamental nature of these distributions. If it hasn't bitten us in our collective asses yet, why would one more monolithically popular distribution change that? This sounds to me an awful lot like advocating security through obscurity, in that they can't overflow the buffer they can't find. This is utter crap, and I suspect the author of the original piece knows this.

As United Linux will have identical binaries for base system software, an exploit that runs against one distribution built atop it will run against all other distributions.
I begin to wonder exactly what "base system software" is. The most common targets for exploits are network resources, such as web servers or FTP servers. These certainly are not base system software, and in fact are the most likely candidates for differentiation between the United Linux distributions. Each will most likely be tuning and tweaking their builds of Apache, MySQL, proftpd, or whatever other network servers they intend to bundle with the base distribution. The homogeneity among these distributions should be rooted in binaries like cp, mv, su and so forth. This is a much smaller deal, since these binaries are all relatively stable in versioning, as major revolutions in the concept of copying a file haven't come along in years, and bugs are few and far between at this point.

That means if United Linux is successful, it will allow automated exploits to proceed with a ruthless efficiency, reminiscent of CodeRed, Nimda, and other worms targeting software mono-cultures.
This is just plain old FUD. A major factor in the success of those worms, and the cause behind the lack of an analog for UNIX since the Morris Worm, is a fundamental difference in design philosophy between the crew in Redmond and the Linux crowd. IIS runs with system privileges, and in fact this is the only way it can be run. They have tied IIS into the core Windows operating environment at such a fundamental level that it cannot divorce itself of the privileges it runs with. This makes bugs resulting in security vulnerabilities a much more serious matter, as a compromised IIS is now a compromised Windows OS. Contrast this with Linux and Apache, where by default it runs as user "nobody" which implies virtually no privileges on almost all default systems. You must consciously change this to achieve the same level of vulnerability as on a Windows server. As you examine software running in both environments on a piece by piece basis, you find this tends to be true throughout, save for those pieces of software which run in both environments, which tend to have a more Unix like philosophy.

Even further than that, has the author given any consideration to the thought that perhaps United Linux will actually bundle truly secure software such as Apache, QMail, TinyDNS, ProFTPd (or PublicFile) and other such excellent servers? Obviously everything has bugs, and there have been numerous security hole s in virtually all of those packages (qmail and tinydns being the exceptions), however they've also been resolved quickly and fixes made widely available in quite reasonable time periods by most vendors.

Another serious problem with United Linux will likely be coordination between vendors for security fixes.
How will this be any more serious of a problem than coordination between the actual software vendor and the distribution firm? In fact, I would think the opportunity is there for packages to be available faster, as there will be no single United Linux distribution, instead it being an abstract framework for building compatible distributions. This means that if SuSE is excellent at packaging and shipping fixes, in the worst case users of the other vendor distros built from United Linux then they can use SuSE packages with little or no modification. Beyond that, it's not as if users cannot install the fixed packages from source, or large installations can always package the fixed versions themselves, as so many shops already do.

Also questionable is United Linux's mandatory availability of SNMP (Simple Network Management Protocol) software. While most Linux distributions already include this, it is rarely installed by default. The default installation of SNMP is almost always insecure, and, in fact, unchanged SNMP community strings made number seven on SANS' list of the most serious Unix vulnerabilities.
There are several holes in this assertion. One is that just because it's installed it will be running. Two is that just because it's installed the community strings won't be forced into non-standard values during installation. Finally is that it is the distribution vendors responsibility to guarantee the user s security, instead of providing them with all the tools to do it themselves.

The author made several interesting points, and there is definitely a danger in having a large identical installed base, however there are mitigating factors to every point raised that went largely ignored in this article. There needs to be further exploration of these issues, instead of the vague and unsubstantiated worries expressed in this column. This exploration needs to be grounded in fact, not fancy, and should cite concrete examples, rather than vaguely speculating about what might be possible. Frankly, I would've expected better from someone like Mr. Lasser.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
United Linux
o Good 38%
o Bad 8%
o Ugly 53%

Votes: 62
Results | Other Polls

Related Links
o article
o Security Focus
o Bastille Linux
o Also by Miniluv


Display: Sort:
In Defense of United Linux | 46 comments (30 topical, 16 editorial, 0 hidden)
Last paragraph needs tweaking (3.00 / 2) (#5)
by El Volio on Thu Jun 06, 2002 at 01:07:03 PM EST

In the last paragraph, you need to make a few quick adjustments. The first sentence is a run-on; I would divide it up something like this:
The author did make several interesting points, and there is definitely a danger in having a large identical installed base. There are, however, mitigating factors to every point raised...
In fact, the whole article reads as if it were written in verbal language, not written. By that I mean that the structure of many of the sentences lends itself better to being spoken than being read.

But in general, I really think it's an excellent article, and with or without these points, I plan to vote +1 FP.

Explanations (none / 0) (#7)
by Miniluv on Thu Jun 06, 2002 at 01:12:06 PM EST

The tone is mostly because it's op-ed, and I've always responded better to op-ed that could easily be listened to instead of read. Opinion pieces are, by nature, diatribes and thus are heavily influenced by the spoken idiom.

You're correct about the run on, however I'm undecided on if it's unacceptable to me or not.

Fuck Walmart
[ Parent ]

Re: Apache and user "nobody" (none / 0) (#6)
by Talez on Thu Jun 06, 2002 at 01:11:48 PM EST

Your theory is correct if you hold the assumption that only apache will be doing the damage.

While I am not a Linux Guru, I do have a serious question. What if a person was to use apache as a gateway to another process and then use that process to execute arbitrary code?

On the whole, a very good article. Sadly, I'm off to bed since its 1:11 here so I won't get the chance to vote on it.

Si in Googlis non est, ergo non est

Apache as a gateway (4.00 / 1) (#8)
by Miniluv on Thu Jun 06, 2002 at 01:20:00 PM EST

I'm not entirely sure what you mean, but I'll take a stab at explaining how what user apache runs as affects system security.

Basic apache architecture is a parent process, which serves no requests, running as root (to get port 80 since it's <1024) which forks children, drops privileges and changes EUID/EGID to the configured user, and then serves the request.<p> This behavior means that apache can only read files that are readable by the user in question, and within the configured docroot, as modified by <Directory> containers and so forth. Apache doesn't execute any commands itself, unless SSI (server side includes), or CGIs are used. SSIs always execute as the user apache is running as, however CGIs can be executed as other users through the suEXEC mechanism.

Does that make sense as to why you can't really use Apache as an attack mechanism, since there's nothing it can do besides its job?
Fuck Walmart
[ Parent ]

Not quite what I was talking about... (none / 0) (#9)
by Talez on Thu Jun 06, 2002 at 01:25:30 PM EST

What if an attacker was to take advantage of a buffer overflow exploit in apache or one of its modules thereby hijacking the machine when you overwrite the stack with a new return address.

Yes, I concede it would be highly unlikely in this day, age and style of programming but it still might be possible to find some little hole that many have overlooked.


Si in Googlis non est, ergo non est
[ Parent ]

Sure (4.00 / 1) (#11)
by Miniluv on Thu Jun 06, 2002 at 01:28:38 PM EST

If there's a buffer overflow in apache, you can smash the stack and execute arbitrary code, but only as the user apache is running as. Since apache doesn't do any processing as root, to the best of my knowledge, then you're still only getting the EUID of apache's child process.


Fuck Walmart
[ Parent ]

The UID isn't important (4.33 / 3) (#15)
by juahonen on Thu Jun 06, 2002 at 01:46:35 PM EST

If the cracker is after valuable information he doesn't need to be able to get root access. More and more corporate networks rely on web interfaces to their data. The user Apache is running as must have enough priviledges to view the data. And if it does not, it must have priviledges to view the configuration files which contain database hostnames and login information. Stealing information doesn't require root level access.

However, a cracker who gets past Apache can then execute malicious code on the target system which further uses buffer overflows or other methods to get root level access. It is only matter of skill and system setup which limit the possibilities for the cracker.

A hacker might be satisfied when he breaks into the system and leave. But a cracker with malicious intend will not be satisfied with the priviledges of nobody.



[ Parent ]
Buffer overflows (4.20 / 5) (#16)
by Miniluv on Thu Jun 06, 2002 at 01:54:10 PM EST

However, a cracker who gets past Apache can then execute malicious code on the target system which further uses buffer overflows or other methods to get root level access. It is only matter of skill and system setup which limit the possibilities for the cracker.
Oh come on now, that's bullshit and you know it. If the attacker can exploit apache to give him a shell, it's true. A properly configured system makes this a minimal exploit, and with a good IDS this will be caught rather quickly.

I've run systems where based on the contents of /etc/passwd, certain users were watched quite closely, and if anything in /etc/shells ran under their userid it was instantly killed. This isn't an uncommon setup, nor is it a particularly difficult one to manage. Ultimately, UID is very important, as it adds a significant barrier to getting root privileges, which are the holy grail of malicious cracking.

Obviously information doesn't require root access in most cases, nor should it. However it's not apache's problem if you don't properly protect said information. Just exploiting a buffer overflow doesn't automagically allow you to peruse the company database. Just because it's such a common exploit doesn't give it some magical death ray status.

Fuck Walmart
[ Parent ]

Auditing (4.00 / 1) (#22)
by prometheus on Thu Jun 06, 2002 at 02:52:25 PM EST

It's never good to have an attacker gain access to sensitive data, but it's far worse to have an attacker gain access to sensitive data and be able to cover his tracks.  Typically, as long as an attacker does not gain root privileges, he can be detected and eliminated quickly, and will often make a lot of noise attempting to gain access.

It's only when an attacker gains root access that you're really fucked, since then he can alter or destroy any record of his entry.

--
<omnifarad> We've got a guy killing people in DC without regard for his astro van's horrible fuel economy
[ Parent ]

The UID can be important (4.66 / 3) (#28)
by phliar on Thu Jun 06, 2002 at 03:25:02 PM EST

If the cracker is after valuable information he doesn't need to be able to get root access. More and more corporate networks rely on web interfaces to their data. The user Apache is running as must have enough priviledges to view the data.
Not necessarily. I'm not saying this is untrue, just that in a well-designed system, it should not be so. When a user makes an HTTP request for sensitive information, there must be some authentication/authorisation mechanism. Instead of having Apache process that, it should just hand it off to the back end. This means it doesn't matter if Apache is compromised: the attacker must have a valid token to view sensitive data.

Of course it may be possible to attack the back-end system. That is harder, since the scope of possible things the back-end system can do should be much smaller than what can be done in HTTP; therefore it should be easier to secure.

Incidentally, I believe that Apache should run with the privileges of the "web" user, i.e. one who has read access on files designated for world-readability via HTTP. The user "nobody" should have no access whatsoever, and should not be used by any valid system.


Faster, faster, until the thrill of...
[ Parent ]

Paranoia, Inc. (none / 0) (#46)
by haflinger on Sat Jun 08, 2002 at 02:15:02 PM EST

More and more corporate networks rely on web interfaces to their data. The user Apache is running as must have enough priviledges to view the data. And if it does not, it must have priviledges to view the configuration files which contain database hostnames and login information. Stealing information doesn't require root level access.
You're right, nearly all of the time. There are ways of dealing with this though. I will outline one.

You lock up your sensitive information in a DB, probably SQL-based. You access it via a web interface using a CGI, probably written in Perl. The CGI is given write access to some (most or all probably) fields of the database. (Of course, the DB machine is behind a gnarly firewall, and all traffic between it and the Apache machine is encrypted - but you knew that, right.) The CGI is only given read access to less sensitive fields. For example, credit card numbers. When the CGI requests the credit card number field, the DB only reports the last 4 digits. That gives the end-user enough information to identify which card it is, but prevents people who crack Apache open from getting credit card numbers.

However, the CGI has full write access to the credit card number field.

I'm sure there are other ways. This is one.

Did people from the future send George Carlin back in time to save rusty and K5? - leviramsey
[ Parent ]

Shell scripts (4.50 / 6) (#12)
by juahonen on Thu Jun 06, 2002 at 01:35:06 PM EST

Even if Linux software was binary compatible across distributions or Operating Systems, the most simple way to make cross-platform or cross-distribution viruses is to write them as shell scripts. The Bourne shell is very capable and it comes or is emulated by most shells. All there'd be left for a cracker is to penetrate into the system.

Binary compatibility or common "base programs" aren't such a big thing when we're talking about braking into a remote machine. It requires detailed knowledge or the availability of some programs and methods which accomplish this. The point is, common ABI or some base programs won't help crackers. They still need to learn the vulnerabilities the target system has.

Code Red only showed that badly designed security can be abused in automated attacs. But did Code Red actually compromize critical, classified or confidential information? I don't think it did nothing but cause more FUD on people who know little about computer security.



Actually (4.60 / 5) (#14)
by Miniluv on Thu Jun 06, 2002 at 01:43:48 PM EST

I'd say the best "cracking" language around is perl. It's heavily distributed, with every major Unix variant having at least Perl5.005 on it at this point, and allows awfully deep access into syscalls.

You can even use shellcode, just like in C, while still gaining a lot of flexibility in that you know an awful lot of stuff will "just work" because of Perl's compatability.

Fuck Walmart
[ Parent ]

Lots of Bad Perl Code (4.33 / 3) (#25)
by prometheus on Thu Jun 06, 2002 at 03:03:13 PM EST

And there are reams and reams of bad Perl programs out there.  Like all the crap people just threw together shopping cart programs with because they thought it would be cool to save money on programmers by buying an O'Reilley book, doing some Yahoo searches, and coming up with a Bitches' Brew of gnarly-ass shit.

And when one of their clients grows beyond three orders a week, it can't handle the load, or some script kiddie hears about their site and tries some simple shell escape exploits and gets to play with other peoples' credit cards.

Lots of fun to be had there.

--
<omnifarad> We've got a guy killing people in DC without regard for his astro van's horrible fuel economy
[ Parent ]

"Sound and fury", etc... Wheee! (2.00 / 6) (#23)
by sk00t on Thu Jun 06, 2002 at 02:59:04 PM EST

No sense spending a lot of time gnashing your teeth about this on either side of the fence; the odds of the GNULix lads actually getting their shit together and unifying libraries and standardizing configurations are slim to none. They can't even seem to do that within individual distros, let alone unilaterally.

As to which model would be more secure, I stopped trusting Linux security measures a long time ago, (right about when my paycheck started being contingent on things like uptime and not getting hacked), and I wouldn't dream of running any Linux distribution on any sort of trusted system. Bastille, Trinux, United Linux, whatever. Linux boxes just keep getting 0wned, and I don't have time to fuck with reinstalling / reconfiguring them every few months.

"Somehow we get by without ever learning, somehow no matter what the world keeps turning"

--Ben Foster

On Red Hat (4.75 / 4) (#27)
by Chris K on Thu Jun 06, 2002 at 03:16:26 PM EST

The current "domination" of the Red Hat distribution is mentioned in the article, but I think it is worth noting that Red Hat is not a participant in the United Linux distro.  I feel this is important for a couple of reasons.
  1. Keeps competition, and some difference in the distributions.  Everyone knows competition is good.  I don't feel this will fragment the user base, because United will use RPM's anyway, and Red Hat will probably switch to a fancy version of United in a couple of years.  They will only do what is best for the company, and if a common base is the fastest/cheapest way to improve their product, they will go with it.
  2. Keeps homogenaity down.  As noted, a large percentage of users are already using Red Hat.  Since it will be different from the United version, the buffer exploits mentioned in the article will have to be written for United Linux, and each version of Red Hat.  
  3. Common user-land distro.  United Linux is primarily a server distribution.  The world will still need a common user version of linux.  Red Hat is good at making things easier.  Not the easiest linux out there, but nonetheless, it is a fairly easy one.  The sys admins can roll their own or use United, and people will use whatever is easiest for them.  This will still foster competition, both to make United easier, and then for Red Hat to keep up with United.  
  4. More security.  Red Hat has had minor problems with security before, because it's trying to be so user-friendly.  Many shops will switch to United Linux because of its security as compared to Red Hat, and as more least-common-denominator servers become familiar with United they will switch over.  This will drive Red Hat to increase their security in order to preserve market share, and since they will have to make it easy to work with, perhaps new user-interface security designs will evolve.  
  5. This doesn't really have so much to do with Red Hat, but since there are at least 4 different companies going to try to make a living from United Linux, they are going to come up with some pretty clever ways to differentiate themselves.  I would say all of them can only help the community.  
So, I still think Red Hat serves a purpose, and will continue to do so.  They may want to switch over eventually, (see point 1), but they will still need a way to differentiate themselves from the pack.

Linux security
Red Hat
United Linux
duxup: I think people who give should be hunted down and hugged. (IRC)

Billions and billions served... (3.25 / 4) (#30)
by NFW on Thu Jun 06, 2002 at 03:40:01 PM EST

What the world really needs is a single-CD one-click Linux install that supports a billion different hardware configurations and gives you a browser, a multi-protocol buddylist/IM app, a good mail client, an MP3 player, maybe a couple other things.

Most importantly, it should be called the McLinux distro.


--
Got birds?


Linux Security (4.33 / 3) (#31)
by phliar on Thu Jun 06, 2002 at 03:45:26 PM EST

While these are all good points, I feel that talking about Linux and security in the same sentence is -- how should I put this -- silly.

The strength of Linux over the other free Unixes is its support of hardware. This means that for the most part, sound cards, video cards, USB etc. just work. This is a Good Thing for the machine that sits on your desk, that you use to listen to MP3s and run your webcam on.

When you talk about security, you're dealing with systems accessible from the Big Bad Internet, potentially one that's attractive to the bad guys because you might have credit cards or whatever on your system. Needless to say, how well this system supports 32-bit colour running X11 will not be a concern. Hence we need a system that can easily be set up in a minimal way with a small set of things happening. I don't feel Linux -- not just the distributions, but also the kernel itself -- is the right choice. I'd prefer a kernel with no dynamic modules, preferably with no dynamic libraries, with drivers only for the hardware actually on the machine. This naturally implies that a binary kernel that came with some distribution is not what I want.

Among the free Unixes I feel the only choice is OpenBSD. It's run by a small group of smart people who think security and reliability is really important. It's also easy to set up a really small system, one that I can personally feel reasonably confident doesn't do anything I don't know about. A system that is small enough that I feel reasonably familiar with every line of code running on it.


Faster, faster, until the thrill of...

Linux can work fine here as well... (5.00 / 3) (#33)
by pb on Thu Jun 06, 2002 at 04:16:05 PM EST

If a binary kernel that came with some distribution is not what you want, then by all means, compile your own kernel.  I ran RedHat for years with a monolithic kernel and drivers only for the hardware actually on the machine; that works just as well as the kernel that it came with.

If you want a really stripped-down configuration, (with no dynamic libraries (!)) then you might just want to build a glorified rescue disk/CD and install whatever necessary minimal services on it, and maybe compile it statically with an alternative libc.  In a situation like that, though, you probably don't want a distribution, except as a starting point.

But there's no reason why you can't do all this on Linux, or any other free Unix.  And there are versions of the Linux kernel that are rabidly obsessed with security; I've built some of them before.

But heck, for what you're doing, OpenBSD is great, if that's what you're familiar with.  It's certainly not the only choice, but it is designed for what you're talking about.  Depending on what you're doing with it, an embedded system might be good too.
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]

You're quite right (5.00 / 1) (#40)
by phliar on Fri Jun 07, 2002 at 12:51:55 AM EST

If a binary kernel that came with some distribution is not what you want, then by all means, compile your own kernel. ... there's no reason why you can't do all this on Linux, or any other free Unix. I think my original message said "I feel...."
I agree. I'm just saying (and this is only my opinion, I don't claim any kind of divine infallibility) it's just easier -- perhaps I should say I find it easier -- to do this with OpenBSD.

My background: I'm no stranger to Linux, I've been using it since '93 (0.99 PL12); I switched to OpenBSD two years ago. I feel more at home there. (Probably because my first significant Unix experience was in '86, on VAXen running 4.3BSD.)


Faster, faster, until the thrill of...
[ Parent ]

Fair enough (5.00 / 1) (#43)
by pb on Fri Jun 07, 2002 at 10:04:38 AM EST

There's nothing wrong with using what you're comfortable with; Linux probably feels more like home to me because I started UNIX with SunOS, and I haven't used the *BSD's nearly as much.

Most of what I really objected to in your post was the technical details; it sounded like you were saying that all of these things couldn't be done with Linux, which is quite different from having them simply not done out-of-the-box in a big distribution...
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]

Right..... (none / 0) (#36)
by prometheus on Thu Jun 06, 2002 at 07:43:32 PM EST

Because with Linux you can't compile a kernel with no loadable modules, or find minimal distributions where everything is tightly controlled.

I respect the fact that you use OpenBSD.  It's respectable.  It's actually a damn fine OS.  But saying crap like "... I feel that talking about Linux and security in the same sentence is -- how should I put this -- silly." is just plain FUD.  A hacked system typically is a sign of a shit admin, and not a shit OS.

--
<omnifarad> We've got a guy killing people in DC without regard for his astro van's horrible fuel economy
[ Parent ]

FUD? (5.00 / 1) (#39)
by phliar on Fri Jun 07, 2002 at 12:46:18 AM EST

But saying crap like "... I feel that talking about Linux and security in the same sentence is -- how should I put this -- silly." is just plain FUD.
I recognise that that feeling I have is just plain opinion, or prejudice -- hence the qualification "I feel that...." (Besides, who's going to take my word for it? It hardly qualifies as FUD!)

Hope that's better!


Faster, faster, until the thrill of...
[ Parent ]

what I am afraid of... (none / 0) (#35)
by KiTaSuMbA on Thu Jun 06, 2002 at 05:40:08 PM EST

The "dangers" discussed in the linked article are no different from the current reality: default distributions are only such and I can see no real gain in a cracker's "work" with just one or the current 3-4 major distros (that actually differ in no significant manners, unless you make a fuss of wether kde is installed under /usr/local or /opt or whatever). Many linux advocates have erroneously passed to public the notion that linux is secure: Wrong! Linux is SECURABLE not secure by default. That means that a cautious and interested user can configure his machine in a whole range of security options... No sane server sysadmin will leave his system as it came out of the box. Linux is open source remember? So you can comfortably install just the basics from a userwide common United Linux and then build it up to your needs from sources, or even bring everything up from source (any seasoned linux user knows what lfs is, source-based distros are popping up all over the net and the gentoo people are doing a beautiful job). I'm afraid our bastille linux friend is pretty biased against another linux initiative or/and considers that linux users are/should be ignorant enough of the structures underlying their favorite OS to not edit inetd.conf, to not change deafault profiles and to be generally security unaware (this coming from a person that designed a firewall featuring default settings such as "none - easy - medium - paranoid"). There is definately an increasing security danger for linux, but it's not due to United Linux or any other effort for standardization but to the increasing linux users base which now includes end users "just trying it out" from a downloaded set of isos and no documentation whatsoever because someone on IRC told them "it's the most secure OS, hackers use it!!!" The evergrowing ease of installation and use while being a "hot spot" for linux advocacy also allows people with no *will* to learn to install this OS. These people almost invariably make full installs, never change default settings and running services and shift from one distro to another within weeks "because the soundcard didn't work" (not bothering even to ask someone to tell them a bloody module should be loaded). I have nothing against the newcommers (we all have been such and I, personally, was not one of the first to get on the linux bandwagon) nor elitism is to be praised. But instead of just pushing people on installing linux on their computers "because it's as easy as any windows" we should add to our "preaching" the need to read a manual in order to properly operate any device, linux included! These people are running high on security risks wether they use a normal Red Hat or a United Linux affiliated distro or whatever...

Finally I have to add that I am too rather sceptical about United Linux, but not due to security issues... While I always liked the standardization efforts, I fear that United Linux is more like a first step into a huge merger rather than just standardization. Are we gathering all the bazaar benches to bring up another cathedral? What if the different benches don't stand the weight and complexity of a cathedral? Is this like a babel tower? Thankfully, the GNU/Linux system is well protected by the GPL so we will find our way out even if this monument crashes... LFS is always there for you. But what will happen to the newcommers? I can see some e-zines' headlines proclaiming linux'es death... That would be our shot to hit the general public exploded in our faces...
There is no Dopaminergic Pepperoni Kabal!

The problem with this (none / 0) (#37)
by Miniluv on Thu Jun 06, 2002 at 07:45:20 PM EST

A personal computer, or any computer for that matter, is a tool. Yes, it's a complicated tool, but fundamentally it is still a tool, in the same manner that a hammer is a tool and so is a butter knife. This particular tool is used by an awful lot of people to do their job, to enrich their life, and just to relax and surf the Web.

Windows, MacOS and others have striven to understand this as thoroughly as possible, and as such hide as much complexity from the user as possible. In this mission many trade offs have been made, configurability, flexibility and security being amongst them. Linux, on the other hand, is not an operating system, and thus hasn't had a need, or even a desire, to strive toward this end. Red Hat, which incorporates Linux, is an operating system, and has striven towards this end, after a fashion.

From the users perspective, security isn't something they should have to worry overly much about. Users can be taught a specific amount, different for each user, about their computer. What the distributions need to do is learn what the reasonable amount to try and teach is, and the community needs to help them, so that we can find the optimal point towards which to strive. Windows has arguably gone too far, Red Hat (and any other distro) hasn't gone far enough. To steal ESR's relative, Aunt Tilly may not be the person to run a Linux based machine, if her ability to configure and use her tool is not up to whatever standard we set. This is not wrong! This is not evil, elitist, stupid, or anything else. In the same way that I tell the stupid people I know to buy Macs and the smart ones to run a Unix variant of some sort, so too can we tell Aunt Tilly to run Windows if that's all she can handle.

United Linux is aiming to fill a specific niche, and finally they are a Linux distribution vendor who understands what a market is. They're not going to end up a product in search of a market, instead they've found that first and are now homing in on it. I realize most people don't think that making the IHVs and ISVs is particularly important, but then most people don't understand what drives software sales either.

From the perspective of the continued sucess of Linux as a contender, giving it away is the worst decision Linus could ever have made, even though it was that very decision that made it a contender in the first place. Obviously the community will survive the downfall of the distro vendors, because we can all roll our own, and we've got secret stashes of operating system CDs. The market of hobbyists has just about reached saturation, and besides, how many of you've actually paid a distribution vendor for even a single copy of said distro? Not many of you is my guess, and why should you when you've got the bandwidth and the desire to download it for free? Then again, how can those vendors stay in business if that's all you do? If you pay at all it's CheapBytes, or some other smelly hippy in his garage with a CD-R drive and spare time.

The only way to continue to keep companies funding Linux, to keep the developement rolling now that kernel hacking isn't fun, or even possible, for most of the community, is for people to buy it in sufficient numbers that the bottom row on the balance sheet gets shaded black and not red. The way that's going to happen is United Linux making it possible for IHVs to package Linux on their hardware and know that it'll work for the end users when they go to buy Oracle from some ISV who's packaging it with a financial app. It doesn't tend to work today, unless you use RedHat, and a lot of people just don't want to be locked in like that.

Even if it's not United Linux that ultimately drives the standards, they need to be driven into distributions heads as a necessary thing if anyone wants to sell anything based on something other than RedHat. Why? Because packaging an rpm is difficult when the file system isn't standard, and it's worse when you cannot gaurantee the layout of a single symbol table, so you can't promise that anything will run.

Ultimately, I think United Linux, or something like it, is the only savior of the "Linux revolution", and even of the OS itself.

Fuck Walmart
[ Parent ]

Symmetry. (none / 0) (#45)
by haflinger on Sat Jun 08, 2002 at 02:05:23 PM EST

In the same way that I tell the stupid people I know to buy Macs and the smart ones to run a Unix variant of some sort
Thus, you tell everybody you know the same thing. (Think OS X. :)

Did people from the future send George Carlin back in time to save rusty and K5? - leviramsey
[ Parent ]
The problem with this (4.50 / 2) (#38)
by Miniluv on Thu Jun 06, 2002 at 07:46:25 PM EST

A personal computer, or any computer for that matter, is a tool. Yes, it's a complicated tool, but fundamentally it is still a tool, in the same manner that a hammer is a tool and so is a butter knife. This particular tool is used by an awful lot of people to do their job, to enrich their life, and just to relax and surf the Web.

Windows, MacOS and others have striven to understand this as thoroughly as possible, and as such hide as much complexity from the user as possible. In this mission many trade offs have been made, configurability, flexibility and security being amongst them. Linux, on the other hand, is not an operating system, and thus hasn't had a need, or even a desire, to strive toward this end. Red Hat, which incorporates Linux, is an operating system, and has striven towards this end, after a fashion.

From the users perspective, security isn't something they should have to worry overly much about. Users can be taught a specific amount, different for each user, about their computer. What the distributions need to do is learn what the reasonable amount to try and teach is, and the community needs to help them, so that we can find the optimal point towards which to strive. Windows has arguably gone too far, Red Hat (and any other distro) hasn't gone far enough. To steal ESR's relative, Aunt Tilly may not be the person to run a Linux based machine, if her ability to configure and use her tool is not up to whatever standard we set. This is not wrong! This is not evil, elitist, stupid, or anything else. In the same way that I tell the stupid people I know to buy Macs and the smart ones to run a Unix variant of some sort, so too can we tell Aunt Tilly to run Windows if that's all she can handle.

United Linux is aiming to fill a specific niche, and finally they are a Linux distribution vendor who understands what a market is. They're not going to end up a product in search of a market, instead they've found that first and are now homing in on it. I realize most people don't think that making the IHVs and ISVs is particularly important, but then most people don't understand what drives software sales either.

From the perspective of the continued sucess of Linux as a contender, giving it away is the worst decision Linus could ever have made, even though it was that very decision that made it a contender in the first place. Obviously the community will survive the downfall of the distro vendors, because we can all roll our own, and we've got secret stashes of operating system CDs. The market of hobbyists has just about reached saturation, and besides, how many of you've actually paid a distribution vendor for even a single copy of said distro? Not many of you is my guess, and why should you when you've got the bandwidth and the desire to download it for free? Then again, how can those vendors stay in business if that's all you do? If you pay at all it's CheapBytes, or some other smelly hippy in his garage with a CD-R drive and spare time.

The only way to continue to keep companies funding Linux, to keep the developement rolling now that kernel hacking isn't fun, or even possible, for most of the community, is for people to buy it in sufficient numbers that the bottom row on the balance sheet gets shaded black and not red. The way that's going to happen is United Linux making it possible for IHVs to package Linux on their hardware and know that it'll work for the end users when they go to buy Oracle from some ISV who's packaging it with a financial app. It doesn't tend to work today, unless you use RedHat, and a lot of people just don't want to be locked in like that.

Even if it's not United Linux that ultimately drives the standards, they need to be driven into distributions heads as a necessary thing if anyone wants to sell anything based on something other than RedHat. Why? Because packaging an rpm is difficult when the file system isn't standard, and it's worse when you cannot gaurantee the layout of a single symbol table, so you can't promise that anything will run.

Ultimately, I think United Linux, or something like it, is the only savior of the "Linux revolution", and even of the OS itself.

Fuck Walmart
[ Parent ]

your last paragraph (5.00 / 2) (#41)
by subgenius on Fri Jun 07, 2002 at 01:01:16 AM EST

sums it up.

Drive On!


Drive On!
[ Parent ]

The SecurityFocus Article is Full of Shit (3.50 / 4) (#42)
by CarryTheZero on Fri Jun 07, 2002 at 03:13:19 AM EST

His only real point seems to be that more people running identical binaries makes exploiting buffer overflows easier, because you only have to do the work of finding stack addresses once. While this is true as far as it goes, so many people run Redhat right now that they constitute a de facto monoculture, and you can do pretty well for yourself just using canned exploits targeted at the Redhat version of the program in question. Furthermore, finding the right stack address for a different binary isn't difficult if you know what you are doing, so at best this is security through obscurity. All the rest of his points are just uninformed hand-waving. Like "the automatic updater might not check package signatures." Why the hell wouldn't it? Why are you even talking about what a hypothetical piece of software might or might not do? Pathetic.

--
You said I'd wake up dead drunk / alone in the park / I called you a liar / but how right you were
iTunes users: want to download album artwork automatically? Now you can.
Identical binaries... (none / 1) (#44)
by busonerd on Sat Jun 08, 2002 at 01:31:42 PM EST

It seems to me that anyone who does not wish to have an identical binary could just tweak the sourcecode, even a slight bit.
For example, change the optimization level, optimize more for size and less for speed. this would create a completely different binary.
There are a myriad of different ways to change the "identical binarys."

But, what software company do we know that distributes their OS precompiled?
Talk to me about identical binaries, pshaw...

In Defense of United Linux | 46 comments (30 topical, 16 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!