For this also, you got my question right.
> Currently our kernel all such code have in modules (where it is
> possible) and that modules aren't loaded by default. This applies for example
> to dccp, sctp, sip, tfp etc. But of course this doesn't protect against
> exploits for more basic network stack parts (like TCP processing).
well.. Still not fully clear. Let me continue, correct me when I'm wrong:
1. What does the stack when modules for this one protocol type are
present on the file system, but not loaded
and it got the data that if this protocol type?
Does it drop any packet that has packet type of something from
/etc/protocols or does it load the module?
If I remember correctly from last time I dealt w/ lots of iptables
rules the modules had to be loaded by operator exactly
specifying them as a comand in script . And according to you - the
things has not changed since that time.
Fine. :)
2. An exploit with remote code execution is most time some data that
gets execution as code,
or a some clever set of replacements of code instructions with a
set of remotely programmed jumps,
or just even one byte replacement in correct code.
Has it any sense to make default protection for at least some of all
possible remote code manipulations?
This is questionable. Does defense from only some situations costs
time? This is also questionable.
So, for just only one example of many possibilities almost unrelated
to reality and the way the network stack does its way:
switch (expression)
{
case constant1:
codes to be executed if expression equals to constant1,
lets think this does no luck for attacker;
break;
case constant2:
codes to be executed if expression equals to constant2,
lets think this does no luck for attacker;
break;
constraint N-2:
break;
case constraintN-1:
case constraintN:
default:
codes to be executed if expression doesn't match to any cases,
lets think that this code is vulnerable that way that jumping here
gaves a remote data execution,
the data is somewhere else;
}
well, lets think that this code is will lead to remote code execution
only if "jmp far ptr address_of_code" landz between default and
constraint N-1.
When the code is made this way and the attacker has to brute adress
for success, our chances to escape landing of remote code-bullet are
probability
based.
And probability to be alive will increase a little when space between
1 and N-2 grows (each have 'break;' that stops attacker from killing
us).
My main question is:
** if we specify exact restrictions by adding -j DROP rule for any
possible protocol numbers that we know we do not use - would we raise
chance to be alive? **
That is question the answer I need. If yes - I'm right spending my own
time to add the -j DROP rules for computers of mine.
I know, though, from Joanna position that non-principal defense is not
a subject to spend time on.
But as you all alreafy know from recent posts - I disagree - we
should use as much chances as we can.
I was saved by this way of thinking when I decided to use
insecure-linux-with-non-perfect-stack-smashing-protection, not the
OpenBSD that was well known to people
to be much secure, but also OpenBSD people these days were against
implementation of non-perfect solutions as were Solar Designer kernel
patches
from their point of view.
Thank you for reading and explaining details of Qubes internals. :)