From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Dennis Subject: Re: get_field_str() and interpret_field() bug with multi-word fields Date: Tue, 12 Aug 2008 16:57:59 -0400 Message-ID: <48A1F957.8070501@redhat.com> References: <0E43BF2D7491F0468B56B1A5C493866B020DD0F1@SAT4MX07.RACKSPACE.CORP> <200808121516.08960.sgrubb@redhat.com> <48A1EB72.6070607@redhat.com> <1218571902.3540.2.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0242093362==" Return-path: In-Reply-To: <1218571902.3540.2.camel@localhost.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Eric Paris Cc: William Kelly , Bret Piatt , linux-audit@redhat.com List-Id: linux-audit@redhat.com This is a multi-part message in MIME format. --===============0242093362== Content-Type: multipart/alternative; boundary="------------010302060406040208030403" This is a multi-part message in MIME format. --------------010302060406040208030403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Paris wrote: > On Tue, 2008-08-12 at 15:58 -0400, John Dennis wrote: > > >> So many people have complained about this; I do not understand the >> resistance to fixing it. The argument it would break something which >> is broken to begin with does not seem like a reasonable justification >> to me. The sooner it's fixed the better IMHO. >> > > Show me the code and I'll start trying to fix the kernel based on that > code as best we can. But before you start read over the article > > Can user-space bugs be kernel regressions? > http://lwn.net/Articles/292143/ > > As soon as you grasp that article send me the code and we'll work > together to fix this problem! > > Perhaps you should grasp the concept this is not a user space bug but a flawed implementation. Anyone with the most basic understanding of parsing and protocols would never defend the current implementation (the fact it's in the kernel does not suspend the laws of computer science and justify it). Let me give you a simple example, suppose this key/value pair was in an audit record: foo=00 How does one know which of the possible values foo has: 1) it's the integer zero (but in what radix? does the leading zero imply octal or is it just an insignificant digit?) 2) it's the hexadecimal encoding of a single character string containing one null byte. 3) it's the 2 character string "00" consisting of two zero characters. The fact is it's ambiguous, it could be any of the above. It's ambiguous because the audit stream is an improperly specified protocol. -- John Dennis --------------010302060406040208030403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Eric Paris wrote: 
On Tue, 2008-08-12 at 15:58 -0400, John Dennis wrote:

  
So many people have complained about this; I do not understand the
resistance to fixing it. The argument it would break something which
is broken to begin with does not seem like a reasonable justification
to me. The sooner it's fixed the better IMHO.
    

Show me the code and I'll start trying to fix the kernel based on that
code as best we can.  But before you start read over the article

Can user-space bugs be kernel regressions?
http://lwn.net/Articles/292143/

As soon as you grasp that article send me the code and we'll work
together to fix this problem!

Perhaps you should grasp the concept this is not a user space bug but a flawed implementation. Anyone with the most basic understanding of parsing and protocols would never defend the current implementation (the fact it's in the kernel does not suspend the laws of computer science and justify it).

Let me give you a simple example, suppose this key/value pair was in an audit record:

foo=00

How does one know which of the possible values foo has:

1) it's the integer zero (but in what radix? does the leading zero imply octal or is it just an insignificant digit?)

2) it's the hexadecimal encoding of a single character string containing one null byte.

3) it's the 2 character string "00" consisting of two zero characters.

The fact is it's ambiguous, it could be any of the above. It's ambiguous because the audit stream is an improperly specified protocol.
-- 
John Dennis <jdennis@redhat.com>
--------------010302060406040208030403-- --===============0242093362== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0242093362==--