|Subject:||Re: [Coverity] Untrusted user data in kernel|
|From:||Tomas Carnecky <tom@xxxxxxxxxxxxx>|
|Date:||Fri, 17 Dec 2004 20:18:15 +0100|
|Cc:||Bill Davidsen <davidsen@xxxxxxx>, James Morris <jmorris@xxxxxxxxxx>, Patrick McHardy <kaber@xxxxxxxxx>, Bryan Fulton <bryan@xxxxxxxxxxxx>, netdev@xxxxxxxxxxx, netfilter-devel@xxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx|
|References:||<41C26DD1.7070006@xxxxxxxxx> <Xine.LNX.4.44.0412170144410.12579-100000@xxxxxxxxxxxxxxxxxxxxxxxx> <41C2FF99.3020908@xxxxxxx> <Pine.LNX.4.61.0412171108340.4216@xxxxxxxxxxxxxxxxxx>|
|User-agent:||Mozilla Thunderbird 1.0 (Windows/20041206)|
On Fri, 17 Dec 2004, Bill Davidsen wrote:James Morris wrote:On Fri, 17 Dec 2004, Patrick McHardy wrote:
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 the difference between you example (cp /dev/zero /dev/mem) and passing unchecked data to the kernel is... you _can_ check the data and do something about it if you discover that the data is not valid/within a range/whatever even if the user has full permissions. No same person would do a 'cp /dev/zero /dev/mem', but passing bad data is more likely to happen, badly written userspace configuration tools etc.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: primary and secondary ip addresses, Hasso Tepper|
|Next by Date:||Re: primary and secondary ip addresses, Henrik Nordstrom|
|Previous by Thread:||Re: [Coverity] Untrusted user data in kernel, Bill Davidsen|
|Next by Thread:||Re: [Coverity] Untrusted user data in kernel, Oliver Neukum|
|Indexes:||[Date] [Thread] [Top] [All Lists]|