Can I put a process in a "network jail", like the "chroot jail"
Ignoramus29044
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
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
Mark Hobley
> 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/
Mark Hobley
> 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 Hobley
> 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.
Rainer Weikusat
You could run them inside a so-called 'Linux container' with an
'empty' network namespace, cf
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
You could run them inside a so-called 'Linux container' with an
'empty' network namespace, cf
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
General Schvantzkoph
You could create a VM with no gateway and no DNS resolution.
Mark
<schvan...@yahoo.com> wrote:
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.
Richard Kettlewell
>>> 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
Why?
Richard Kettlewell
> Richard Kettlewell <r...@greenend.org.uk> wrote:
>> Mark <i...@dontgetlotsofspamanymore.invalid> writes:
>>> General Schvantzkoph <schvan...@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...
Mark
<r...@greenend.org.uk> wrote:
>Mark <i...@dontgetlotsofspamanymore.invalid> writes:
>> Richard Kettlewell <r...@greenend.org.uk> wrote:
>>> Mark <i...@dontgetlotsofspamanymore.invalid> writes:
>>>> General Schvantzkoph <schvan...@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...
--
Richard Kettlewell
> Richard Kettlewell <r...@greenend.org.uk> wrote:
>> Mark <i...@dontgetlotsofspamanymore.invalid> writes:
>>>>...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*.
Richard Kettlewell
> 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.
The Natural Philosopher
> Ignoramus29044 <ignoram...@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..
Richard Kettlewell
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.
Mark
<r...@greenend.org.uk> wrote:
>Mark <i...@dontgetlotsofspamanymore.invalid> writes:
>> Richard Kettlewell <r...@greenend.org.uk> wrote:
>>> Mark <i...@dontgetlotsofspamanymore.invalid> writes:
>>>> Richard Kettlewell <r...@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.
Cong Wang
> 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.
>
Rainer Weikusat
> 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.
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.