Right, for a start, if I was a professor at university I'd much rather
some "smart" students crashed 100 boxes a day for a year than one
owned several servers. In any case, it seems absurd that anybody
looking for security holes to either subvert or crash systems would be
deterred by the lack of security commit messages. They already know
what they are looking for. On the other hand, there has to be some
metrics available for normal people to make an informed decision about
the relative security of linux and the likely hood that smart people
are able to cause a bit of mindless vandalism or get up to much worse.
Your hand waving and obfuscation simply do not wash. The bugs being
talked about are not just any bugs. They have their own commercial
value because they can allow the complete subversion of your systems.
This (for most people I'd guess) is far more dangerous than simply
having their computers crash. Also, I'd bet that many security bugs
aren't triggerable under any normal workload. If my machines have
been running for 2 months why bother bringing them down in order to
bugfix something that doesn't seem to affect them anyway?
This business of passing the buck onto vendors is also absurd. If
security is not built into your development mindset and models from
the start you are being utterly naive and complacent. I commend the
stable team for fixing and backporting what they can, but I need to
know what I've been exposed to and for how long. From the looks of
what the paxteam has been saying, it seems linux security is pretty
bad and has been getting worse. This must be in no small part to you
putting your head in the sand, sticking your fingers in your ears and
going "lalalalala".
Obfuscating the risk people are exposed to means you have no real
accountability and thus no incentive to not put so many security bugs
there in the first place. If other developers or users don't know how
bad things are how can they make informed decisions about development
processes or where they can afford to deploy linux?
If it turns out that the current development model has produced too
many security problems then the development model must change. I'd
like to think that the integrity of most peoples systems is more
important than some micro benchmark improvement because of some
complex scheduler change. That's not to say the latter isn't
important, just that more time and effort needs to be put into making
sure that the changes don't affect users in potentially disasterous
ways.
One more thing I'd like to throw out there on the issue of
accountability is this: How do I know that some developers have not
been paid to specifically introduce some obscure security flaw? Given
that such subversions happen frequently in every other field of human
endeavour where potential profit is involved, this is not beyond the
realms of possibility. The more linux is adopted the more likely this
is to become a real issue. For that reason it is imperitive that
these potentially severe flaws are dealt with openly and transparantly
when discovered.
If the attitudes of the people at the top of linux development don't
change this is the end of the linux experiment for me and i'm sure
many other people. The percieved benifits of transparancy, openness
and cost will have been completely smashed for the vast majority of
users. This is not something to be taken lightly.
On Wed, 16 Jul 2008 16:05:07 +0000 Cheradenine Zakalwe wrote:
[deletia]
Please submit patch(es) to Documentation/stable_kernel_rules.txt
or some other (even new) file in Documentation/ .
Thanks.
---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
On Wed, 16 Jul 2008, Cheradenine Zakalwe wrote:
> If it turns out that the current development model has produced too
> many security problems then the development model must change. I'd
> like to think that the integrity of most peoples systems is more
> important than some micro benchmark improvement because of some
> complex scheduler change. That's not to say the latter isn't
> important, just that more time and effort needs to be put into making
> sure that the changes don't affect users in potentially disasterous
> ways.
how can you tell for sure if a bug has security implications or not?
the argument can be made that just about any bug can be a security bug
frequently the security implications of a bug are not known at the time
it's fixed, but are discovered later. how do you expect to have this in
the announcements?
if you only upgrade when there is a 'security bug' announcement you will
miss a lot of important upgrades.
as Linus stated, there's nothing preventing anyone who thinks that he's
not doing an appropriate job from doing the research on the security
implications of everything and doing their own announcements or just
maintaining their own tree.
David Lang
Cheradenine Zakalwe wrote:
> If the attitudes of the people at the top of linux development don't
> change this is the end of the linux experiment for me and i'm sure
> many other people. The percieved benifits of transparancy, openness
> and cost will have been completely smashed for the vast majority of
> users. This is not something to be taken lightly.
There is a project which is seriously concerned about security as well
as open source, and it's name is OpenBSD. Not a popular observation to
make in some parts, I know, but true none-the-less.
On Wed, 16 Jul 2008 16:05:07 -0000, Cheradenine Zakalwe said:
> This (for most people I'd guess) is far more dangerous than simply
> having their computers crash. Also, I'd bet that many security bugs
> aren't triggerable under any normal workload. If my machines have
> been running for 2 months why bother bringing them down in order to
> bugfix something that doesn't seem to affect them anyway?
You just convinced me that you've never *really* thought about it the way
a security professional would.
The key point you overlooked is that if it's only triggered under an abnormal
workload, the attacker can usually *arrange* said workload. Need at least
10K processes for something to trigger, and there's usually only 400 on the
box? No problem, just fork-bomb yourself 9,600 processes and then run the
exploit. You can only avoid the reboot for a bugfix if you can *prove*
that the setup condition(s) cannot possibly happen on the system unless
the security has already been breached (for example, "we don't need to
reboot to fix this because there is a system-wide process limit of 1,250
per user, there are only 7 userids on the system, and you need to already
be root to reset the limit").
Just woe unto you if you add an 8th userid before you reboot.. :)
> Obfuscating the risk people are exposed to means you have no real
> accountability and thus no incentive to not put so many security bugs
> there in the first place. If other developers or users don't know how
> bad things are how can they make informed decisions about development
> processes or where they can afford to deploy linux?
If I wrote up a 'DoS Advisory' for every time I manage to find another way
to oops or panic a -mm kernel, I'd probably have a a very large pile of
advisories. However, the fact that I managed to oops or panic their software
has almost always been incentive enough for the maintainers to fix it, there's
no need to add more.
> know what I've been exposed to and for how long. From the looks of
> what the paxteam has been saying, it seems linux security is pretty
> bad and has been getting worse. This must be in no small part to you
> putting your head in the sand, sticking your fingers in your ears and
> going "lalalalala".
It should however be noted that a number of people who take security seriously
think the paxteam is totally out to lunch with some of their ideas. The last
time I looked at their "security patch" (admittedly, that was back around
2.6.17 or so), a large chunk of it was pretty much cargo-cult security that
addressed specific gotcha's that have in the past been used (like symlink races
in /tmp), rather than address the *actual* security issue (for instance,
"compilers shouldn't overwrite system config files") in a comprehensive manner.
A big chunk of the rest was their version of execshield, which required
cutting the available address space in half (a big issue for 32-bit archs).
The telling point is that they didn't see this as being possibly a problem for
some users.
> If it turns out that the current development model has produced too
> many security problems then the development model must change.
You've apparently overlooked the fact that although there are probably still
a lot of security bugs in the kernel, an attacker is *always* going to
approach the path of least resistance. No sense in looking for a kernel
exploit, when it's probably a lot easier to find one you can package up
in Firefox, or OpenOffice, or the pcre library, or any of the zillions
of other packages that get security advisories all the time...
And tell me - how many is "too many"? Who gets to judge? You don't like
the way Linus and Andrew handle it, there's this guy Theo, you can go talk
to him....
> One more thing I'd like to throw out there on the issue of
> accountability is this: How do I know that some developers have not
> been paid to specifically introduce some obscure security flaw?
Which is more likely - that somebody will manage to sneak a malicious patch
past the relevant subsystem maintainer, and Andrew Morton, *and* Linus,
without anybody being the wiser, or that they'll drop their malicious code
into one of the *other* 5,932 packages currently in Fedora Rawhide?
Go read up on the Underhanded C contest. Then go read Ken Thompson's Turing
Award Lecture "On Trusting Trust" - and then go see if anybody's audited the
gcc tree lately, while thinking about what Thompson wrote. Or audited
the *other 5,931 packages besides the kernel and gcc...
(Incidentally, the "unnamed Air Force Document" that Ken mentions is none
other than Karger&Schell's paper on Multics security - also a good read,
as it discusses a *lot* of attack methods you may not have really thought
about in detail...)
On Wed Jul 16, 2008 at 16:05:07, Cheradenine Zakalwe wrote:
> Right, for a start, if I was a professor at university I'd much rather
> some "smart" students crashed 100 boxes a day for a year than one
> owned several servers. In any case, it seems absurd that anybody
> looking for security holes to either subvert or crash systems would be
> deterred by the lack of security commit messages. They already know
> what they are looking for. On the other hand, there has to be some
> metrics available for normal people to make an informed decision about
> the relative security of linux and the likely hood that smart people
> are able to cause a bit of mindless vandalism or get up to much worse.
I don't know what to make of this paragraph. I'm currently employed at a
University and there are quite a few linux boxes (even available to
students, some of them probably "smart") and I don't have any issues with
crashes or servers getting owned. The only upgrade decsision I have on
these servers is when to reboot after the vendor supplies patched kernels.
> Your hand waving and obfuscation simply do not wash. The bugs being
> talked about are not just any bugs. They have their own commercial
> value because they can allow the complete subversion of your systems.
> This (for most people I'd guess) is far more dangerous than simply
> having their computers crash. Also, I'd bet that many security bugs
> aren't triggerable under any normal workload. If my machines have
> been running for 2 months why bother bringing them down in order to
> bugfix something that doesn't seem to affect them anyway?
Because uptime isn't everything. Bugs can (and will) happen in any complex
system. Furthermore not every bug obviously has a security implication. If
you discover one, just reply to the release announcement and tell the rest
of the world of your discovery.
> This business of passing the buck onto vendors is also absurd. If
> security is not built into your development mindset and models from
> the start you are being utterly naive and complacent. I commend the
> stable team for fixing and backporting what they can, but I need to
> know what I've been exposed to and for how long. From the looks of
> what the paxteam has been saying, it seems linux security is pretty
> bad and has been getting worse. This must be in no small part to you
> putting your head in the sand, sticking your fingers in your ears and
> going "lalalalala".
Why is it absurd that the vendors take care of the bugs in their specific
kernels. Most vendors deliver kernels with additional patches anyway, so
it's their duty to fix the bugs. I've never experienced this
"finger-in-the-ears" attitude here. And I don't think security isn't
important here. But the system is very complex and security issues in a
bug aren't easy to spot. I've been running linux since 1996 and every
successful attack I've seen on any of my systems so far was either caused
by weak passwords or badly written php webapps (I haven't been root-owned
so far, an I hope it stays that way).
> Obfuscating the risk people are exposed to means you have no real
> accountability and thus no incentive to not put so many security bugs
> there in the first place. If other developers or users don't know how
> bad things are how can they make informed decisions about development
> processes or where they can afford to deploy linux?
There is nobody here deliberatly obfuscating bugs. It's just not always
plain to see that there is a security issue.
> If it turns out that the current development model has produced too
> many security problems then the development model must change. I'd
> like to think that the integrity of most peoples systems is more
> important than some micro benchmark improvement because of some
> complex scheduler change. That's not to say the latter isn't
> important, just that more time and effort needs to be put into making
> sure that the changes don't affect users in potentially disasterous
> ways.
If you want more stability stay with your vendor kernel. On my personal
system I always run the latest stable release. That's my personal decision
and the response times of the stable team are almost unbeatable. I sure
won't win any uptime contest that way, but there isn't something in the
world I'm less interested in. I can easily live with the 1-2 minutes
downtime once in a while.
> One more thing I'd like to throw out there on the issue of
> accountability is this: How do I know that some developers have not
> been paid to specifically introduce some obscure security flaw? Given
> that such subversions happen frequently in every other field of human
> endeavour where potential profit is involved, this is not beyond the
> realms of possibility. The more linux is adopted the more likely this
> is to become a real issue. For that reason it is imperitive that
> these potentially severe flaws are dealt with openly and transparantly
> when discovered.
Have you ever seen what happens with patches on this list? There's almost
never a patch among them that slips through not reviewed or commented by
anyone. I seriously doubt anybody would be willing to spend money to slip
an exploitable hole into the kernel. The risk of getting detected early is
way to high. And any developer involved in such a plot is probalby out of
business forever. He will never again contribute to any open source
project and he most likely won't ever find an employer again. Would you
hire someone that has a record of backdooring software for money?
> If the attitudes of the people at the top of linux development don't
> change this is the end of the linux experiment for me and i'm sure
> many other people. The percieved benifits of transparancy, openness
> and cost will have been completely smashed for the vast majority of
> users. This is not something to be taken lightly.
I don't think the attitude of the top developers is an issue here. Maybe
you are overreacting to some extent. Calm down and think about the
questions you raised. If you want the quality of the code raised, review
patches, test rc-kernels or mm-kernels. Raise concerns about changes
early. Or just tell this list about possible security implications of
fixes in -stable by replying to the announcements. There's plenty of
possibilities to contribute and hence increase the quality.
Best regards,
Stefan Roas
> the relative security of linux and the likely hood that smart people
> are able to cause a bit of mindless vandalism or get up to much worse.
Distributions assign CVE numbers to kernel vulnerabilities. As
distributions like Fedora ship current kernels they provide a pretty
complete summary.
> One more thing I'd like to throw out there on the issue of
> accountability is this: How do I know that some developers have not
> been paid to specifically introduce some obscure security flaw?
Wrong question. Thats a very naïve basis for thinking about security. Why
should end users care whether a flaw was added deliberately or by
mistake. What matters is that the flaw is identified. A passive attacker
observing a flaw and using it is at least as dangerous if not more so
than an active attacker.
Alan
On Wed, Jul 16, 2008 at 04:05:07PM +0000, Cheradenine Zakalwe wrote:
> Right, for a start, if I was a professor at university I'd much rather
> some "smart" students crashed 100 boxes a day for a year than one
> owned several servers. In any case, it seems absurd that anybody
> looking for security holes to either subvert or crash systems would be
> deterred by the lack of security commit messages. They already know
> what they are looking for. On the other hand, there has to be some
> metrics available for normal people to make an informed decision about
> the relative security of linux and the likely hood that smart people
> are able to cause a bit of mindless vandalism or get up to much worse.
>
> Your hand waving and obfuscation simply do not wash. The bugs being
> talked about are not just any bugs. They have their own commercial
> value because they can allow the complete subversion of your systems.
Bear in mind that top linux development does not happen in a
corporation. So "commercial value" is a complete non-issue.
Corporations like RedHat and SUSE care about this though. If
you want guarantees and documented security - that is where you
want to go. Not to the kernel mailing list.
> This (for most people I'd guess) is far more dangerous than simply
> having their computers crash.
Sure. And kernel developers don't want their machines
taken over either. So they do fix security bugs.
> This business of passing the buck onto vendors is also absurd. If
Not absurd if you think about it. Most linux developers don't develop
linux for money - they don't have customers - so customers have *no*
hold over them at all. Vendors are the ones who have to care, so they
do that.
Still, linux security is good for a different reason - there is prestige
in making linux good, and so developers strive for that. Also,
security-concerned vendors are always welcome to bring security
patches...
> security is not built into your development mindset and models from
Each developer has the mindset "what I want from linux". That's
what you get from such a loosely organized effort. But many actually
wants security, so you get that even without a clear policy.
> One more thing I'd like to throw out there on the issue of
> accountability is this: How do I know that some developers have not
> been paid to specifically introduce some obscure security flaw? Given
> that such subversions happen frequently in every other field of human
> endeavour where potential profit is involved, this is not beyond the
> realms of possibility.
This is much harder to do in linux, than in a closed-source system. If I
bribe a key microsoft developer to put in a backdoor, then nobody notice
until I exploit it - for the source code is a trade secret.
If i bribe a linux developer to put in a backdoor, then this developer's
patch will likely be rejected by the upstream maintainer or Linus, for
containing a griveous scurity flaw. And if it isn't caught immediately,
then it will still be open for all to see.
Also, bribing a key linux developer is probably much harder, since
they work for pride instead of money. Someone getting caught
would likely never be trusted in open-source development again,
a dramatic loss for such a person.
> If the attitudes of the people at the top of linux development don't
> change this is the end of the linux experiment for me and i'm sure
> many other people. The percieved benifits of transparancy, openness
> and cost will have been completely smashed for the vast majority of
> users. This is not something to be taken lightly.
Current attitudes has brought linux where it is today - it works very
well.
Helge Hafting