netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: linux-os@analogic.com
Cc: James Morris <jmorris@redhat.com>,
	Patrick McHardy <kaber@trash.net>,
	Bryan Fulton <bryan@coverity.com>,
	netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org,
	linux-kernel@vger.kernel.org
Subject: Re: [Coverity] Untrusted user data in kernel
Date: Fri, 17 Dec 2004 13:37:16 -0500	[thread overview]
Message-ID: <41C3275C.2010505@tmr.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0412171108340.4216@chaos.analogic.com>

linux-os wrote:
> On Fri, 17 Dec 2004, Bill Davidsen wrote:
> 
>> James Morris wrote:
>>
>>> On Fri, 17 Dec 2004, Patrick McHardy wrote:
>>>
>>>
>>>> James Morris wrote:
>>>>
>>>>
>>>>> This at least needs CAP_NET_ADMIN.
>>>>>
>>>>
>>>> It is already checked in do_ip6t_set_ctl(). Otherwise anyone could
>>>> replace iptables rules :)
>>>
>>>
>>>
>>> That's what I meant, you need the capability to do anything bad :-)
>>
>>
>> Are you saying that processes with capability don't make mistakes? 
>> This isn't a bug related to untrusted users doing privileged 
>> operations, it's a case of using unchecked user data.
>>
> 
> But isn't there always the possibility of "unchecked user data"?
> I can, as root, do `cp /dev/zero /dev/mem` and have the most
> spectacular crask you've evet seen. I can even make my file-
> systems unrecoverable.

But that's not the type of thing you would do by accident. The kernel 
can't protect against deliberate abuse by trusted users, nor should it. 
But the type of problem caused by an application program bug can, and I 
believe should, be caught.

The difference between "oops" and "take that!"

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

  parent reply	other threads:[~2004-12-17 18:37 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1103247211.3071.74.camel@localhost.localdomain>
2004-12-17  5:15 ` [Coverity] Untrusted user data in kernel James Morris
2004-12-17  5:25   ` Patrick McHardy
2004-12-17  6:45     ` James Morris
2004-12-17 13:18       ` Tomas Carnecky
2004-12-17 19:16         ` David S. Miller
2004-12-17 19:34           ` Tomas Carnecky
2004-12-17 19:30             ` David S. Miller
2004-12-17 15:47       ` Bill Davidsen
2004-12-17 16:11         ` linux-os
2004-12-17 16:31           ` Oliver Neukum
2004-12-17 18:37           ` Bill Davidsen [this message]
2004-12-17 19:18           ` Tomas Carnecky
2004-12-17 19:30             ` Oliver Neukum
2004-12-17 19:39               ` Tomas Carnecky
2004-12-18  1:42           ` Horst von Brand
2004-12-17 15:10   ` Pavel Machek
2004-12-17 15:38     ` James Morris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41C3275C.2010505@tmr.com \
    --to=davidsen@tmr.com \
    --cc=bryan@coverity.com \
    --cc=jmorris@redhat.com \
    --cc=kaber@trash.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.com \
    --cc=netdev@oss.sgi.com \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).