Restrict to a fixed Internet domain in a sandbox

Restrict to a fixed Internet domain in a sandbox

[Victor Porton]

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!

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

Re: Restrict to a fixed Internet domain in a sandbox

[Victor Porton]

09.01.2014, 18:39, "Victor Porton" <porton@narod.ru>:
> 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!

You could add a syscall like:

int selinux_restrict_domain(const char *domain);

(We could modify this interface to restrict to a finite list of domains instead of one domain, but personally I don't need this.)

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

Re: Restrict to a fixed Internet domain in a sandbox

[William Roberts]

Could you just do this with normal iptables rules? Optionally using
labeled networking to label packets coming in.

On Thu, Jan 9, 2014 at 8:59 AM, Victor Porton <porton@narod.ru> wrote:
> 09.01.2014, 18:39, "Victor Porton" <porton@narod.ru>:
>> 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!
>
> You could add a syscall like:
>
> int selinux_restrict_domain(const char *domain);
>
> (We could modify this interface to restrict to a finite list of domains instead of one domain, but personally I don't need this.)
>
> --
> Victor Porton - http://portonvictor.org
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.



-- 
Respectfully,

William C Roberts

Re: Restrict to a fixed Internet domain in a sandbox

[Victor Porton]

09.01.2014, 19:03, "William Roberts" <bill.c.roberts@gmail.com>:
> Could you just do this with normal iptables rules? Optionally using
> labeled networking to label packets coming in.

It could be done with iptables, but:

1. My application would need root access to manipulate netfilter. It is not acceptable.

2. Even if my application has permissions enough to manipulate iptables, rules automatically created by it would interfere with customary way system administrators manually edit iptables script. It is very bad (and possibly may even impose a security treat).

I am about a quite particular application I am going to write, and I now am writing its algorithm specification. Not to turn my application into spam mail bomber or something similar, I really need to restrict to a fixed domain as a security measure. It is important. It is done in JavaScript and Java, obviously SELinux should not be behind JavaScript and Java in security.

> On Thu, Jan 9, 2014 at 8:59 AM, Victor Porton <porton@narod.ru> wrote:
>
>>  09.01.2014, 18:39, "Victor Porton" <porton@narod.ru>:
>>>  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!
>>  You could add a syscall like:
>>
>>  int selinux_restrict_domain(const char *domain);
>>
>>  (We could modify this interface to restrict to a finite list of domains instead of one domain, but personally I don't need this.)

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

Re: Restrict to a fixed Internet domain in a sandbox

[William Roberts]

You wouldn't want your application to set up the security... that
would be like asking the fox to guard the hen house. You would want to
establish all these things before your application is running.
However, you would need to administer this policy somehow, which is
going to be specific on the environment you are running.

What Java and JavaScript are doing doesn't really relate to SELinux
directly IMO. SELinux is controlling the interactions to resources of
the Linux Kernel (assuming no userspace object managers).

Im not really a desktop SELinux guy, more on Android. So I cant tell
you the specifics of how to do it, but I know it can be done.

Bill


On Thu, Jan 9, 2014 at 9:19 AM, Victor Porton <porton@narod.ru> wrote:
> 09.01.2014, 19:03, "William Roberts" <bill.c.roberts@gmail.com>:
>> Could you just do this with normal iptables rules? Optionally using
>> labeled networking to label packets coming in.
>
> It could be done with iptables, but:
>
> 1. My application would need root access to manipulate netfilter. It is not acceptable.
>
> 2. Even if my application has permissions enough to manipulate iptables, rules automatically created by it would interfere with customary way system administrators manually edit iptables script. It is very bad (and possibly may even impose a security treat).
>
> I am about a quite particular application I am going to write, and I now am writing its algorithm specification. Not to turn my application into spam mail bomber or something similar, I really need to restrict to a fixed domain as a security measure. It is important. It is done in JavaScript and Java, obviously SELinux should not be behind JavaScript and Java in security.
>
>> On Thu, Jan 9, 2014 at 8:59 AM, Victor Porton <porton@narod.ru> wrote:
>>
>>>  09.01.2014, 18:39, "Victor Porton" <porton@narod.ru>:
>>>>  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!
>>>  You could add a syscall like:
>>>
>>>  int selinux_restrict_domain(const char *domain);
>>>
>>>  (We could modify this interface to restrict to a finite list of domains instead of one domain, but personally I don't need this.)
>
> --
> Victor Porton - http://portonvictor.org



-- 
Respectfully,

William C Roberts

Re: Restrict to a fixed Internet domain in a sandbox

[Victor Porton]

09.01.2014, 19:34, "William Roberts" <bill.c.roberts@gmail.com>:
> You wouldn't want your application to set up the security... that
> would be like asking the fox to guard the hen house. You would want to
> establish all these things before your application is running.
> However, you would need to administer this policy somehow, which is
> going to be specific on the environment you are running.

The security cannot be set in advance, because before my application starts, which domains should be allowed is not known. It can be setup only from the inside of my application.

My application is not the fox to guard the hen house, because I am going my application "safe" (in the same sense as "ls" and "cp" Linux commands are safe, they don't do anything without user's approval).

But by design my application may run programs downloaded from the Web without user's interaction. This is why I need a sandbox and restrict networking to a certain domain (which domain is calculated by my application based on its input data).

> What Java and JavaScript are doing doesn't really relate to SELinux
> directly IMO. SELinux is controlling the interactions to resources of
> the Linux Kernel (assuming no userspace object managers).

Despite of the real (implemented) security behind Java is too bad, basic Java security ideas were designed by wise guys. We should follow their wisdom and implement these ideas in SELinux.

> Im not really a desktop SELinux guy, more on Android. So I cant tell
> you the specifics of how to do it, but I know it can be done.
>
> Bill
>
> On Thu, Jan 9, 2014 at 9:19 AM, Victor Porton <porton@narod.ru> wrote:
>
>>  09.01.2014, 19:03, "William Roberts" <bill.c.roberts@gmail.com>:
>>>  Could you just do this with normal iptables rules? Optionally using
>>>  labeled networking to label packets coming in.
>>  It could be done with iptables, but:
>>
>>  1. My application would need root access to manipulate netfilter. It is not acceptable.
>>
>>  2. Even if my application has permissions enough to manipulate iptables, rules automatically created by it would interfere with customary way system administrators manually edit iptables script. It is very bad (and possibly may even impose a security treat).
>>
>>  I am about a quite particular application I am going to write, and I now am writing its algorithm specification. Not to turn my application into spam mail bomber or something similar, I really need to restrict to a fixed domain as a security measure. It is important. It is done in JavaScript and Java, obviously SELinux should not be behind JavaScript and Java in security.
>>>  On Thu, Jan 9, 2014 at 8:59 AM, Victor Porton <porton@narod.ru> wrote:
>>>>   09.01.2014, 18:39, "Victor Porton" <porton@narod.ru>:
>>>>>   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!
>>>>   You could add a syscall like:
>>>>
>>>>   int selinux_restrict_domain(const char *domain);
>>>>
>>>>   (We could modify this interface to restrict to a finite list of domains instead of one domain, but personally I don't need this.)
>>  --
>>  Victor Porton - http://portonvictor.org
>
> --
> Respectfully,
>
> William C Roberts

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

Re: Restrict to a fixed Internet domain in a sandbox

[Victor Porton]

Sorry, it should restrict not only domain but also port and protocol.

So I propose this new syscall to restrict an application by "same-origin" policy:

int selinux_restrict_domain(struct sockaddr *ADDR, socklen_t LENGTH);

I am not sure that it is the best API specification. Please comment.

Note that probably all connections we need are TCP (not UDP), but we can support all protocols for completeness.

09.01.2014, 18:59, "Victor Porton" <porton@narod.ru>:
> 09.01.2014, 18:39, "Victor Porton" <porton@narod.ru>:
>
>>  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!
>
> You could add a syscall like:
>
> int selinux_restrict_domain(const char *domain);
>
> (We could modify this interface to restrict to a finite list of domains instead of one domain, but personally I don't need this.)
>
> --
> Victor Porton - http://portonvictor.org

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

Re: Restrict to a fixed Internet domain in a sandbox

[Victor Porton]

I've realized that this would not work in the case of DNS round-robin load balancing, because the IP used by a sandboxed program may differ from the IP set by my application (which calls the sandbox).

So now I propose the following alternative

struct full_host_desc_t {
  struct sockaddr *ADDR, socklen_t LENGTH;
};

int selinux_restrict_domains(struct full_host_desc_t *hosts, unsigned int num_hosts);

Maybe there can be constructed a more efficient API.

09.01.2014, 21:02, "Victor Porton" <porton@narod.ru>:
> Sorry, it should restrict not only domain but also port and protocol.
>
> So I propose this new syscall to restrict an application by "same-origin" policy:
>
> int selinux_restrict_domain(struct sockaddr *ADDR, socklen_t LENGTH);
>
> I am not sure that it is the best API specification. Please comment.
>
> Note that probably all connections we need are TCP (not UDP), but we can support all protocols for completeness.
>
> 09.01.2014, 18:59, "Victor Porton" <porton@narod.ru>:
>
>>  09.01.2014, 18:39, "Victor Porton" <porton@narod.ru>:
>>>   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!
>>  You could add a syscall like:
>>
>>  int selinux_restrict_domain(const char *domain);
>>
>>  (We could modify this interface to restrict to a finite list of domains instead of one domain, but personally I don't need this.)
>>
>>  --
>>  Victor Porton - http://portonvictor.org
>
> --
> Victor Porton - http://portonvictor.org
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

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

Re: Restrict to a fixed Internet domain in a sandbox

[Victor Porton]

09.01.2014, 21:21, "Victor Porton" <porton@narod.ru>:
> I've realized that this would not work in the case of DNS round-robin load balancing, because the IP used by a sandboxed program may differ from the IP set by my application (which calls the sandbox).
>
> So now I propose the following alternative
>
> struct full_host_desc_t {
>   struct sockaddr *ADDR, socklen_t LENGTH;
> };

// a little error:  '.' instead of ';'
struct full_host_desc_t {
  struct sockaddr *ADDR;
  socklen_t LENGTH;
};

> int selinux_restrict_domains(struct full_host_desc_t *hosts, unsigned int num_hosts);
>
> Maybe there can be constructed a more efficient API.
>
> 09.01.2014, 21:02, "Victor Porton" <porton@narod.ru>:
>
>>  Sorry, it should restrict not only domain but also port and protocol.
>>
>>  So I propose this new syscall to restrict an application by "same-origin" policy:
>>
>>  int selinux_restrict_domain(struct sockaddr *ADDR, socklen_t LENGTH);
>>
>>  I am not sure that it is the best API specification. Please comment.
>>
>>  Note that probably all connections we need are TCP (not UDP), but we can support all protocols for completeness.
>>
>>  09.01.2014, 18:59, "Victor Porton" <porton@narod.ru>:
>>>   09.01.2014, 18:39, "Victor Porton" <porton@narod.ru>:
>>>>    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!
>>>   You could add a syscall like:
>>>
>>>   int selinux_restrict_domain(const char *domain);
>>>
>>>   (We could modify this interface to restrict to a finite list of domains instead of one domain, but personally I don't need this.)
>>>
>>>   --
>>>   Victor Porton - http://portonvictor.org
>>  --
>>  Victor Porton - http://portonvictor.org
>>
>>  _______________________________________________
>>  Selinux mailing list
>>  Selinux@tycho.nsa.gov
>>  To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>>  To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>
> --
> Victor Porton - http://portonvictor.org
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

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

Re: Restrict to a fixed Internet domain in a sandbox

[Stephen Smalley]

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

Re: Restrict to a fixed Internet domain in a sandbox

[Victor Porton]

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.

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

Re: Restrict to a fixed Internet domain in a sandbox

[Stephen Smalley]

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.

Re: Restrict to a fixed Internet domain in a sandbox

[Victor Porton]

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.

You force me (user) to start some scripts under root. But I want my software to be installable by a regular user in his home directory. It is one reason why adding new syscall into the kernel (see my previous email) would be better than creating such a daemon.

Also, I continue to highly doubt that your usage of IP would not interfere with normal system administration.

It is also unclear how to implement your daemon. It should create a new kind of "mark" every time a new sandbox binary starts (for two different sandboxes not to interfere with each other). I am not quite sure that this can be implemented in iptables.

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

Re: Restrict to a fixed Internet domain in a sandbox

[Victor Porton]

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.

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

Re: Restrict to a fixed Internet domain in a sandbox

[Stephen Smalley]

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

Re: Restrict to a fixed Internet domain in a sandbox

[Victor Porton]

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

Re: Restrict to a fixed Internet domain in a sandbox

[Stephen Smalley]

On 01/09/2014 03:14 PM, Victor Porton wrote:
> 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.

You misunderstand SECMARK.  It is a handle to a security context, which
is assigned to the sk_buff and then used in SELinux packet send/recv
checks that can be used to control packet flow.

http://selinuxproject.org/page/NB_Networking
http://james-morris.livejournal.com/11010.html
http://www.linux.com/learn/tutorials/421152-using-selinux-and-iptables-together
http://paulmoore.livejournal.com/4281.html

Note that most if not all of those articles were written before a
separate security table was introduced, so these days you would use -t
security and make sure your kernel enables CONFIG_IP_NF_SECURITY=y as
well as the SECMARK/CONNSECMARK options.

But again, you are free to do as you like.

Re: Restrict to a fixed Internet domain in a sandbox

[Victor Porton]

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.

We need to make a separate ID for every sandbox process (with all its children) (there may be more than one, even run simultaneously by the same user). This ID should be in some way passed to NetFilter. Does iptables provide a way to add such an ID to the rules? (Moreover we need to somehow ensure that this ID would not interact with rules created by other software packages or by an administrator?)

Can it be safely done with iptables? Please be specific.

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

Re: Restrict to a fixed Internet domain in a sandbox

[Stephen Smalley]

On 01/10/2014 01:41 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.
> 
> We need to make a separate ID for every sandbox process (with all its children) (there may be more than one, even run simultaneously by the same user). This ID should be in some way passed to NetFilter. Does iptables provide a way to add such an ID to the rules? (Moreover we need to somehow ensure that this ID would not interact with rules created by other software packages or by an administrator?)
> 
> Can it be safely done with iptables? Please be specific.

SECMARK/CONNSECMARK is just a way to assign a SELinux security context
to packets based on various iptables selectors.  Then in SELinux policy,
you can control sending/receiving packets based on those security
contexts and the security context of the sending/receiving process.  You
can obviously generate a unique security context for each sandbox; the
sandbox program already does that.

Re: Restrict to a fixed Internet domain in a sandbox

[Victor Porton]

10.01.2014, 20:48, "Stephen Smalley" <sds@tycho.nsa.gov>:
> On 01/10/2014 01:41 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.
>>  We need to make a separate ID for every sandbox process (with all its children) (there may be more than one, even run simultaneously by the same user). This ID should be in some way passed to NetFilter. Does iptables provide a way to add such an ID to the rules? (Moreover we need to somehow ensure that this ID would not interact with rules created by other software packages or by an administrator?)
>>
>>  Can it be safely done with iptables? Please be specific.
>
> SECMARK/CONNSECMARK is just a way to assign a SELinux security context
> to packets based on various iptables selectors.  Then in SELinux policy,
> you can control sending/receiving packets based on those security
> contexts and the security context of the sending/receiving process.  You
> can obviously generate a unique security context for each sandbox; the
> sandbox program already does that.

I understand this.

I just want to make sure that my daemon would be able to remove rules created by particular sandbox (when the sandbox exists). Can it be done by `iptables -D` with a complete security content (including the category, which is different for each sandbox)? I am not sure whether -D will deal with rules specified by (among other data) security context. Or can my daemon get specific rulenum for each rule it creates (to be able to remove them when the sandbox exists)?

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