No, this is just the wrong way. The kernel is the most important part for a running system. You can turn off samba, or cron, but turning off the kernel is ... *mmmhh* ... stupid ..

ssh? cron? syslog? ntp?

Everyone caring a little bit, should be able to recompile a kernel, and it is not very hard to learn, too. Distributors will _never_ be fast enough to rapair a kernel hole in reasonable time. As far as I remember, SuSe has made a patched 2.2.18 kernel, which _is_ secure.

I must disagree on this point. Does everyone that drives a car know how to fix it? I sure don't. Do you know how to safely disable the airbags in a car? Can you do basic TV repair? Microwaves? Computers are horribly complex, most people quite simply don't have the time, expertise or want/need to learn, and they don't really need it to be honest. This is why we have tech support and IT staffers. BTW what happens when there is a flaw in binary only software? Doh. I think Theo de Radt has a good quote on this "we don't want administrators to have to be security experts, that's why we ship OpenBSD secure by default".

Markus

-Kurt

* Markus Gaugusch wrote on Wed, May 09, 2001 at 10:02 +0200:

...

ssh? cron? syslog? ntp?

they are much easier to build, than a kernel. Kernel means really high complexity for the distributor, because it has to run on many, many, many, MANY different machines.

I agree, and SuSE demonstrated that even ordinary RPMs are not trival, since the depencies may have changed on build host, which could make the rebuild RPM unusable on other hosts.

What I wanted to say, is, that the kernel is so special, that every admin should know, how to build it, and apply patches. Just like very windoze user knows how to reboot ...

I think I know how to build a kernel, and I built a lot of. But I don't want to do it, and make a useful kernel RPM is another task than just building a kernel. Remember modules like freeswan.

...

I must disagree on this point. Does everyone that drives a car know how to fix it? I sure don't.

No, but people driving through the desert should at least be able to change the tires if one gets damaged.

So a admin must be able to change/update a kernel RPM supplied by the vendor according to the update instructions, not more.

The internet is a hard place, and admins must be able to survive there.

Building kernels is more complex than it seems to be, there are a lot of patches for some device drivers, patches with interfere each other, like kerneli and freeswan and others. From my point of view it's not nessacary for every admin to reinvent the wheel (or a kernel RPM), it should be task of the vendor. But currently there are problems (missing announcements, missing kernel module updates and others). I asked already on this list, let me repeat my question: Which kernel RPM (without the <2.2.18 ptrace bug) is working with with distribution? Are the kernel depended packages (like freeswan) available? Usually it's nessasary to update them as well - at least when changing the kernel version. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

Agreed. For those of us who don't use SuSE default kernels, it would be very convenient though if SuSE would provide the sources for the newer kernels, with all (suse-specific etc) modules included. I think a large part of this list is more than competent enough to build their kernel from those, and it would save people the hassle of grabbing up sources and modules from somewhere else.

This URL is not really official, but it used to be like this for years. The absolutely latest that Hubert (Hubert Mantel, kernel maintainer at SuSE, founder of SuSE and poor guy with this pile of work from my side) does can always be found at ftp://ftp.suse.com/pub/people/mantel/next/ as a tarball as well as a patch against the vanilla version of the kernel. I'm running this kernel on my desktop machine as well as a few servers that are under heavy load at times, and I haven't seen any hassle so far. I have to ask a question to the list though, we could use some assistance. New thread. Thanks, Roman. -- - - | Roman Drahtmüller // "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - -

On Thu, May 10, 2001 at 10:45:54AM +0200, RoMaN SoFt / LLFB!! wrote:

Is there any other way of solve this "tarball vs rpm" troubles? Things like dependencies are added problems... (rpm thinks you have an old kernel installed although you have the last one compiled from tarball).

I would have done rpm -e vendor_kernel.rpm then build by own kernel from the tar source modify my lilo use mk_initrd (if necessary) then reboot. This way there is no kernel rpm installed according to the rpm database. Ofcourse I can be completely wrong -- Togan Muftuoglu

...

I would have done rpm -e vendor_kernel.rpm then build by own kernel from the tar source modify my lilo use mk_initrd (if necessary) then reboot. Then you break all rpm's dependencies! No, this is not true. I never had SuSE kernels and never had problems with kernel tar balls or other RPMS. Kernel is the only thing I compile myself without RPM, though. Other packages really ruin your system. Some packages require packages like "kernel >= 2.2.0", but these are rare and you can still force installation, because you know which kernel is installed.

But I think we should kill this thread now. bye Markus -- _____________________________ /"\ Markus Gaugusch ICQ 11374583 \ / ASCII Ribbon Campaign markus@gaugusch.dhs.org X Against HTML Mail / \

I agree, and SuSE demonstrated that even ordinary RPMs are not trival, since the depencies may have changed on build host, which could make the rebuild RPM unusable on other hosts.

$ rpm -qpl k_deflt.rpm |grep /modules/|wc -l 803 $ The upcoming 2.4 kernel: 1117 kernel modules. Needless to say that this is a bit worksome.

...

What I wanted to say, is, that the kernel is so special, that every admin should know, how to build it, and apply patches. Just like very windoze user knows how to reboot ...

I think I know how to build a kernel, and I built a lot of. But I don't want to do it, and make a useful kernel RPM is another task than just building a kernel. Remember modules like freeswan.

That's where we still have a problem: freeswan. It is one of the few packages that have their own kernel module (usually the modules are inside the kernel rpm).

Building kernels is more complex than it seems to be, there are a lot of patches for some device drivers, patches with interfere each other, like kerneli and freeswan and others.

...

From my point of view it's not nessacary for every admin to reinvent the wheel (or a kernel RPM), it should be task of the vendor. But currently there are problems (missing announcements, missing kernel module updates and others).

It's as with cars: In the beginning, everybody must have been able to take apart the engine to repair it. Later, when technique became too complex on the one side and when people who didn't know anything about engines could drive, mechanics took over that part. A few years back everybody compiled her own kernel, and today it is expected that the mechanics solve that problem. And I fully agree with that.

I asked already on this list, let me repeat my question:

Which kernel RPM (without the <2.2.18 ptrace bug) is working with with distribution? Are the kernel depended packages (like freeswan) available? Usually it's nessasary to update them as well - at least when changing the kernel version.

There are multiple bugs in the kernel, and the ptrace bug is only one of them. All kernels that can currently be found on ftp.suse.com/pub/suse/i386/update/* do fix the known security problems. These kernels call themselves 2.2.18, but they are basically 2.2.19 with only a few items missing (most important the version number change). Installation: rpm -Uhv k_deflt.rpm mk_initrd lilo We are very close to the announcement.

Steffen

Thanks, Roman. -- - - | Roman Drahtmüller // "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - -

Martin P.S.: I like your car example. If you want to drive a car, you need a driving license ;-)

Drivers Licenses only cover how to USE the car. Not how to fix it. -Kurt

On Thu, May 10, 2001 at 01:24:13PM +0000, Martin Peikert wrote:

"Kurt Seifried" wrote:

...

...

Martin P.S.: I like your car example. If you want to drive a car, you need a driving license ;-)

Drivers Licenses only cover how to USE the car. Not how to fix it.

Uuh? System administrators has only to know how to _use_ a kernel? I think they should know a little bit more...

And to stay tuned with the example, at least in Greece proffessional drivers (like TAXI drivers, bus drivers etc) are required to know how to fix the vehicle they are driving... -- Yiorgos Adamopoulos -- #include adamo@dblab.ece.ntua.gr -- Knowledge and Data Base Systems Laboratory, NTUA

** Reply to message from Michael Chletsos on Thu, 10 May 2001 07:49:22 -0500 (CDT) ***Also in many central European countries, you have to know how to fix your ***car just to get a driver's license. And In Japan one must have a parking space before getting a drivers license, but that doesn't mean any of these folks under discussian can *DRIVE* ... >G> OTH When one is starting to learn anything new it's all rather overwhelming. I should have thought , the fact that someone a "newbie" especially, who has the sense to join a list such as thing inorder to become more aware of the failings/abilities of his new system should be encouraged. One cannot learn everything overnight ... and , when someone , gvining the appearrance of a knowledgable being publishes something in this formum that is labled "the WORST" exploit ever... the newbies shouldn't be discouraged from applying other fixes simpley because they haven't reached the levels of enlightnment of some here. I *could* be wrong but, I believe Kernel compiling is a rather high level of Linux Leaning and discipleship, something to work toward, not be derided if one hasn't yet atained it. Grand Master Linus surely wouldn't approve .. j afterthought ... > ... FILE NOT FOUND. Should I FAKE it? (Y/N)

On Thu, May 10, 2001 at 01:24:13PM +0000, Martin Peikert wrote:

"Kurt Seifried" wrote:

...

...

Martin P.S.: I like your car example. If you want to drive a car, you need a driving license ;-)

Drivers Licenses only cover how to USE the car. Not how to fix it.

Uuh? System administrators has only to know how to _use_ a kernel? I think they should know a little bit more...

... and I'd say that in the car example the *driver* should indeed be compared to the "ordinary sysadmin", while the "ordinary users" would be the passengers. In the same way you could compare the admin of a large multi-user server to a bus driver. To elaborate this further: in the car example the driver should to know quite a lot of things about traffic regulations and related stuff and be able to drive his car without causing too much damage to his environment ;-) and he having at least some ideas of how his car works can help him a lot in many situations: being able to replace a wheel by himself may be a good thing for him, and knowing what to do when that small red light with the little oil can symbol starts flashing could be even more useful. Just recall the old lady who owned a Volkswagen beetle: she thought somebody had stolen her engine when her car wouldn't start and she opened what she thought was the engine bonnet at the front of her car ;-) The longer I look at the car example the more I like it! And the drivers licence for sysadmins also sounds nice as a comparison... Thomas -- Thomas Haeberlen Rechenzentrum Universitaet Stuttgart (RUS) Email: haeberlen@rus.uni-stuttgart.de

* Martin Peikert wrote on Wed, May 09, 2001 at 10:57 +0000:

For the people that use linux at home, I agree completely. But for a system administrator in, for example, an university, where many people have an account on the system, I do not and do not even want to.

oki, in university it's may not be a problem to waste a lot of time and money for building kernel modules. In industry this is handled differently usually. If a hour costs i.e. $100, and a kernel security update tooks 2 hours per machine, you will have enourmous costs... so it becomes neccesary to be efficient, and recompiling kernels all the time cannot be efficient. Second, RPM building may require very special knowledge. SuSE is able to pay one or two "kernel gurus" - ordinary small companies are not. But I see no reason to continue this thread, since it becomes more and more offtopic. It's everybodies own decision to use SuSEs upgrades or not.

My belief is that those still need to be able to fix major security flaws by patching and compiling the faulty software if there is a root exploit out in the wild.

Have you ever estimated the costs? Assume 2 hours for download, patch and compile, add 1 hour for testing on each system hardware configuration (controllers combinations and others), add time needed to document the changes and you'll get a lot of time, really.

So what the hell is it we are going to? Incompetence as normality?

I think you missed the point. Nobody is able to be very competent in kernel and *.RPM security, even with reading mailinglists all the time. Evaluating patches and doing security audits is anythink but trivial. Don't forget that.

I still think that anyone that wants to administrate (not the home users, because users do not neccessarily need to have that knowlwdge that administrators of a more complex system - that many people are using - should have) a system has to have some competence about what she is doing.

It's hardly possible to know at least the kernel well, since it sources are some MB of data. Did you understand every part of it? Did you ever looked into the sources of cron or whatever? I cannot believe it. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

[ attribution broken, whom are you citing here Kurt? ] On Wed, May 09, 2001 at 01:55 -0600, Kurt Seifried wrote:

...

Everyone caring a little bit, should be able to recompile a kernel, and it is not very hard to learn, too. Distributors will _never_ be fast enough to rapair a kernel hole in reasonable time.

I must disagree on this point. Does everyone that drives a car know how to fix it?

It's nice to have an analogy everybody's familiar with. This raises recognition. :) Everyone that drives a car should either - know how to fix a breakage or - know a garage to go to in case the car breaks down or is going to instead of - waiting for the vendor to overhaul(id?) the model / series and ram the change down the customers' throats. When people only drive their car without any maintenance (no matter if done by themselves or done by a garage they pay), they have at least *contributed* when an accident happens. It boils down to "teach yourself or have your administration done by somebody who knows what to do". You do have an individual support contract for your installation, don't you? If not, you're doomed to wait for the vendor. And the vendor won't head for the quick and dirty fix as long as customers are screaming when their non typical setup breaks. As well as variety in possible setups delays testing. [ I don't talk to you specifically, Kurt. It's the audience "you". ]

Computers are horribly complex, most people quite simply don't have the time, expertise or want/need to learn, and they don't really need it to be honest. This is why we have tech support and IT staffers.

Exactly the point. If general distribution media doesn't satisfy your need in terms of response time and customization, talk to tech support people and use their offers.

I think Theo de Radt has a good quote on this "we don't want administrators to have to be security experts, that's why we ship OpenBSD secure by default".

This "secure by default" comes from disabling all the dangerous stuff. Add some usual functionality and boom! You have OpenBSD running and yet are not secure. And that's exactly what the OpenBSD community will tell you: You don't have a default setup (enabled services which are disabled by default, installed additional software, changed existing configuration) and so it's *your* fault when something happens. In fact there were people fleeing from OpenBSD because "the security had gotten on their nerves". :) The advantage doesn't come (in any distribution you could think of) from installing things, but from using them appropriately. (How many of these threads did we have already?) One of my favourite fortunes is pinned above my desk: "A fool with a tool is still a fool". That's not about telling unexperienced or overloaded people that they are fools. It's about the above "learn it" (luckily ignorance is something you can do something against) or "pay someone to do it for you". If you judge yourself you don't know and yet keep up this state and neither hand out this overwhelming job to somebody to handle it, don't moan if bad things happen ... virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.

...

BTW what happens when there is a flaw in binary only software? Doh.

So why are you using Microsoft Outlook? Do you have the sources? Or don't you care about security?

I have up to date AV software and I block 200+ attachment types on my server. Plus a few other commercial security products loaded onto my windows machine. Plus other forms of network security to isolate this workstation in the event someone does do something nasty to it. Pine has also had it's share of security flaws, on OpenBSD ports it won't compile, they have configured it to issue a warning, you must make a modification to the Makefile to download/compile/install it. Show me a unix mailer with support for PGP/GnuPG and a smart card reader with X.509 certificate and I will switch.

Hubert Mantel Goodbye, dots... /\\

Kurt Seifried, seifried@securityportal.com Securityportal - your focal point for security on the 'net

"Kurt Seifried" wrote:

Show me a unix mailer with support for PGP/GnuPG

mutt, pine, kmail.

and a smart card reader with X.509 certificate and I will switch.

:-( Martin -- martin.peikert@innominate.com innominate AG project manager the linux architects dipl. math. http://www.innominate.com tel: +49-30-308806-0 fax: -77 gpg: http://innominate.org/gpg/mpe.gpg

I fail to see how all this will protect you from some backdoor in binary only outlook. Since the sources of outlook are not available, paranoid people need to assume the worst.

Same goes for opensource products. Look at all the security flaws that are found on a weekly basis. Pine was opensource yet it had several long term security flaws....

1. You have the sources of pine. You can audit it and fix it if needed

Then why did these problems escape notice for so long?

2. There are alternatives to pine (eg mutt) 3. You don't know what security flaws are in outlook. There might even be intentional ones. But maybe you have some special deal with Microsoft...

You don't know what security flaws are still present in pine.

That is a lame excuse. If you are really interested in having this functionality in Linux, help work on it ;) But blindly trusting some binary only program (especially from Microsoft) sounds very strange to me.

No it's not lame. I need that functionality. It doesn't yet exist in Linux. I don't have the time or inclination to code it myself.

...

Kurt Seifried, seifried@securityportal.com Securityportal - your focal point for security on the 'net ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Don't get me wrong. I do not intend to offend you. But claiming to care about security and at the same time using binary only software for really critical and sensitive things makes it quite hard for lots of people to take you seriously.

This binary only software argument is somewhat bogus in my opinion. I write a weekly linux and bsd digests, they have more then their share of security problems.

-o) Hubert Mantel Goodbye, dots... /\\

Kurt Seifried, seifried@securityportal.com Securityportal - your focal point for security on the 'net