All of lore.kernel.org
 help / color / mirror / Atom feed
From: Victor Porton <porton@narod.ru>
To: Stephen Smalley <sds@tycho.nsa.gov>,
	"selinux@tycho.nsa.gov" <selinux@tycho.nsa.gov>
Subject: Re: Restrict to a fixed Internet domain in a sandbox
Date: Thu, 09 Jan 2014 22:14:45 +0200	[thread overview]
Message-ID: <97521389298485@web1m.yandex.ru> (raw)
In-Reply-To: <52CF0129.5070904@tycho.nsa.gov>

09.01.2014, 22:06, "Stephen Smalley" <sds@tycho.nsa.gov>:
> On 01/09/2014 02:58 PM, Victor Porton wrote:
>
>>  09.01.2014, 21:35, "Stephen Smalley" <sds@tycho.nsa.gov>:
>>>  On 01/09/2014 02:31 PM, Victor Porton wrote:
>>>>   09.01.2014, 21:25, "Stephen Smalley" <sds@tycho.nsa.gov>:
>>>>>   On 01/09/2014 11:37 AM, Victor Porton wrote:
>>>>>>    I remind that sandbox is implemented in Fedora using SELinux.
>>>>>>
>>>>>>    It would be useful to restrict sandboxed application to connect only to one, programmatically specified Internet domain (just like Java and JavaScript security).
>>>>>>
>>>>>>    It seems it is impossible with current SELinux.
>>>>>>
>>>>>>    Could you add necessary features? Please!
>>>>>   I'm not aware of any missing kernel features required to support your
>>>>>   functionality.  I think all you are missing is two userspace components:
>>>>   AFAIK, there are no support for this in Linux kernel.
>>>>
>>>>   It is why I advise to add a new syscall (see my previous message).
>>>>>    a library that provides whatever interface you design, and a daemon
>>>>>   that receives the specification in whatever form you design and turns it
>>>>>   into a set of SELinux and iptables SECMARK/CONNSECMARK rules to label
>>>>>   the packets so that SELinux can mediate them accordingly, and loads that
>>>>>   into the kernel for enforcement.
>>>>   I've already explained some reasons why iptables solution would be wrong. One of the reasons is that this would confuse a system administrator by appearance of new unexpected rules, the automatically added rules would also disappear when iptables script is reloaded, what could make errors for regular users. To use iptables this way seems a really bad idea.
>>>  For SECMARK/CONNSECMARK, there is a separate dedicated security table to
>>>  avoid such conflicts.
>>  Also I think, implementing it my way would be much more efficient than your way.
>
> You are certainly free to implement it any way you like; it is open
> source software after all.  But implementing a new kernel mechanism +
> system call when it can already be achieved using existing mechanism is
> generally discouraged.  You haven't even tried...

I've looked into iptables. It has 32 bit marks.

The first idea is to set the mark to the label of the sandbox process.

But it is wrong, other packages may use the same 32 bit numbers.

The same applies to SECMARK which are also 32 bit wide.

So, to implement it, we would need to introduce a new standard, which marks are used by which packages. A very bad idea.

It's better to implement it in kernel. I prophecy that sandboxes will become more and more important, and this feature will be very useful.

-- 
Victor Porton - http://portonvictor.org

  reply	other threads:[~2014-01-09 20:14 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-09 16:37 Restrict to a fixed Internet domain in a sandbox Victor Porton
2014-01-09 16:59 ` Victor Porton
2014-01-09 17:03   ` William Roberts
2014-01-09 17:19     ` Victor Porton
2014-01-09 17:34       ` William Roberts
2014-01-09 18:28         ` Victor Porton
2014-01-09 18:59   ` Victor Porton
2014-01-09 19:18     ` Victor Porton
2014-01-09 19:22       ` Victor Porton
2014-01-09 19:25 ` Stephen Smalley
2014-01-09 19:31   ` Victor Porton
2014-01-09 19:34     ` Stephen Smalley
2014-01-09 19:44       ` Victor Porton
2014-01-09 19:58       ` Victor Porton
2014-01-09 20:06         ` Stephen Smalley
2014-01-09 20:14           ` Victor Porton [this message]
2014-01-09 20:21             ` Stephen Smalley
2014-01-10 18:41       ` Victor Porton
2014-01-10 18:47         ` Stephen Smalley
2014-01-10 18:53           ` Victor Porton

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=97521389298485@web1m.yandex.ru \
    --to=porton@narod.ru \
    --cc=sds@tycho.nsa.gov \
    --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.