[gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2832 bytes --]

Hi, everyone.

Almost 9 months ago I've committed three new FEATURES for portage:
cgroup, ipc-sandbox and network-sandbox. Today I'd like to propose
enabling at least the latter two by default.


Firstly, I'd like to shortly remind you what they do:

1. cgroup -- puts all processes spawned by ebuild to cgroup, and kills
all of them once phase exits (prevents leaving orphans),

2. ipc-sandbox -- puts all processes spawned by ebuild to a separate
IPC namespace, preventing them from interfacing other system services
via IPC (message queues, semaphores, shared memory),

3. network-sandbox -- puts all processes spawned by ebuild to
a separate network namespace with a private loopback interface,
preventing them from interfacing other system services, local network
and the Internet.


Secondly, the benefits of using the latter two include:

1. improved tree quality through more complete testing

In the past, usually users with no or shoddy Internet access were
the first to notice ebuilds breaking with no Internet access. With
network-sandbox, the ebuilds fail consistently for everyone including
developers. They can notice the issues first hand and fix them before
committing the ebuild to the tree.

2. protection of user privacy (and security)

Currently, programs spawned by ebuilds can submit any data
to the Internet, often unnoticed. While committing ebuild performing
malicious activity is unlikely, such uses as test suites sending
pre-defined data and possibly some system-specific data to remote
services happen. This affects user's privacy and we should prevent
ebuilds from doing that without user's approval.

3. preventing unsolicited (and possibly costly) Internet access

Bear that Gentoo can be run on a machine with byte-paid or otherwise
shoddy Internet access (possibly with local distfile host or alike).
Ebuilds using network unwisely can reduce throughput of other local
services or even cause higher Internet bill.

4. improving security through preventing unsolicited access

The build process (and especially tests) can spawn daemons and bind
them to network interfaces. Without network sandbox, other processes
(or systems if 0.0.0.0/:: is used) can access the spawned services
and possibly perform malicious operations. With network-sandbox, even
local users can't access the spawned daemons (due to private loopback
interface).

5. preventing data loss through thoughtless access to local services

I have seen test suites that used production database servers running
on the host. You can imagine how much damage such a test suite could
cause by mistake. network-sandbox prevents the ebuild from accessing
local services, requiring it to run a safe, separate instance.


What do you think?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Davide Pesavento]

On Sun, May 11, 2014 at 11:42 PM, Michał Górny <mgorny@gentoo.org> wrote:
> Hi, everyone.
>
> Almost 9 months ago I've committed three new FEATURES for portage:
> cgroup, ipc-sandbox and network-sandbox. Today I'd like to propose
> enabling at least the latter two by default.
>

+1

I've been using all three of them since their introduction, without
any problems.

Thanks,
Davide

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Justin (jlec)]

[-- Attachment #1: Type: text/plain, Size: 608 bytes --]

On 12/05/14 02:18, Davide Pesavento wrote:
> On Sun, May 11, 2014 at 11:42 PM, Michał Górny <mgorny@gentoo.org> wrote:
>> Hi, everyone.
>>
>> Almost 9 months ago I've committed three new FEATURES for portage:
>> cgroup, ipc-sandbox and network-sandbox. Today I'd like to propose
>> enabling at least the latter two by default.
>>
> 
> +1
> 
> I've been using all three of them since their introduction, without
> any problems.
> 
> Thanks,
> Davide
> 

Same here. No Problems ever. Only if packages try to access the net,
which we don't want anyway, you will have problems.

Jusitn


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1031 bytes --]

[gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

On Sun, 11 May 2014 23:42:38 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Hi, everyone.
> 
> Almost 9 months ago I've committed three new FEATURES for portage:
> cgroup, ipc-sandbox and network-sandbox. Today I'd like to propose
> enabling at least the latter two by default.
> 
> 
> Firstly, I'd like to shortly remind you what they do:
> 
> 1. cgroup -- puts all processes spawned by ebuild to cgroup, and kills
> all of them once phase exits (prevents leaving orphans),
> 
> 2. ipc-sandbox -- puts all processes spawned by ebuild to a separate
> IPC namespace, preventing them from interfacing other system services
> via IPC (message queues, semaphores, shared memory),
> 
> 3. network-sandbox -- puts all processes spawned by ebuild to
> a separate network namespace with a private loopback interface,
> preventing them from interfacing other system services, local network
> and the Internet.

[snip]

All three of these require kernel support.  It might be a good idea to add
the needed options to that Gentoo Linux menu we have in gentoo-sources and
enable them by default.  I think it would be non-obvious to a new user that
they would have to enable network and ipc namespaces for portage to work
properly out of the box (and if they disable the latter they get a bunch of
cryptic "Unable to unshare: EINVAL" messages every time they build something
which isn't very helpful).

Do we know of any packages broken by these features?  Maybe we can add them to
the dev profiles for a while before we dump it on everyone.

Otherwise +1.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

On Mon, 12 May 2014 00:47:17 -0600
Ryan Hill <rhill@gentoo.org> wrote:

> > 1. cgroup -- puts all processes spawned by ebuild to cgroup, and
> > kills all of them once phase exits (prevents leaving orphans),
> > 
> > 2. ipc-sandbox -- puts all processes spawned by ebuild to a separate
> > IPC namespace, preventing them from interfacing other system
> > services via IPC (message queues, semaphores, shared memory),
> > 
> > 3. network-sandbox -- puts all processes spawned by ebuild to
> > a separate network namespace with a private loopback interface,
> > preventing them from interfacing other system services, local
> > network and the Internet.
> 
> All three of these require kernel support.  It might be a good idea
> to add the needed options to that Gentoo Linux menu we have in
> gentoo-sources and enable them by default. 

Right, this skipped my mind when I enabled them yesterday; this should
be documented, as well as have Portage check for missing support and
test it and bail out with a proper error message if it doesn't already.

Which options are these in particular? I'll cook a patch with them.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

- -1 from me until Portage is capable of detecting if the user's
operating system supports the FEATUREs, and informing them of this.

I also agree with Ryan that the relevant Linux options should be added
to the Gentoo Linux menu.
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlNwrVcACgkQRtClrXBQc7VW3AEAhl41o6THGN7MmZBw+8fr2rIh
KhR3PEwaVmxVzTxoMt4BAK7wTlp22XrQd4mndJQLFVvitAHFNftideozWVkHqSkp
=Pfv7
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 656 bytes --]

Am Montag, 12. Mai 2014, 13:15:35 schrieb Alexander Berntsen:
> -1 from me until Portage is capable of detecting if the user's
> operating system supports the FEATUREs, and informing them of this.
> 
> I also agree with Ryan that the relevant Linux options should be added
> to the Gentoo Linux menu.

Same opinion here, please
* have portage detect the OS support
("You have enabled FEATURES=x, but this is unsupported by your operating 
system. Disabling.")
* add to Gentoo Linux kernel config menu

Afterwards, +1 +1 +1 :)


-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Mike Gilbert]

On Mon, May 12, 2014 at 8:59 AM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
> Am Montag, 12. Mai 2014, 13:15:35 schrieb Alexander Berntsen:
>> -1 from me until Portage is capable of detecting if the user's
>> operating system supports the FEATUREs, and informing them of this.
>>
>> I also agree with Ryan that the relevant Linux options should be added
>> to the Gentoo Linux menu.
>
> Same opinion here, please
> * have portage detect the OS support
> ("You have enabled FEATURES=x, but this is unsupported by your operating
> system. Disabling.")

Portage currently prints a warning based on errno when the unshare(2)
call fails for ipc-sandbox or network-sandbox. There is probably no
need for fancier detection, but the message could probably be
improved.

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

On Mon, 12 May 2014 13:15:35 +0200
Alexander Berntsen <bernalex@gentoo.org> wrote:
> - -1 from me until Portage is capable of detecting if the user's
> operating system supports the FEATUREs, and informing them of this.

A flag being present or not in FEATURES does not mean anything, and if
you're assuming that it does then you have a bug.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/05/14 17:23, Ciaran McCreesh wrote:
> A flag being present or not in FEATURES does not mean anything, and
> if you're assuming that it does then you have a bug.
Please try to stay on topic, and don't obfuscate your posts
needlessly. Note that I will not be responding to comments like these
from you in the future. I am familiar with your modus operandi by now,
and am far too busy for it.

If you have an actual question or opinion, please make it, and I shall
respond to it if that makes sense.
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlNw7PEACgkQRtClrXBQc7WXjQD/Qat4O5OnEH48jrNyHXpbsUTr
M+UujFHqHLc9KBz3dNoA/RWh5zbh7j8TUeeMxqvlnRZ4/ggki1rza/KVr8nyiT+B
=a62v
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

On Mon, 12 May 2014 17:46:57 +0200
Alexander Berntsen <bernalex@gentoo.org> wrote:
> On 12/05/14 17:23, Ciaran McCreesh wrote:
> > A flag being present or not in FEATURES does not mean anything, and
> > if you're assuming that it does then you have a bug.
> Please try to stay on topic, and don't obfuscate your posts
> needlessly.

This is on-topic, and it tells you exactly what you need to know to
understand why your objection is irrelevant. But if you would like it
made simpler, but less precise: if you are looking at FEATURES for
anything that is not purely Portage internals, you are doing something
wrong.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/11/2014 05:42 PM, Michał Górny wrote:
> Hi, everyone.
> 
> Almost 9 months ago I've committed three new FEATURES for portage:
> cgroup, ipc-sandbox and network-sandbox. Today I'd like to propose
> enabling at least the latter two by default.
> 
> 
> Firstly, I'd like to shortly remind you what they do:
> 
> 1. cgroup -- puts all processes spawned by ebuild to cgroup, and kills
> all of them once phase exits (prevents leaving orphans),
> 
> 2. ipc-sandbox -- puts all processes spawned by ebuild to a separate
> IPC namespace, preventing them from interfacing other system services
> via IPC (message queues, semaphores, shared memory),
> 
> 3. network-sandbox -- puts all processes spawned by ebuild to
> a separate network namespace with a private loopback interface,
> preventing them from interfacing other system services, local network
> and the Internet.
> 
> 
> Secondly, the benefits of using the latter two include:
> 
> 1. improved tree quality through more complete testing
> 
> In the past, usually users with no or shoddy Internet access were
> the first to notice ebuilds breaking with no Internet access. With
> network-sandbox, the ebuilds fail consistently for everyone including
> developers. They can notice the issues first hand and fix them before
> committing the ebuild to the tree.
> 
> 2. protection of user privacy (and security)
> 
> Currently, programs spawned by ebuilds can submit any data
> to the Internet, often unnoticed. While committing ebuild performing
> malicious activity is unlikely, such uses as test suites sending
> pre-defined data and possibly some system-specific data to remote
> services happen. This affects user's privacy and we should prevent
> ebuilds from doing that without user's approval.
> 
> 3. preventing unsolicited (and possibly costly) Internet access
> 
> Bear that Gentoo can be run on a machine with byte-paid or otherwise
> shoddy Internet access (possibly with local distfile host or alike).
> Ebuilds using network unwisely can reduce throughput of other local
> services or even cause higher Internet bill.
> 
> 4. improving security through preventing unsolicited access
> 
> The build process (and especially tests) can spawn daemons and bind
> them to network interfaces. Without network sandbox, other processes
> (or systems if 0.0.0.0/:: is used) can access the spawned services
> and possibly perform malicious operations. With network-sandbox, even
> local users can't access the spawned daemons (due to private loopback
> interface).
> 
> 5. preventing data loss through thoughtless access to local services
> 
> I have seen test suites that used production database servers running
> on the host. You can imagine how much damage such a test suite could
> cause by mistake. network-sandbox prevents the ebuild from accessing
> local services, requiring it to run a safe, separate instance.
> 
> 
> What do you think?
> 
I love these new features, with one minor question:

What about talking to local network resources?  In my metasploit ebuild
it has tests available which talk to a local database and are perfectly
safe, however, if postgresql is started on the system the tests don't
work, the ebuild needs to start it's own postgresql to run the tests.
This seems a bit needless in my package, but likely saves others from
poorly written tests.  Do we want to allow access to system network
services or block them? Right now they are blocked, and that's going to
make the src_test function on my ebuild expand into near insanity to fix.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTcPGvAAoJEKXdFCfdEflKTRsQALVP4yDmT+KIbd5ZnEj0TlUf
6eiG2pVJ1XHun3cuil4Sm5AqbuehvhzCLzM8uLEZuTus8YIZqfO4XhiXjY70WyMM
N1SdUMFucmokOvNG2RmTVt30VETAn2fOQakbpYu7KyR2N9lDtAi/UXfJJTGRe+m3
iilVZ8rRyQG903VRwJZoQsYPjv7qYwxC7I345u3jDpwwObnbvs9An5lE5A4gVSa/
oLHI636lkdO7e2egitewGEo96Xaa65CCVTt9w5BeT2Ovv3IwgxjD6UgO6hbYIHvg
CsdnCUTd1o3BTasZgAwaJJv8FcJWdrpJsEk8Kowb42Mpy6kaz7ymaxbOye3i07jf
MIdh+nbRUS3VRuUf14+8sda1/rCpgnOKIbGfNpfAuKFf/FNfTbLQET7cIv5oNAJE
Kis0nfLCSdZTxV9qlLC/7cxC8MNSjYu1x/ynRQYmK1qUTGfiWUqMwdk3HBveVAI8
bfYTtoXbbuyGHU2hOxRPgYl/ynVoWRw65jYZR5gLekXlVJtbU3H76NpbKqkYXWtF
l+u8ddJCGD3ghVUm8Sknk8E8uSGOxgHaRaIfj8HpVSKrn/BZkB8dnmTa15SvQYUf
yBvuJTAMlSDkLXCvqJZJVK61iDc6eFPXXcsrOkrYNOpz3425AI4iuXHvtfpDJnGP
UgnWgSfIJ9iN0jHz7n0e
=uAgr
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Rich Freeman]

On Mon, May 12, 2014 at 12:07 PM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> What about talking to local network resources?  In my metasploit ebuild
> it has tests available which talk to a local database and are perfectly
> safe, however, if postgresql is started on the system the tests don't
> work, the ebuild needs to start it's own postgresql to run the tests.
> This seems a bit needless in my package, but likely saves others from
> poorly written tests.  Do we want to allow access to system network
> services or block them? Right now they are blocked, and that's going to
> make the src_test function on my ebuild expand into near insanity to fix.

So, in theory with a separate network namespace I would think that the
ebuild could start postgresql which could listen on any port
regardless of the fact that it is running already, because the port
would not be used within its own namespace.  Anything started within
the namespace that tried to connect to postgresql would end up talking
to the version contained within the namespace.  That could be useful
in a lot of testing scenarios.

However, I don't know if portage actually makes the network namespace
that it creates useful - I don't know if it contains any interfaces,
or if they are initialized/etc.

Rich

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Mike Gilbert]

On Mon, May 12, 2014 at 11:59 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Mon, 12 May 2014 17:46:57 +0200
> Alexander Berntsen <bernalex@gentoo.org> wrote:
>> On 12/05/14 17:23, Ciaran McCreesh wrote:
>> > A flag being present or not in FEATURES does not mean anything, and
>> > if you're assuming that it does then you have a bug.
>> Please try to stay on topic, and don't obfuscate your posts
>> needlessly.
>
> This is on-topic, and it tells you exactly what you need to know to
> understand why your objection is irrelevant. But if you would like it
> made simpler, but less precise: if you are looking at FEATURES for
> anything that is not purely Portage internals, you are doing something
> wrong.
>

The idea would be to check for the necessary kernel features from
portage backend code, not from ebuild code.

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

On Mon, 12 May 2014 12:44:38 -0400
Mike Gilbert <floppym@gentoo.org> wrote:
> On Mon, May 12, 2014 at 11:59 AM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > On Mon, 12 May 2014 17:46:57 +0200
> > Alexander Berntsen <bernalex@gentoo.org> wrote:
> >> On 12/05/14 17:23, Ciaran McCreesh wrote:
> >> > A flag being present or not in FEATURES does not mean anything,
> >> > and if you're assuming that it does then you have a bug.
> >> Please try to stay on topic, and don't obfuscate your posts
> >> needlessly.
> >
> > This is on-topic, and it tells you exactly what you need to know to
> > understand why your objection is irrelevant. But if you would like
> > it made simpler, but less precise: if you are looking at FEATURES
> > for anything that is not purely Portage internals, you are doing
> > something wrong.
> 
> The idea would be to check for the necessary kernel features from
> portage backend code, not from ebuild code.

Why, though? FEATURES doesn't give meaningful information to anything
other than Portage internals, so it doesn't matter.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Mike Gilbert]

On Mon, May 12, 2014 at 12:46 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Mon, 12 May 2014 12:44:38 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
>> On Mon, May 12, 2014 at 11:59 AM, Ciaran McCreesh
>> <ciaran.mccreesh@googlemail.com> wrote:
>> > On Mon, 12 May 2014 17:46:57 +0200
>> > Alexander Berntsen <bernalex@gentoo.org> wrote:
>> >> On 12/05/14 17:23, Ciaran McCreesh wrote:
>> >> > A flag being present or not in FEATURES does not mean anything,
>> >> > and if you're assuming that it does then you have a bug.
>> >> Please try to stay on topic, and don't obfuscate your posts
>> >> needlessly.
>> >
>> > This is on-topic, and it tells you exactly what you need to know to
>> > understand why your objection is irrelevant. But if you would like
>> > it made simpler, but less precise: if you are looking at FEATURES
>> > for anything that is not purely Portage internals, you are doing
>> > something wrong.
>>
>> The idea would be to check for the necessary kernel features from
>> portage backend code, not from ebuild code.
>
> Why, though? FEATURES doesn't give meaningful information to anything
> other than Portage internals, so it doesn't matter.
>

I'm not sure what you mean, but maybe we are just thinking about it differently.

When FEATURES="network-sandbox", the kernel must have CONFIG_NET_NS
enabled or the unshare(2) call will fail.

We should probably emit an error message advising the user to enable
the kernel option or disable the network-sandbox feature. This should
happen when we call unshare() and that fails with errno == EINVAL.

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Peter Stuge]

Mike Gilbert wrote:
> On Mon, May 12, 2014 at 12:46 PM, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > Why, though?
> 
> We should probably emit an error message advising the user to enable
> the kernel option or disable the network-sandbox feature. This should
> happen when we call unshare() and that fails with errno == EINVAL.

Why? Because that would be a sensible error message.


//Peter

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 391 bytes --]

Dnia 2014-05-12, o godz. 12:40:42
Rich Freeman <rich0@gentoo.org> napisał(a):

> However, I don't know if portage actually makes the network namespace
> that it creates useful - I don't know if it contains any interfaces,
> or if they are initialized/etc.

It sets up a private loopback (alike 'ifconfig lo up') that gets
the standard addresses.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

Dnia 2014-05-12, o godz. 12:07:11
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> napisał(a):

> What about talking to local network resources?  In my metasploit ebuild
> it has tests available which talk to a local database and are perfectly
> safe, however, if postgresql is started on the system the tests don't
> work, the ebuild needs to start it's own postgresql to run the tests.

How can you assume that the tests are perfectly safe? What do the tests
do exactly?

> This seems a bit needless in my package, but likely saves others from
> poorly written tests.  Do we want to allow access to system network
> services or block them? Right now they are blocked, and that's going to
> make the src_test function on my ebuild expand into near insanity to fix.

I'd rather not get into allowing exceptions for the rule without
knowing a good use case first. I can expand on that once the previous
question is answered.

I wouldn't call spawning a daemon that close to insanity. For those who
haven't seen such a thing yet -- dev-python/pymongo is an example where
I fixed a similar issue (writing into production database). Though it's
bit hacky since I needed a way to bind to a random free port -- with
network namespaces it'd be easier as Rich noted, since the ebuild would
have all ports free.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/12/2014 01:08 PM, Michał Górny wrote:
> Dnia 2014-05-12, o godz. 12:07:11
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> napisał(a):
> 
>> What about talking to local network resources?  In my metasploit ebuild
>> it has tests available which talk to a local database and are perfectly
>> safe, however, if postgresql is started on the system the tests don't
>> work, the ebuild needs to start it's own postgresql to run the tests.
> 
> How can you assume that the tests are perfectly safe? What do the tests
> do exactly?
> 

As stated just below, the tests are not poorly written.  All testing is
done in a test DB which is different from the production DB.

>> This seems a bit needless in my package, but likely saves others from
>> poorly written tests.  Do we want to allow access to system network
>> services or block them? Right now they are blocked, and that's going to
>> make the src_test function on my ebuild expand into near insanity to fix.
> 
> I'd rather not get into allowing exceptions for the rule without
> knowing a good use case first. I can expand on that once the previous
> question is answered.
> 
I wouldn't necessarily ask for this either, I'm just bringing to the
attention of the ML as this could be an issue for more than metasploit
and pymongodb.

> I wouldn't call spawning a daemon that close to insanity. For those who
> haven't seen such a thing yet -- dev-python/pymongo is an example where
> I fixed a similar issue (writing into production database). Though it's
> bit hacky since I needed a way to bind to a random free port -- with
> network namespaces it'd be easier as Rich noted, since the ebuild would
> have all ports free.
> 
That would be nice, can we do the network namespaces so that I at least
don't have to bind to a random port? That alone would be a major
improvement in usability.

Personally, I would love to be able to talk to localhost outside the
ebuild, but if everyone agrees that is too dangerous then I don't feel I
am qualified to disagree.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTcQNMAAoJEKXdFCfdEflKuNEP/34dIuiPCFLqLBUnCPJDQ3JW
RVrhfOoqLyyixS18rYqTNeTDBDBrnICtsZ7T47ycs9fKbN81cgSUOrMQw/qai8/v
jDBPUNb9YTs2BJ22GtNw0OBPbGc81GEBLc36P5etS5ymDPwbThSsSTo90cOiZweS
IQgHkN0ZUDxmgG/q53GSU1IONZzNU3nSt+yrd90h40Vbo2PuAC4O+fz0m3jEGV5C
WX+h5W+BCLStPerOV/VNySqQ3uo5poi3wXc3o4ojgpH1ejXo0dJ4fn6KHZxema52
JH3K3VSn2Mr60wo/43kDRmA4TtYSNbxMAH2aykAJ3WklZf3a82O0Z+++Sad84zTJ
khpJwMHJkWAGTRibxpLIQ4lSjuCwAD/WCTHRw2i8PQPWtDJNGETaGFiBwtNZRexe
2kXZbpr3TqdwfY9WgDU4pB4QpRk7UYKSVgktSIU+yY4zGH6R2LaoUs/uQDntP/1F
RYtdxV4glZ8qeOq9hmT3hnzVt/Pvj/sm+oPVJRRurz+X5FJIBGUkEFzqIXisE12E
3xUxsMQfjfOh4Io5y45iQjoYw30GdNU2t47IhTMHy1Cg9ZW5Lodx5qYiXy6JOww9
rLXVYa7u8f9emrQZChDd3+OeODU09O/YaakNhHv6gxpcVAOj9G9BMKMh0LHxSY6P
X0lKgUDxyzYSDNBhaiCn
=Vi4y
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2060 bytes --]

Dnia 2014-05-12, o godz. 13:22:20
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 05/12/2014 01:08 PM, Michał Górny wrote:
> > Dnia 2014-05-12, o godz. 12:07:11
> > "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> napisał(a):
> > 
> >> What about talking to local network resources?  In my metasploit ebuild
> >> it has tests available which talk to a local database and are perfectly
> >> safe, however, if postgresql is started on the system the tests don't
> >> work, the ebuild needs to start it's own postgresql to run the tests.
> > 
> > How can you assume that the tests are perfectly safe? What do the tests
> > do exactly?
> > 
> 
> As stated just below, the tests are not poorly written.  All testing is
> done in a test DB which is different from the production DB.

I don't know postgresql well enough but does the test db reside
in temporary build directory? That is, can you guarantee that:

1) it will never ever collide with user's database,

2) it will be properly cleaned up even if the test suite terminates
unexpectedly?

> > I wouldn't call spawning a daemon that close to insanity. For those who
> > haven't seen such a thing yet -- dev-python/pymongo is an example where
> > I fixed a similar issue (writing into production database). Though it's
> > bit hacky since I needed a way to bind to a random free port -- with
> > network namespaces it'd be easier as Rich noted, since the ebuild would
> > have all ports free.
> > 
> That would be nice, can we do the network namespaces so that I at least
> don't have to bind to a random port? That alone would be a major
> improvement in usability.

FEATURES=network-sandbox == network namespaces.

I'd say a reasonable assumption would be to Gentoo-reserve a port range
for ebuild use, and use a port in that range. When network-sandbox
becomes the default, it will be perfectly safe. Before that, it will be
reasonably safe :).

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Rich Freeman]

On Mon, May 12, 2014 at 1:22 PM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> That would be nice, can we do the network namespaces so that I at least
> don't have to bind to a random port? That alone would be a major
> improvement in usability.

From my very limited understanding of network namespaces, when you
create one it doesn't contain any interfaces.  You can then create
virtual interfaces inside, and potentially bridge them to other
interfaces outside.  If you just don't bridge it, then you would get
what amounts to a loopback interface inside the namespace.  If you do
bridge it, then that interface still gets its own IP.

Nothing would be listening on a new virtual interface, so you could
bind to any port you want to (though I think you'd still need to be
root to bind to a low port/etc).

>
> Personally, I would love to be able to talk to localhost outside the
> ebuild, but if everyone agrees that is too dangerous then I don't feel I
> am qualified to disagree.

I guess the question is, "why?"  I suppose you could provide a way for
ebuilds to disable the use of namespaces, but I'm not sure if that is
worth building, or even is desirable.  (And yes, I realize this would
be PM-specific if we did it.)

Rich

[gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]

On Mon, 12 May 2014 11:39:10 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> On Mon, 12 May 2014 00:47:17 -0600
> Ryan Hill <rhill@gentoo.org> wrote:
> 
> > > 1. cgroup -- puts all processes spawned by ebuild to cgroup, and
> > > kills all of them once phase exits (prevents leaving orphans),
> > > 
> > > 2. ipc-sandbox -- puts all processes spawned by ebuild to a separate
> > > IPC namespace, preventing them from interfacing other system
> > > services via IPC (message queues, semaphores, shared memory),
> > > 
> > > 3. network-sandbox -- puts all processes spawned by ebuild to
> > > a separate network namespace with a private loopback interface,
> > > preventing them from interfacing other system services, local
> > > network and the Internet.
> > 
> > All three of these require kernel support.  It might be a good idea
> > to add the needed options to that Gentoo Linux menu we have in
> > gentoo-sources and enable them by default. 
> 
> Right, this skipped my mind when I enabled them yesterday; this should
> be documented, as well as have Portage check for missing support and
> test it and bail out with a proper error message if it doesn't already.
> 
> Which options are these in particular? I'll cook a patch with them.

I believe they are CONFIG_IPC_NS, CONFIG_NET_NS, and CONFIG_CGROUPS.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[Alon Bar-Lev]

Hi,

I do not know if this came up... glibc must be bumped first[1].

Alon

[1] https://bugs.gentoo.org/show_bug.cgi?id=504032

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3251 bytes --]

Hello,

On Sun, 11 May 2014 23:42:38 +0200 Michał Górny wrote:
> Hi, everyone.
> 
> Almost 9 months ago I've committed three new FEATURES for portage:
> cgroup, ipc-sandbox and network-sandbox. Today I'd like to propose
> enabling at least the latter two by default.
> 
> 
> Firstly, I'd like to shortly remind you what they do:
> 
> 1. cgroup -- puts all processes spawned by ebuild to cgroup, and kills
> all of them once phase exits (prevents leaving orphans),
> 
> 2. ipc-sandbox -- puts all processes spawned by ebuild to a separate
> IPC namespace, preventing them from interfacing other system services
> via IPC (message queues, semaphores, shared memory),
> 
> 3. network-sandbox -- puts all processes spawned by ebuild to
> a separate network namespace with a private loopback interface,
> preventing them from interfacing other system services, local network
> and the Internet.
> 
> 
> Secondly, the benefits of using the latter two include:
> 
> 1. improved tree quality through more complete testing
> 
> In the past, usually users with no or shoddy Internet access were
> the first to notice ebuilds breaking with no Internet access. With
> network-sandbox, the ebuilds fail consistently for everyone including
> developers. They can notice the issues first hand and fix them before
> committing the ebuild to the tree.
> 
> 2. protection of user privacy (and security)
> 
> Currently, programs spawned by ebuilds can submit any data
> to the Internet, often unnoticed. While committing ebuild performing
> malicious activity is unlikely, such uses as test suites sending
> pre-defined data and possibly some system-specific data to remote
> services happen. This affects user's privacy and we should prevent
> ebuilds from doing that without user's approval.
> 
> 3. preventing unsolicited (and possibly costly) Internet access
> 
> Bear that Gentoo can be run on a machine with byte-paid or otherwise
> shoddy Internet access (possibly with local distfile host or alike).
> Ebuilds using network unwisely can reduce throughput of other local
> services or even cause higher Internet bill.
> 
> 4. improving security through preventing unsolicited access
> 
> The build process (and especially tests) can spawn daemons and bind
> them to network interfaces. Without network sandbox, other processes
> (or systems if 0.0.0.0/:: is used) can access the spawned services
> and possibly perform malicious operations. With network-sandbox, even
> local users can't access the spawned daemons (due to private loopback
> interface).
> 
> 5. preventing data loss through thoughtless access to local services
> 
> I have seen test suites that used production database servers running
> on the host. You can imagine how much damage such a test suite could
> cause by mistake. network-sandbox prevents the ebuild from accessing
> local services, requiring it to run a safe, separate instance.
> 
> 
> What do you think?

Please do not enable them prior rigorous testing.

I tried network-sandbox — this is a disaster. It brokes distcc
completely since distcc client can't connect to remote servers (and
even to a local one if any).

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Luis Ressel]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

On Mon, 12 May 2014 19:39:09 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> I don't know postgresql well enough but does the test db reside
> in temporary build directory? That is, can you guarantee that:
> 
> 1) it will never ever collide with user's database,
> 
> 2) it will be properly cleaned up even if the test suite terminates
> unexpectedly?

The closest thing you could do would be to create a separate tablespace
residing in the build directory. I wouldn't consider this a good idea
however, as you'd need postgres superuser permissions, it would have
some unintented side effects (like breaking on SELinux machines), you'd
have to patch the test suites and it still wouldn't ensure an automatic
cleanup -- on unexpected test suite terminations the dir in which the
tablespace resides would vanish, but postgres would still expect one
there, which might even create further problems (especially on
re-emerge). I wouldn't recommend using this approach even when
accessing the host postgres.

On top of that, many postgres installations with reasonably secure
configuration wouldn't grant portage access anyway.

As it isn't hard at all to run a separate postgres instance (upstream
is explicitly supporting it), I'd strongly recommend doing so even with
network-sandbox being disabled.


--
Regards,
Luis Ressel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Rich Freeman]

On Tue, May 13, 2014 at 1:28 AM, Andrew Savchenko <bircoph@gmail.com> wrote:
>
> Please do not enable them prior rigorous testing.
>
> I tried network-sandbox — this is a disaster. It brokes distcc
> completely since distcc client can't connect to remote servers (and
> even to a local one if any).

Certainly agree on the need for testing, but it sounds like several
have been using it without issue.  Lack of distcc compatibility could
be addressed by either filtering the setting if it is enabled,
actually bridging the distcc traffic only, or by just publishing news
to warn distcc users to disable it.

I don't think that distcc compatibility should drive the defaults -
distcc is not enabled by default and anybody using it should be able
to handle reading a news item and complying.

Rich

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

Dnia 2014-05-13, o godz. 09:28:49
Andrew Savchenko <bircoph@gmail.com> napisał(a):

> I tried network-sandbox — this is a disaster. It brokes distcc
> completely since distcc client can't connect to remote servers (and
> even to a local one if any).

Calling something a disaster just because it breaks one thing is
unpleasant at least.

This is a corner case with no good solution at the moment. Though it is
entirely doable to make FEATURES=distcc and FEATURES=network-sandbox
conflict, or the former disable the latter implicitly. As Rich noted,
we do not enable distcc by default so there's no reason why we can't
enable conflicting options by default.

As far as distcc is concerned, I don't currently have time to work on
it. This would probably require some kind of bridging -- or allowing
distcc processes to escape the sandbox.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

[gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

On Tue, 13 May 2014 19:11:18 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Dnia 2014-05-13, o godz. 09:28:49
> Andrew Savchenko <bircoph@gmail.com> napisał(a):
> 
> > I tried network-sandbox — this is a disaster. It brokes distcc
> > completely since distcc client can't connect to remote servers (and
> > even to a local one if any).
> 
> Calling something a disaster just because it breaks one thing is
> unpleasant at least.
> 
> This is a corner case with no good solution at the moment. Though it is
> entirely doable to make FEATURES=distcc and FEATURES=network-sandbox
> conflict, or the former disable the latter implicitly. As Rich noted,
> we do not enable distcc by default so there's no reason why we can't
> enable conflicting options by default.

Probably best to make FEATURES=distcc disable network-sandbox then.  People
enabling it are explicitly saying they want to access the network.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[Thomas D.]

Hi,

Ryan Hill wrote:
> Probably best to make FEATURES=distcc disable network-sandbox
> then. People enabling it are explicitly saying they want to access
> the network.

Do you really think it is a good behavior to automatically disable
something you can call a "security feature"? At least there should be a
warning, not?

Think about situations where the user just know "network-sandbox is
important, because it will protect my system from unwanted
modifications" (the thing where the test suite for example will write to
the local, productive, database server...) and therefore explicitly
enable that feature by hand.

But the user is *also* using distcc to speed up the compilation/update
time in his/her network.

The user maybe knows that distcc is using network, but he/she might be
surprised that it won't work together with the network-sandbox feature.
If we now silently disable network-sandbox because the user also set
distcc he/she might be even more surprised when he/she noticed that
his/her local productive database system was accessed by emerge though
he/she enabled network-sandbox feature to prevent this (but which was
automatically disabled without a warning).

Because it is security relevant and the impact could be a real problem I
won't even show just a warning the user could miss. If network-sandbox
*and* distcc are both set, emerge should fail complaining about the
problem.
This is something the user should be aware of and must be solved by hand.

So if we decide to enable the network-sandbox feature by default (which
we should do), users also using distcc must take action.

And if in future we will solve the problem so that both features can be
used together, we should send out a news item for people using the
distcc feature telling them "Now you can re-enable (the default)
network-sandbox feature"...


-Thomas

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]

On Thu, May 15, 2014 at 4:12 AM, Thomas D. <whissi@whissi.de> wrote:

> Hi,
>
> Ryan Hill wrote:
> > Probably best to make FEATURES=distcc disable network-sandbox
> > then. People enabling it are explicitly saying they want to access
> > the network.
>
> Do you really think it is a good behavior to automatically disable
> something you can call a "security feature"? At least there should be a
> warning, not?
>

I think you are reading much further into Ryan's statement than he intended.


>
> Think about situations where the user just know "network-sandbox is
> important, because it will protect my system from unwanted
> modifications" (the thing where the test suite for example will write to
> the local, productive, database server...) and therefore explicitly
> enable that feature by hand.
>
> But the user is *also* using distcc to speed up the compilation/update
> time in his/her network.
>
> The user maybe knows that distcc is using network, but he/she might be
> surprised that it won't work together with the network-sandbox feature.
> If we now silently disable network-sandbox because the user also set
> distcc he/she might be even more surprised when he/she noticed that
> his/her local productive database system was accessed by emerge though
> he/she enabled network-sandbox feature to prevent this (but which was
> automatically disabled without a warning).
>
> Because it is security relevant and the impact could be a real problem I
> won't even show just a warning the user could miss. If network-sandbox
> *and* distcc are both set, emerge should fail complaining about the
> problem.
> This is something the user should be aware of and must be solved by hand.
>
> So if we decide to enable the network-sandbox feature by default (which
> we should do), users also using distcc must take action.
>
> And if in future we will solve the problem so that both features can be
> used together, we should send out a news item for people using the
> distcc feature telling them "Now you can re-enable (the default)
> network-sandbox feature"...
>
>
> -Thomas
>
>
>

[-- Attachment #2: Type: text/html, Size: 2806 bytes --]

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

On Thu, 15 May 2014 13:12:30 +0200
"Thomas D." <whissi@whissi.de> wrote:
> Ryan Hill wrote:
> > Probably best to make FEATURES=distcc disable network-sandbox
> > then. People enabling it are explicitly saying they want to access
> > the network.
> 
> Do you really think it is a good behavior to automatically disable
> something you can call a "security feature"? At least there should be
> a warning, not?

Sandboxing isn't about security. It's about catching mistakes.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[Luis Ressel]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

On Thu, 15 May 2014 16:48:24 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> Sandboxing isn't about security. It's about catching mistakes.

Ciaran has a point here. Thomas, you assumed that network-sandbox is
the only thing stopping an ebuild from accessing local services or the
internet. However, even with network-sandbox being enabled such
behaviour would still constitue a major bug which would be fixed by the
devs.

So yes, network-sandbox (and same goes for ipc-sandbox) is mainly a
debugging aid for developers which will help them spot such problems
more easily.


--
Regards,
Luis Ressel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[hasufell]

Ciaran McCreesh:
> 
> Sandboxing isn't about security.
> 

Sure it is.

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

On Thu, 15 May 2014 17:15:32 +0000
hasufell <hasufell@gentoo.org> wrote:
> Ciaran McCreesh:
> > Sandboxing isn't about security.
> > 
> 
> Sure it is.

Then where do the bug reports for all the "security violations"
possible with sandbox go?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[Thomas D.]

Hi,

Ciaran McCreesh wrote:
> Sandboxing isn't about security. It's about catching mistakes.

From Wikipedia
(http://en.wikipedia.org/wiki/Sandbox_%28computer_security%29):
> In computer security, a sandbox is a security mechanism for 
> separating running programs. It is often used to execute untested 
> code, or untrusted programs from unverified third-parties,
> suppliers, untrusted users and untrusted websites

network-sandbox is using unshare() syscalls to separate... not?

But when I wrote my mail I was referring to Michal's statements in
<http://thread.gmane.org/gmane.linux.gentoo.devel/91131>. He is
explicitly listing "improving security"...


-Thomas

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On Thu, 15 May 2014 20:35:41 +0200
"Thomas D." <whissi@whissi.de> wrote:
> Ciaran McCreesh wrote:
> > Sandboxing isn't about security. It's about catching mistakes.
> 
> From Wikipedia
> (http://en.wikipedia.org/wiki/Sandbox_%28computer_security%29):
> > In computer security, a sandbox is a security mechanism for 
> > separating running programs. It is often used to execute untested 
> > code, or untrusted programs from unverified third-parties,
> > suppliers, untrusted users and untrusted websites
> 
> network-sandbox is using unshare() syscalls to separate... not?

Not for security reasons: sandbox (the way it is used on Gentoo) does
nothing against a malicious ebuild or a malicious package. Instead, it
simply catches certain common mistakes.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[Mike Gilbert]

On Thu, May 15, 2014 at 1:17 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Thu, 15 May 2014 17:15:32 +0000
> hasufell <hasufell@gentoo.org> wrote:
>> Ciaran McCreesh:
>> > Sandboxing isn't about security.
>> >
>>
>> Sure it is.
>
> Then where do the bug reports for all the "security violations"
> possible with sandbox go?
>

There is a big difference between the sandbox utility
(sys-apps/sandbox) and the network-sandbox/ipc-sandbox features. The
former uses an LD_PRELOAD hack to intercept libc functions, and does
not provide any security benefit. The latter options create separate
namespaces in the kernel, which is probably a lot more secure.

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

On Thu, 15 May 2014 14:44:58 -0400
Mike Gilbert <floppym@gentoo.org> wrote:
> On Thu, May 15, 2014 at 1:17 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > On Thu, 15 May 2014 17:15:32 +0000
> > hasufell <hasufell@gentoo.org> wrote:
> >> Ciaran McCreesh:
> >> > Sandboxing isn't about security.
> >> >
> >>
> >> Sure it is.
> >
> > Then where do the bug reports for all the "security violations"
> > possible with sandbox go?
> >
> 
> There is a big difference between the sandbox utility
> (sys-apps/sandbox) and the network-sandbox/ipc-sandbox features. The
> former uses an LD_PRELOAD hack to intercept libc functions, and does
> not provide any security benefit. The latter options create separate
> namespaces in the kernel, which is probably a lot more secure.

"Secure" against what? Malicious ebuilds? Malicious packages?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[Mike Gilbert]

On Thu, May 15, 2014 at 2:48 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Thu, 15 May 2014 14:44:58 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
>> On Thu, May 15, 2014 at 1:17 PM, Ciaran McCreesh
>> <ciaran.mccreesh@googlemail.com> wrote:
>> > On Thu, 15 May 2014 17:15:32 +0000
>> > hasufell <hasufell@gentoo.org> wrote:
>> >> Ciaran McCreesh:
>> >> > Sandboxing isn't about security.
>> >> >
>> >>
>> >> Sure it is.
>> >
>> > Then where do the bug reports for all the "security violations"
>> > possible with sandbox go?
>> >
>>
>> There is a big difference between the sandbox utility
>> (sys-apps/sandbox) and the network-sandbox/ipc-sandbox features. The
>> former uses an LD_PRELOAD hack to intercept libc functions, and does
>> not provide any security benefit. The latter options create separate
>> namespaces in the kernel, which is probably a lot more secure.
>
> "Secure" against what? Malicious ebuilds? Malicious packages?
>

Secure against unauthrorized network access during phases where
network-sandbox is effective. I am aware that this is a very small
benefit given that the ebuild or build system can do lots of things
locally without network access, or install some file that accesses the
network later.

ipc-sandbox probably has some similar security benefit, but I don't
understand it as well.

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

On Thu, May 15, 2014 at 12:01 PM, Mike Gilbert <floppym@gentoo.org> wrote:

> On Thu, May 15, 2014 at 2:48 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > On Thu, 15 May 2014 14:44:58 -0400
> > Mike Gilbert <floppym@gentoo.org> wrote:
> >> On Thu, May 15, 2014 at 1:17 PM, Ciaran McCreesh
> >> <ciaran.mccreesh@googlemail.com> wrote:
> >> > On Thu, 15 May 2014 17:15:32 +0000
> >> > hasufell <hasufell@gentoo.org> wrote:
> >> >> Ciaran McCreesh:
> >> >> > Sandboxing isn't about security.
> >> >> >
> >> >>
> >> >> Sure it is.
> >> >
> >> > Then where do the bug reports for all the "security violations"
> >> > possible with sandbox go?
> >> >
> >>
> >> There is a big difference between the sandbox utility
> >> (sys-apps/sandbox) and the network-sandbox/ipc-sandbox features. The
> >> former uses an LD_PRELOAD hack to intercept libc functions, and does
> >> not provide any security benefit. The latter options create separate
> >> namespaces in the kernel, which is probably a lot more secure.
> >
> > "Secure" against what? Malicious ebuilds? Malicious packages?
> >
>
> Secure against unauthrorized network access during phases where
> network-sandbox is effective. I am aware that this is a very small
> benefit given that the ebuild or build system can do lots of things
> locally without network access, or install some file that accesses the
> network later.
>
> ipc-sandbox probably has some similar security benefit, but I don't
> understand it as well.
>
>
I think we are way off topic here folks ;)

-A

[-- Attachment #2: Type: text/html, Size: 2505 bytes --]