misc things
Paul Rusty Russell
Paul.Russell@rustcorp.com.au
Wed, 22 Sep 1999 03:06:12 +0930
In message <Pine.LNX.4.10.9909061840020.30977-100000@ontario.alcove-int> you wr
ite:
> Hi Rusty,
>
> Hope you're doing well. Here it is :
>
> #ifdef USE_POWERS_FOR_EVIL /* yes, some actually read the source ! ;-) */
Hey, we have a winner! Everyone else, pay attention... (Bonus points
for figuring out what it does).
> In packet-filter/extentions/ipt_unclean.c, it seems you forgot one 576
> (maybe a macro would be good ?) :
> limpk("First fragment size %u < 576\n", ntohs(iph->tot_len));
Thanks, fixed.
> In ipnatctl.8 :
> .\" Man page written by Rusty, based on iptables page by
> .\" Herve Eychenne <eychenne@info.enserb.u-bordeaux.fr>, based on
> .\" ipchains page by Paul ``Rusty'' Russell March 1997
> .\" Based on the original ipfwadm man page by Jos Vos <jos@xos.nl>, who was
> .\" probably the only one who actually grokked nroff.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Thanks, I had a good laugh. :-))
I'd forgotten about that. 8-)
> In iptables.c :
> /* FIXME: Userspace can determine that there are no loops, and should
> do so, elimintating loop check and simplifying this code. --RR */
>
> The point is that there should be *no* way to do any loop (thus hang the
> kernel). Would the test be done in the lib or in iptables ?
> In both cases, if in userspace, it would possible to bypass the tests.
> But as long as rules can only be set as root, there would always be a way
> to compromise kernel integrity...
There are precedents for allowing root to screw the machine up. There
are also precedents the other way; it depends on how
optimization-obsessed the kernel author is, really. The loop check
*could* be done statically in the kernel at table insertion time.
That means it has to be done without recursion...
<thinks>
Ick.
</thinks>
> I guess you've already updated iptables man page (QUEUE, REJECT, state,
> unclean, etc...), so I won't provide an already obsolete patch this
> time. ;-)
Oh. Yeah... thanks, will do.
Rusty.
--
Hacking time.