Can I put a process in a "network jail", like the "chroot jail"

[Ignoramus29044]

I am working on something where I would have processes that handle
user contributed data, in a way where I feel that I have to restrict
them as much as possible. I wand them to read stdin, and produce
stdout and stderr only.

I do not want them to access the file system, which is done easily
with a chroot jail. This is easy.

I also do not want those processes to do connect() and use any
networking. And here's where I am lost. Is there some way to drop a
process privilege to use networking?

thanks

i

[Tim Watts]

Post by Ignoramus29044
I am working on something where I would have processes that handle
user contributed data, in a way where I feel that I have to restrict
them as much as possible. I wand them to read stdin, and produce
stdout and stderr only.
I do not want them to access the file system, which is done easily
with a chroot jail. This is easy.
I also do not want those processes to do connect() and use any
networking. And here's where I am lost. Is there some way to drop a
process privilege to use networking?
thanks
i

Well, it doesn't exist as a Capability bit so that's out.

If the processes are running as one or more defined non root UIDs you could
block them with [iptables --uid-owner...]

This does not stop them receiving packets, but it stops them sending any
which pretty much neuters them.

Would that work?

Tim

[Mark Hobley]

Post by Ignoramus29044
I also do not want those processes to do connect() and use any
networking. And here's where I am lost. Is there some way to drop a
process privilege to use networking?

A network jail is a good idea for a new tool.

Mark.

[Mark Hobley]

Post by Ignoramus29044
I also do not want those processes to do connect() and use any
networking. And here's where I am lost. Is there some way to drop a
process privilege to use networking?

A network jail is a good idea for a new tool.

Mark.

[Rainer Weikusat]

Post by Ignoramus29044
I am working on something where I would have processes that handle
user contributed data, in a way where I feel that I have to restrict
them as much as possible. I wand them to read stdin, and produce
stdout and stderr only.
I do not want them to access the file system, which is done easily
with a chroot jail. This is easy.
I also do not want those processes to do connect() and use any
networking. And here's where I am lost. Is there some way to drop a
process privilege to use networking?

You could run them inside a so-called 'Linux container' with an
'empty' network namespace, cf

http://lxc.sourceforge.net

NETWORK

The network section defines how the network is virtualized in
the container. The network virtualization acts at layer two. In
order to use the network virtualization, parameters must be
specified to define the network interfaces of the
container. Several virtual interfaces can be assigned and used
in a container even if the system has only one physical network
interface.

lxc.network.type

specify what kind of network virtualization to be used
for the container. Each time a lxc.network.type field is
found a new round of network con- figuration begins. In
this way, several network virtualization types can be
specified for the same container, as well as assigning
several net- work interfaces for one container. The
different virtualization types can be:

empty: will create only the loopback interface.
[lxc.conf(5)]

The company I work for uses this in production to host 'virtual IPsec
gateways' (with added security features) for different customers on
shared computers and because of this, I can confidentially state that
it is stable (the main drawback is that the netfilter people generally
don't care for network namespace support and are thus neither willing
to implement it themselves nor to accept patches of people who do[*]).

[*] Yes, I'm writing about me. I don't usually bother to
submit 'feature contributions' to Linux because this is, in my
experience, simply a total waste of time: If the responsible
people cared for the issue, it wouldn't exist and since they
don't it will persist.

[Rainer Weikusat]

Post by Ignoramus29044
I am working on something where I would have processes that handle
user contributed data, in a way where I feel that I have to restrict
them as much as possible. I wand them to read stdin, and produce
stdout and stderr only.
I do not want them to access the file system, which is done easily
with a chroot jail. This is easy.
I also do not want those processes to do connect() and use any
networking. And here's where I am lost. Is there some way to drop a
process privilege to use networking?

You could run them inside a so-called 'Linux container' with an
'empty' network namespace, cf

http://lxc.sourceforge.net

NETWORK

The network section defines how the network is virtualized in
the container. The network virtualization acts at layer two. In
order to use the network virtualization, parameters must be
specified to define the network interfaces of the
container. Several virtual interfaces can be assigned and used
in a container even if the system has only one physical network
interface.

lxc.network.type

specify what kind of network virtualization to be used
for the container. Each time a lxc.network.type field is
found a new round of network con- figuration begins. In
this way, several network virtualization types can be
specified for the same container, as well as assigning
several net- work interfaces for one container. The
different virtualization types can be:

empty: will create only the loopback interface.
[lxc.conf(5)]

The company I work for uses this in production to host 'virtual IPsec
gateways' (with added security features) for different customers on
shared computers and because of this, I can confidently state that
it is stable (the main drawback is that the netfilter people generally
don't care for network namespace support and are thus neither willing
to implement it themselves nor to accept patches of people who do[*]).

[*] Yes, I'm writing about me. I don't usually bother to
submit 'feature contributions' to Linux because this is, in my
experience, simply a total waste of time: If the responsible
people cared for the issue, it wouldn't exist and since they
don't it will persist.

[General Schvantzkoph]

I am working on something where I would have processes that handle user
contributed data, in a way where I feel that I have to restrict them as
much as possible. I wand them to read stdin, and produce stdout and
stderr only.
I do not want them to access the file system, which is done easily with
a chroot jail. This is easy.
I also do not want those processes to do connect() and use any
networking. And here's where I am lost. Is there some way to drop a
process privilege to use networking?
thanks
i

You could create a VM with no gateway and no DNS resolution.

[Mark]

On 17 Jul 2011 23:04:39 GMT, General Schvantzkoph

Post by General Schvantzkoph

I am working on something where I would have processes that handle user
contributed data, in a way where I feel that I have to restrict them as
much as possible. I wand them to read stdin, and produce stdout and
stderr only.
I do not want them to access the file system, which is done easily with
a chroot jail. This is easy.
I also do not want those processes to do connect() and use any
networking. And here's where I am lost. Is there some way to drop a
process privilege to use networking?
thanks
i

You could create a VM with no gateway and no DNS resolution.

Link in dummy versions of connect() and accept() etc...

[Richard Kettlewell]

Post by Mark

Post by General Schvantzkoph

I am working on something where I would have processes that handle user
contributed data, in a way where I feel that I have to restrict them as
much as possible. I wand them to read stdin, and produce stdout and
stderr only.
I do not want them to access the file system, which is done easily with
a chroot jail. This is easy.
I also do not want those processes to do connect() and use any
networking. And here's where I am lost. Is there some way to drop a
process privilege to use networking?

You could create a VM with no gateway and no DNS resolution.

Link in dummy versions of connect() and accept() etc...

...and you still have the underlying syscall to worry about.

[Mark]

On Mon, 18 Jul 2011 19:31:58 +0100, Richard Kettlewell

Post by Richard Kettlewell

Post by Mark

Post by General Schvantzkoph

I am working on something where I would have processes that handle user
contributed data, in a way where I feel that I have to restrict them as
much as possible. I wand them to read stdin, and produce stdout and
stderr only.
I do not want them to access the file system, which is done easily with
a chroot jail. This is easy.
I also do not want those processes to do connect() and use any
networking. And here's where I am lost. Is there some way to drop a
process privilege to use networking?

You could create a VM with no gateway and no DNS resolution.

Link in dummy versions of connect() and accept() etc...

...and you still have the underlying syscall to worry about.

Why?

[Richard Kettlewell]

Post by Richard Kettlewell

Post by Mark

Post by General Schvantzkoph

I am working on something where I would have processes that handle user
contributed data, in a way where I feel that I have to restrict them as
much as possible. I wand them to read stdin, and produce stdout and
stderr only.
I do not want them to access the file system, which is done easily with
a chroot jail. This is easy.
I also do not want those processes to do connect() and use any
networking. And here's where I am lost. Is there some way to drop a
process privilege to use networking?

You could create a VM with no gateway and no DNS resolution.

Link in dummy versions of connect() and accept() etc...

...and you still have the underlying syscall to worry about.

Why?

Because the hypothetical malicious code the OP is worried about could
invoke that rather than the libc function.

Actually it's easier to do that than use libc anyway...

[Mark]

On Tue, 19 Jul 2011 10:15:47 +0100, Richard Kettlewell

Post by Richard Kettlewell

Post by Richard Kettlewell

Post by Mark

Post by General Schvantzkoph

I am working on something where I would have processes that handle user
contributed data, in a way where I feel that I have to restrict them as
much as possible. I wand them to read stdin, and produce stdout and
stderr only.
I do not want them to access the file system, which is done easily with
a chroot jail. This is easy.
I also do not want those processes to do connect() and use any
networking. And here's where I am lost. Is there some way to drop a
process privilege to use networking?

You could create a VM with no gateway and no DNS resolution.

Link in dummy versions of connect() and accept() etc...

...and you still have the underlying syscall to worry about.

Why?

Because the hypothetical malicious code the OP is worried about could
invoke that rather than the libc function.

I didn't know it was that easy to call lower level functions directly.
Wouldn't these vary from one release to the next?

Post by Richard Kettlewell
Actually it's easier to do that than use libc anyway...

[Richard Kettlewell]

Post by Mark

Post by Richard Kettlewell

Post by Richard Kettlewell
...and you still have the underlying syscall to worry about.

Why?

Because the hypothetical malicious code the OP is worried about could
invoke that rather than the libc function.

I didn't know it was that easy to call lower level functions directly.
Wouldn't these vary from one release to the next?

Not really. Even if it did that would be irrelevant - the hypothetical
attacker only needs to go after whatever the OP was *actually running*.

[Mark]

On Tue, 19 Jul 2011 13:23:10 +0100, Richard Kettlewell

Post by Richard Kettlewell

Post by Mark

Post by Richard Kettlewell

Post by Richard Kettlewell
...and you still have the underlying syscall to worry about.

Why?

Because the hypothetical malicious code the OP is worried about could
invoke that rather than the libc function.

I didn't know it was that easy to call lower level functions directly.
Wouldn't these vary from one release to the next?

Not really. Even if it did that would be irrelevant - the hypothetical
attacker only needs to go after whatever the OP was *actually running*.

Can't the OP use SELinux access control for this? I haven't tried it
but it is supposed to restrict network access.

[Richard Kettlewell]

Post by Ignoramus29044
I am working on something where I would have processes that handle
user contributed data, in a way where I feel that I have to restrict
them as much as possible. I wand them to read stdin, and produce
stdout and stderr only.

Is this out of native caution or are you hoping to comply with some set
of laws or regulations?

Post by Ignoramus29044
I do not want them to access the file system, which is done easily
with a chroot jail. This is easy.
I also do not want those processes to do connect() and use any
networking. And here's where I am lost. Is there some way to drop a
process privilege to use networking?

Another option to consider would be to use a separate machine with no
network connection and connect it to the outside using a serial port
(over which your stdin/out/err are carried).

This is closely analogous to the VM/container suggestions but avoids
relying on software to isolate the sensitive code (at least to the same
extent). It's also more expensive, of course.

[The Natural Philosopher]

Post by Richard Kettlewell

Post by Ignoramus29044
I am working on something where I would have processes that handle
user contributed data, in a way where I feel that I have to restrict
them as much as possible. I wand them to read stdin, and produce
stdout and stderr only.

Is this out of native caution or are you hoping to comply with some set
of laws or regulations?

Post by Ignoramus29044
I do not want them to access the file system, which is done easily
with a chroot jail. This is easy.
I also do not want those processes to do connect() and use any
networking. And here's where I am lost. Is there some way to drop a
process privilege to use networking?

Another option to consider would be to use a separate machine with no
network connection and connect it to the outside using a serial port
(over which your stdin/out/err are carried).

...and than watch your hypothetical hacker construct a PPP link over the
serial port..

[Richard Kettlewell]

Post by The Natural Philosopher

Post by Richard Kettlewell

Post by Ignoramus29044
I do not want them to access the file system, which is done easily
with a chroot jail. This is easy.
I also do not want those processes to do connect() and use any
networking. And here's where I am lost. Is there some way to drop a
process privilege to use networking?

Another option to consider would be to use a separate machine with no
network connection and connect it to the outside using a serial port
(over which your stdin/out/err are carried).

...and than watch your hypothetical hacker construct a PPP link over
the serial port..

If the attacker can control what's on the 'secured' side of that link
then they have already won, and should have no need to use anything as
complex as PPP to get the data back out.

The point of the exercise is, AIUI, to reduce the software-addressable
attack surface to the single bidirection channel that the software
unavoidably needs. The software still needs to be immune to attack
through that channel.

[Rainer Weikusat]

Post by Ignoramus29044
I am working on something where I would have processes that handle
user contributed data, in a way where I feel that I have to restrict
them as much as possible. I wand them to read stdin, and produce
stdout and stderr only.

If you're so afraid of unknown bugs in your own code, don't bother
with anything fancy: This means you have to write even more code and
why would that be any less buggy?

NB: This is a completely serious statement in form of a rethorical
question. The only way to be safe from 'yet unknown future dangers' is
immediate suicide.

[The Natural Philosopher]

Post by Rainer Weikusat

Post by Ignoramus29044
I am working on something where I would have processes that handle
user contributed data, in a way where I feel that I have to restrict
them as much as possible. I wand them to read stdin, and produce
stdout and stderr only.

If you're so afraid of unknown bugs in your own code, don't bother
with anything fancy: This means you have to write even more code and
why would that be any less buggy?
NB: This is a completely serious statement in form of a rethorical
question. The only way to be safe from 'yet unknown future dangers' is
immediate suicide.

even that is not a secure option, given religious uncertainties ;-)