Re: [Ipsec-tools-devel] configuration reload without loosing existing tunnels

[Aidas K. <a.k...@gm...>]

There is proverb "Mornign is clever than evening". And this morning 
brought some ideas :-)

Emmanuel Dreyfus wrote:
> Aidas Kasparas <a.k...@gm...> wrote:
> 
> 
>>First, my knowledge about privilege separation is mostly based on 
>>experience with apache's suexec. I recognize, it is limited. But in case
>>it is _VERY_ limited, please point my mistakes. Based on that limited
>>experience, my undestanding is, that privsep makes sence if we have 
>>simple as hammer privileged part and all the complexity in the 
>>nonprivileged. Parsing files, analysing communication datastream in my
>>book are examples of complex operation.
> 
> 
> Here initial config file parsing is done before dropping root. That's
> difficult to avoid it since the config file tells if we should do
> privilege separation or not.
>   

yes, that's probably unavoidable.

>>>priv needs to have a config update for the following items:
>>>- the script hooks location
>>
>>Can nonpriv signal this back to priv? Or, if you don't trust nonpriv,
>>then, maybe this should be compile-time option?
> 
> 
> nonpriv can indeed tell priv about the new scripts. You pointed the
> issue: that means priv trusts nonpriv. This is critical here, because if
> a compromised nonpriv can decide what script priv will execute, then it
> can have priv doing anything, including groveling /dev/kmem or other bad
> things. 

Priv can refuse to run script if it is not bellow some point in the 
filesystem. For example, it could require that all the script to be 
placed in [subdirectories of] directory /etc/racoon/scripts. This way it 
would be difficult to mess with system, if one do not have write access 
to that dir.

> 
> The only alternative I see for now is having priv parsing the config
> file on its own to refresh the script list.
>  
> 

I'm afraid, I too start to think, that both, priv and nonpriv will have 
to parse config...

>>>- the PSK file location 
>>
>>What does priv does with that location? Or with PSKs?
> 
> 
> it reads a PSK for unpriv. PSK is owned by root, in mode 600, unreadable
> from unpriv. unpriv asks priv for a PSK name and get the PSK back.
> 
> That's not very satisfaying, because a compromised unpriv can disclose
> the PSK to an attacker. But it's better than nothing because at least
> the compromised unpriv cannot suck /etc/shadow. 
> 
> We could improve the thing by having priv doing cryptographic operation
> for unpriv without discolsing the key, but that would make priv much
> more complicated, and the change would be very intrusive, so I think
> it's not a good idea.  
> 
> Anyway. priv must know about PSK file location. Can we just say that
> unpriv will provide the new info?
>  

I have to check, but from KAME's anouncement about racoon2, I've got 
impression, that they have separated IKE protocol part into separate 
executable. Maybe we should consider case with two kinds of nonprivs -- 
one doing IKE negotiation, another storing crypto material?..

>>Yep, handy. Have you seen hardware, which can run racoon and has 
>>hot-swappable network interfaces? I did not. But I would like to see.
>>So, if anybody has such hardware and need (b) or better... you know what
>>to do ;-)
> 
> 
> Unfortunately I was thinking about something quite precise here :)
> 
> I have a PDA running NetBSD and with ipsec-tools used as the VPN client
> to connect to my work's VPN gateway. It has one PCMCIA slot where I can
> plug either a 10baseT ethernet card or a wireless ethernet card. Each
> time I change the card, I swap in and out a network interface.
> 
> I guess it's easy to reach the same scenario with a laptop.   

Bah! I claimed, I have not seen PCMCIA network card! What a shame! ~%}
Obviously I have seen PCMCIA network cards. But when I wrote those words 
I had PCI or similar server oriented network cards in mind. Today I 
realized, that I myself do use alias interfaces, vlan interfaces, ppp. 
All of them are interfaces what can appear and disapear while racoon is 
running. And therefore, this should be handled.

And there is one [crazy] solution for handling new sockets - run several 
racoons side by side. So, if racoon should open new socket, it simply 
opens it in the priv one, sets bypass policies, marks that new socket to 
be used in the new instance and forks another nonpriv, which will listen 
only on that one! I do have one box in production which already runs two 
instances simultaneously. And to save number of instances, on the box 
which adds often and lots of them, it is possible to introduce some 
delay before forking new nonpriv.

And, BTW, how current privsep code handles new interface appearances? :-)

>  
> 
>>>That means any IKE traffic that should go to unpriv will get through
>>>priv first, it does not seems a very good idea. 
>>
>>Well, what's not an idea, which would make me verry happy. But, copying
>>info as is from one socket to another is simple enought operation to be
>>implemented bug-free.
> 
> 
> On the performance point of view, it's a disaster. Think about slow
> machines, you'd devide by 2 the throughput.
>  

Well, in the typical setup, I think that amount of ESP traffic should be 
at least order or two orders of magnitude higher than amount of IKE 
traffic. Therefore, I would not be so pessimistic about impact on 
throughput.

On the other hand, I proposed solution how to avoid that above. Yes, 
running several racoons side by side will increase pfkey traffic. I have 
to make an experiment, but I think that only acquire messages have to be 
broadcasted to all instances. Therefore, that increase IMHO should be 
handleable.

> 
>>On the other hand... If we preallocate some extra sockets before fork,
>>then maybe later we can bind them in privileged part and use in 
>>nonprivileged (this needs to be checked and can be nontrue).
> 
> 
> Hum, yes, you need to be a bit more precise here.
>  

Forget that. We will return here if everything else fails :-)

 > Now I see
> three unresolved points if we reload the config in nonpriv:
> 
> One for scripts:
> 1) how does priv refreshes the script list?
> 
> Two for interface creation: 
> 2) how to bind to a new privilegied port from unpriv
> 3) how to set a bypass policy on a port from unpriv  

To sum up:
1) config reloading should probably be done by both, priv and non priv 
instances (maybe priv one should signal nonpriv to reload);
2,3) what do you think about idea running several racoons side by side?

And another idea. One of first things what racoon does at startup is try 
to get complete list of policies in the kernel (spddump). PFKEY RFC says 
it should not do that (should not relay on this). When there are 
thousands of policiess, that call fails (due to architectural pfkey's 
problems). Kernel provides required policy in acquire messages. 
Therefore, most likely we can stop requesting full copy of policies from 
kernel at startup and just maintain policy cache from acquire and 
spdadd/spddelete messages. This will save memory, and savings can be 
substantial, if we will have lots of policies and lots of racoons 
running simultaneously.


-- 
Aidas Kasparas
IT administrator
GM Consult Group, UAB