From: Victor Porton <porton@narod.ru>
To: Joshua Brindle <brindle@quarksecurity.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"selinux@tycho.nsa.gov" <selinux@tycho.nsa.gov>
Subject: Re: Create new NetFilter table
Date: Fri, 10 Jan 2014 21:52:40 +0200 [thread overview]
Message-ID: <25561389383560@web15m.yandex.ru> (raw)
In-Reply-To: <52D04C59.20406@quarksecurity.com>
10.01.2014, 21:39, "Joshua Brindle" <brindle@quarksecurity.com>:
> Victor Porton wrote:
>
>> I propose to create a new NetFilter table dedicated to rules created programmatically (not by explicit admin's iptables command).
>>
>> Otherwise an admin could be tempted to say `iptables -F security` which would probably break rules created for example by sandboxing software (which may follow same-origin policy to restrict one particular program to certain domain and port only). Note that in this case `iptables -F security` is a security risk (sandbox breaking)?
>>
>> New table could be possibly be called:
>>
>> - temp
>> - temporary
>> - auto
>> - automatic
>> - volatile
>> - daemon
>> - system
>> - sys
>>
>> In iptables docs it should be said that this table should not be manipulated manually.
>
> Is it possible that the solution to your sandboxing problem is seccomp
> filter?
>
> http://outflux.net/teach-seccomp/
>
> You'd filter out any syscall that can make outbound connections and then
> only pass already opened sockets to the sandboxed threads?
>
> seccomp filter was actually created for sandboxing, so that user
> applications could voluntarily shed the ability to call certain syscalls
> before handling untrusted data.
seccomp would not work for me, because I need network enabled sandboxes. Moreover we should be able to filter out certain subnets such as 127.0.0.0/255.0.0.0 (and others), This cleanly can't be done with seccomp.
--
Victor Porton - http://portonvictor.org
WARNING: multiple messages have this Message-ID (diff)
From: Victor Porton <porton@narod.ru>
To: Joshua Brindle <brindle@quarksecurity.com>
Cc: "selinux@tycho.nsa.gov" <selinux@tycho.nsa.gov>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Create new NetFilter table
Date: Fri, 10 Jan 2014 21:52:40 +0200 [thread overview]
Message-ID: <25561389383560@web15m.yandex.ru> (raw)
In-Reply-To: <52D04C59.20406@quarksecurity.com>
10.01.2014, 21:39, "Joshua Brindle" <brindle@quarksecurity.com>:
> Victor Porton wrote:
>
>> I propose to create a new NetFilter table dedicated to rules created programmatically (not by explicit admin's iptables command).
>>
>> Otherwise an admin could be tempted to say `iptables -F security` which would probably break rules created for example by sandboxing software (which may follow same-origin policy to restrict one particular program to certain domain and port only). Note that in this case `iptables -F security` is a security risk (sandbox breaking)?
>>
>> New table could be possibly be called:
>>
>> - temp
>> - temporary
>> - auto
>> - automatic
>> - volatile
>> - daemon
>> - system
>> - sys
>>
>> In iptables docs it should be said that this table should not be manipulated manually.
>
> Is it possible that the solution to your sandboxing problem is seccomp
> filter?
>
> http://outflux.net/teach-seccomp/
>
> You'd filter out any syscall that can make outbound connections and then
> only pass already opened sockets to the sandboxed threads?
>
> seccomp filter was actually created for sandboxing, so that user
> applications could voluntarily shed the ability to call certain syscalls
> before handling untrusted data.
seccomp would not work for me, because I need network enabled sandboxes. Moreover we should be able to filter out certain subnets such as 127.0.0.0/255.0.0.0 (and others), This cleanly can't be done with seccomp.
--
Victor Porton - http://portonvictor.org
next prev parent reply other threads:[~2014-01-10 19:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-10 19:25 Create new NetFilter table Victor Porton
2014-01-10 19:39 ` Joshua Brindle
2014-01-10 19:39 ` Joshua Brindle
2014-01-10 19:52 ` Victor Porton [this message]
2014-01-10 19:52 ` Victor Porton
2014-01-10 19:58 ` David Lang
2014-01-12 19:52 ` Luis Ressel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=25561389383560@web15m.yandex.ru \
--to=porton@narod.ru \
--cc=brindle@quarksecurity.com \
--cc=linux-kernel@vger.kernel.org \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.