Re: Some thoughts about stable kernel development
From: John Bradford (john_at_grabjohn.com)
Date: 11/11/03
- Previous message: Sean Neakums: "Re: Fibre channel HBA support"
- In reply to: Valdis.Kletnieks_at_vt.edu: "Re: Some thoughts about stable kernel development"
- Next in thread: Matt: "Re: Some thoughts about stable kernel development"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 11 Nov 2003 08:53:09 GMT To: Valdis.Kletnieks@vt.edu
Quote from Valdis.Kletnieks@vt.edu:
> --==_Exmh_1622051872P
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, 10 Nov 2003 08:50:44 GMT, John Bradford <john@grabjohn.com> said:
>
> > cause annoyance to third parties. Given that, I think a file in the
> > root of the kernel tree, saying something like, "Don't use me on an
> > internet connected machine unless you know what you're doing" would be
> > worth considering.
>
> OK.. I'll bite.. :)
>
> What *additional* level of "know what you're doing" is called for, over and
> above the usual "best practices" we wish all net-connected machines implemented?
>
> Or phrased differently - yes, there's several local-user-gets-root attacks that
> aren't patched. However, I'm sure that even a tightened down and fully-patched
> system has several ways to do that without leveraging a kernel bug, so the
> question becomes "balance the chances that the attacker has an exploit for the
> kernel bug" against "chance attacker has exploit for set-UID program XYZ".
>
> Or is the assumption that if you understand how "remote execution of
> arbitrary code as local user" combines with "local user gets root" to
> form the product "you're screwed", sufficient clue is available?
I don't even know why this thread is continuing - I have already
pointed out that I intended to cancel my original post, but hit the
wrong key. I.E. I had changed my mind about the importance of the
issue. If you don't belive me, note the face that I hadn't trimmed
the quotes on the original post, and the fact that it was addressed as
a private comment to Linus, anyway, (I hadn't yet removed the CC
list).
Nevertheless, I the point I just brought up is much simpler than you
are making it seem.
My experience, at least, has been that during the development of most
userspace applications, security fixes which apply to both stable and
unstable branches are applied at the same time. I think users have
come to expect that, even though that is bad practice.
In any case - we work differently, and don't make that fact at all
obvious. Rather than suggesting we change the way we work, (not
practical), I am suggesting that we educate people, (not easy, but we
can do our bit - provide the information).
The upshot of all this is that an admin who is _generally responsible
and knows what he is doing_, may well be under the impression that
running a development kernel on a network connected box may eat his
filesystem, but that it would not contain _known_ security
vulnerabilities. Be aware that a compromised box could be used as a
vector for attack on other boxes, including those of innocent third
parties, (E.G. on a datacentre LAN).
A typical admin may decide to run, E.G. a news server or web proxy
server with a development kernel, on the basis that even if the
machine is trashed, it doesn't matter, not being aware of the security
issues.
John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Sean Neakums: "Re: Fibre channel HBA support"
- In reply to: Valdis.Kletnieks_at_vt.edu: "Re: Some thoughts about stable kernel development"
- Next in thread: Matt: "Re: Some thoughts about stable kernel development"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
