kernel-2.6: ipsec without devices

kernel-2.6: ipsec without devices

[richard lucassen]

Hello list,

Anyone an explanation (or a link to an explanation) why the IPSEC
implementation in kernel-2.6 doesn't use devices like "ipsec0"? I
searched google, but I can't find anything on this subject. For tunnels
between Linux-boxes I can use OpenVPN of course, but for all other
connections I only can use the kernel-IPSEC. And I prefer not to use
FreeSWAN.

I really miss these devices. E.g.: I can't do a tcpdump on the tunnel to
see what's happening there, nor can I do some shaping *in* the tunnel.

Or have I missed something crucial?

Richard.

-- 
___________________________________________________________________
Recursion: see recursion

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
| Public key and email address:                                    |
| http://www.lucassen.org/mail-pubkey.html                         |
+------------------------------------------------------------------+

Re: kernel-2.6: ipsec without devices

[Antony Stone]

On Thursday 05 August 2004 10:33 am, richard lucassen wrote:

> Hello list,
>
> Anyone an explanation (or a link to an explanation) why the IPSEC
> implementation in kernel-2.6 doesn't use devices like "ipsec0"?

My understanding of this is that the kernel developers simply didn't like the 
concept of "virtual" interfaces for no (essential) reason.   When FreeS/WAN 
was a patch to the 2.4 kernel, it was necessary to create these interfaces to 
get things working, but now that the code is integrated inside the kernel 
itself, the pseudo-devices are no longer needed, so they've been removed.

I tend to agree with you that they were a useful way to keep track of which 
packets were going where, and I think from a firewalling point of view the 
new 2.6 implementation of IPsec is not as easy to work with.

Regards,

Antony.

-- 
Late in 1972 President Richard Nixon announced that the rate of increase of 
inflation was decreasing.   This was the first time a sitting president used 
a third derivative to advance his case for re-election.

 - Hugo Rossi, Notices of the American Mathematical Society

                                                     Please reply to the list;
                                                           please don't CC me.

Re: kernel-2.6: ipsec without devices

[richard lucassen]

On Thu, 5 Aug 2004 11:09:34 +0100
Antony Stone <Antony@Soft-Solutions.co.uk> wrote:

> On Thursday 05 August 2004 10:33 am, richard lucassen wrote:
> 
> > Anyone an explanation (or a link to an explanation) why the IPSEC
> > implementation in kernel-2.6 doesn't use devices like "ipsec0"?
> 
> My understanding of this is that the kernel developers simply didn't
> like the concept of "virtual" interfaces for no (essential) reason.  
> When FreeS/WAN was a patch to the 2.4 kernel, it was necessary to
> create these interfaces to get things working, but now that the code
> is integrated inside the kernel itself, the pseudo-devices are no
> longer needed, so they've been removed.
> 
> I tend to agree with you that they were a useful way to keep track of
> which packets were going where, and I think from a firewalling point
> of view the new 2.6 implementation of IPsec is not as easy to work
> with.

I just found this pdf on the net with a clear explanation of what's
going on. I'm glad to hear that I'm not the only one who's feeling
uncomfortable with the IPSEC implementation in 2.6. Hopefully the newer
versions of 2.6 will give us back the good old ipsec devices.

http://www.xelerance.com/talks/linuxtag2004/IPseconLinux.pdf

R.

-- 
___________________________________________________________________
Recursion: see recursion

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
| Public key and email address:                                    |
| http://www.lucassen.org/mail-pubkey.html                         |
+------------------------------------------------------------------+

Re: kernel-2.6: ipsec without devices

[Les Mikesell]

On Thu, 2004-08-05 at 05:25, richard lucassen wrote:
> > I tend to agree with you that they were a useful way to keep track of
> > which packets were going where, and I think from a firewalling point
> > of view the new 2.6 implementation of IPsec is not as easy to work
> > with.

A more fundamental question: does anyone know why Linux uses
pseudo devices for networking instead of having real names
in /dev with associated permissions and inodes connected
to drivers by major/minor numbers?  It seems odd not to
be able to control access to /dev/tcp by group permisions
like you can every other device.

---
  Les Mikesell
    les@futuresource.com

Re: kernel-2.6: ipsec without devices

[Tobias DiPasquale]

On Thu, 05 Aug 2004 07:35:09 -0500, Les Mikesell <les@futuresource.com> wrote:
> A more fundamental question: does anyone know why Linux uses
> pseudo devices for networking instead of having real names
> in /dev with associated permissions and inodes connected
> to drivers by major/minor numbers?  It seems odd not to
> be able to control access to /dev/tcp by group permisions
> like you can every other device.

Because network devices aren't easily manipulated using the standard
UNIX "everything is a file" methodology. They are packet-oriented, as
opposed to character- or block-oriented and as such, the normal
read()/write()/close()/etc suite of system calls doesn't make sense
for network devices (therefore, there's no reason to have a /dev file
for them). Also, network devices push packets towards the kernel
asynchronously (as far as the kernel's concerned, anyway);
chrdev/blkdev devices do so in response to some kind of request. No
UNIX(-alike) that I know of has /dev files that correspond to network
devices.

-- 
[ Tobias DiPasquale ]
0x636f6465736c696e67657240676d61696c2e636f6d

Re: kernel-2.6: ipsec without devices

[Les Mikesell]

On Thu, 2004-08-05 at 08:05, Tobias DiPasquale wrote:
> On Thu, 05 Aug 2004 07:35:09 -0500, Les Mikesell <les@futuresource.com> wrote:
> > A more fundamental question: does anyone know why Linux uses
> > pseudo devices for networking instead of having real names
> > in /dev with associated permissions and inodes connected
> > to drivers by major/minor numbers?  It seems odd not to
> > be able to control access to /dev/tcp by group permisions
> > like you can every other device.
> 
> Because network devices aren't easily manipulated using the standard
> UNIX "everything is a file" methodology. They are packet-oriented, as
> opposed to character- or block-oriented and as such, the normal
> read()/write()/close()/etc suite of system calls doesn't make sense
> for network devices (therefore, there's no reason to have a /dev file
> for them).

But it still makes as much sense to require open() to pass the
access control restrictions as it does for every other device.

>  Also, network devices push packets towards the kernel
> asynchronously (as far as the kernel's concerned, anyway);
> chrdev/blkdev devices do so in response to some kind of request. No
> UNIX(-alike) that I know of has /dev files that correspond to network
> devices.

I've forgotten the details because it was years ago, but I'm sure
the last 'real' SysVr4 I used (perhaps Dell's, or AT&T's) had a
/dev/tcp or similar device that was opened as a step in opening
a socket and subject to the same rules as every other unix device.
A local ISP back in the days when people would telnet in to
access character-mode email/news, etc. used this to distinguish
accounts that could make direct outbound connections from those
that could only run programs to access the local mailbox and
news spool.  I was very surprised when I first saw that Linux
omitted such a basic basic security concept of unix (all the
magic happens in open()).  As far as the network goes, it is
the same thing as Lindows/Linspire defaulting to letting everyone
run as root.

---
  Les Mikesell
   les@futuresource.com

Re: kernel-2.6: ipsec without devices

[Tobias DiPasquale]

On Thu, 05 Aug 2004 10:48:43 -0500, Les Mikesell <les@futuresource.com> wrote:
> But it still makes as much sense to require open() to pass the
> access control restrictions as it does for every other device.

It ceases to make sense once you realize that you are not opening the
"device", per se, but simply a socket that is bourne by said device.
Character and block devices use open() to open the device itself. A
network device is "always on", so to speak, and you use socket() to
create a communications channel through that device.

> I was very surprised when I first saw that Linux
> omitted such a basic basic security concept of unix (all the
> magic happens in open()).  As far as the network goes, it is
> the same thing as Lindows/Linspire defaulting to letting everyone
> run as root.

I see your point. But this interface was designed over 20 years ago by
the BSD team and it certainly made sense from their perspective to
create a new set of system calls because this type of device did not
neatly fit into the "everything is a file" paradigm that UNIX uses.
But, clearly, it would be a great benefit if you could set your eth0
to 0600 root:root and prevent regular users from abusing the network
card.

The question is, though, what would doing that actually mean? I
believe the impediment to this solution is that the card signals the
kernel of incoming packets with no warning, and thus checking the user
permissions is not possible since the handling of network devices
happens all in interrupt context (i.e. not on behalf of a particular
user). As well, the datalink, network and transport layers have no
concept of user permissions or ownership and you couldn't tack one on
without implementing a global authentication scheme that everyone
involved adheres to.

-- 
[ Tobias DiPasquale ]
0x636f6465736c696e67657240676d61696c2e636f6d