f



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

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
0
Ignoramus29044
7/17/2011 2:53:23 AM
comp.os.linux.misc 33599 articles. 1 followers. amosa69 (78) is leader. Post Follow

20 Replies
729 Views

Similar Articles

[PageSpeed] 51

Ignoramus29044 wrote:

> 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

-- 
Tim Watts
0
tw86 (68)
7/17/2011 7:47:46 AM
On Sat, 16 Jul 2011 21:53:23 -0500, Ignoramus29044 wrote:

> 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
Linux User: #370818  http://markhobley.yi.org/

0
markhobley3 (126)
7/17/2011 5:11:56 PM
On Sat, 16 Jul 2011 21:53:23 -0500, Ignoramus29044 wrote:

> 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
Linux User: #370818  http://markhobley.yi.org/

0
markhobley3 (126)
7/17/2011 5:13:07 PM
On Sat, 16 Jul 2011 21:53:23 -0500, Ignoramus29044 wrote:

> 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
Linux User: #370818  http://markhobley.yi.org/

0
markhobley3 (126)
7/17/2011 5:14:49 PM
Ignoramus29044 <ignoramus29044@NOSPAM.29044.invalid> writes:
> 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.
0
rweikusat (2830)
7/17/2011 6:25:51 PM
Ignoramus29044 <ignoramus29044@NOSPAM.29044.invalid> writes:
> 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.
0
rweikusat (2830)
7/17/2011 7:51:08 PM
On Sat, 16 Jul 2011 21:53:23 -0500, Ignoramus29044 wrote:

> 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. 
0
schvantzkoph (1943)
7/17/2011 11:04:39 PM
On 17 Jul 2011 23:04:39 GMT, General Schvantzkoph
<schvantzkoph@yahoo.com> wrote:

>On Sat, 16 Jul 2011 21:53:23 -0500, Ignoramus29044 wrote:
>
>> 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...
-- 
(\__/)  M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking some articles
posted from there.  If you wish your postings to be seen by
everyone you will need use a different method of posting.

0
i1658 (121)
7/18/2011 10:43:06 AM
Mark <i@dontgetlotsofspamanymore.invalid> writes:
> General Schvantzkoph <schvantzkoph@yahoo.com> wrote:
>> Ignoramus29044 wrote:

>>> 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.

-- 
http://www.greenend.org.uk/rjk/
0
rjk (534)
7/18/2011 6:31:58 PM
On Mon, 18 Jul 2011 19:31:58 +0100, Richard Kettlewell
<rjk@greenend.org.uk> wrote:

>Mark <i@dontgetlotsofspamanymore.invalid> writes:
>> General Schvantzkoph <schvantzkoph@yahoo.com> wrote:
>>> Ignoramus29044 wrote:
>
>>>> 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?
-- 
(\__/)  M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking some articles
posted from there.  If you wish your postings to be seen by
everyone you will need use a different method of posting.

0
i1658 (121)
7/19/2011 8:32:23 AM
Mark <i@dontgetlotsofspamanymore.invalid> writes:
> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>> Mark <i@dontgetlotsofspamanymore.invalid> writes:
>>> General Schvantzkoph <schvantzkoph@yahoo.com> wrote:
>>>> Ignoramus29044 wrote:

>>>>> 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...

-- 
http://www.greenend.org.uk/rjk/
0
rjk (534)
7/19/2011 9:15:47 AM
On Tue, 19 Jul 2011 10:15:47 +0100, Richard Kettlewell
<rjk@greenend.org.uk> wrote:

>Mark <i@dontgetlotsofspamanymore.invalid> writes:
>> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>>> Mark <i@dontgetlotsofspamanymore.invalid> writes:
>>>> General Schvantzkoph <schvantzkoph@yahoo.com> wrote:
>>>>> Ignoramus29044 wrote:
>
>>>>>> 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?

>Actually it's easier to do that than use libc anyway...
-- 
(\__/)  M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking some articles
posted from there.  If you wish your postings to be seen by
everyone you will need use a different method of posting.

0
i1658 (121)
7/19/2011 10:12:01 AM
Mark <i@dontgetlotsofspamanymore.invalid> writes:
> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>> Mark <i@dontgetlotsofspamanymore.invalid> writes:
>>> Richard Kettlewell <rjk@greenend.org.uk> wrote:

>>>>...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*.

-- 
http://www.greenend.org.uk/rjk/
0
rjk (534)
7/19/2011 12:23:10 PM
Ignoramus29044 <ignoramus29044@NOSPAM.29044.invalid> writes:

> 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?

> 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.

-- 
http://www.greenend.org.uk/rjk/
0
rjk (534)
7/19/2011 12:37:42 PM
Richard Kettlewell wrote:
> Ignoramus29044 <ignoramus29044@NOSPAM.29044.invalid> writes:
> 
>> 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?
> 
>> 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..
0
tnp (2409)
7/19/2011 2:43:50 PM
The Natural Philosopher <tnp@invalid.invalid> writes:
> Richard Kettlewell wrote:
>> Ignoramus29044 <ignoramus29044@NOSPAM.29044.invalid> writes:

>>> 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.

-- 
http://www.greenend.org.uk/rjk/
0
rjk (534)
7/19/2011 3:09:32 PM
On Tue, 19 Jul 2011 13:23:10 +0100, Richard Kettlewell
<rjk@greenend.org.uk> wrote:

>Mark <i@dontgetlotsofspamanymore.invalid> writes:
>> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>>> Mark <i@dontgetlotsofspamanymore.invalid> writes:
>>>> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>
>>>>>...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.
-- 
(\__/)  M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking some articles
posted from there.  If you wish your postings to be seen by
everyone you will need use a different method of posting.

0
i1658 (121)
7/20/2011 8:04:18 AM
["Followup-To:" header set to comp.os.linux.development.system.]
On Sun, 17 Jul 2011 at 17:14 GMT, Mark Hobley <markhobley@yahoo.donottypethisbit.co> wrote:
> On Sat, 16 Jul 2011 21:53:23 -0500, Ignoramus29044 wrote:
>
>> 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.
>

You might want to try Linux containers, LXC.
0
2/4/2012 7:05:09 AM
Ignoramus29044 <ignoramus29044@NOSPAM.29044.invalid> writes:
> 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.

0
rweikusat (2830)
2/4/2012 7:01:29 PM
Rainer Weikusat wrote:
> Ignoramus29044 <ignoramus29044@NOSPAM.29044.invalid> writes:
>> 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 ;-)
0
tnp (2409)
2/4/2012 7:03:10 PM
Reply: