Re: [PATCH 1/2] audit: fix NUL handling in untrusted strings

[John Dennis <jdennis@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1656 bytes --]

Miloslav Trmač wrote:
> John Dennis píše v Čt 11. 09. 2008 v 13:30 -0400:
>   
>> Special processing with regards to the presence or absence of a null
>> byte is one example of prohibited interpretation.
>>     
> This is UNIX, "string" means "NUL-terminated string" (in fact the
> presence of a NUL byte is the only way to reasonably detect binary
> data). 
>
>   
A primary purpose of the audit system is to log with the greatest 
accuracy possible the actual data. If that data somehow contained a 
null, even in a context in which a null would have been prohibited, the 
audit system absolutely needs to be able to correctly record that 
aberrant event and it's actual data. If the audit system failed at that 
moment it's failing at the worst possible moment, the moment when you're 
looking for bad data.

A UNIX-like operating system does not in and of itself mandate the 
default conventions of the C programming language. A great danger and 
the source of bugs is making assumptions concerning how to interpret 
octet sequences. By far and away the worst possible place to make a 
mistake handling an octet sequence is in the kernel. It would be wrong 
for the audit system to assume the memory block it was pointed to only 
ever contained null terminated ascii strings, especially when the memory 
block is terminated by virtue of an octet count.
> You're far more likely to encounter a fixed-length field with an
> optional terminating NUL (like the old-style, 16-byte directory entries)
> than an ASCII-compatible string that intentionally contains a NUL byte.
>   

-- 
John Dennis <jdennis@redhat.com>


[-- Attachment #1.2: Type: text/html, Size: 2274 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]