lost connection to test machine

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit: 08caa2c8aed2 Compute storage size for a string correctly.
git tree: netbsd
console output: https://syzkaller.appspot.com/x/log.txt?x=11f63834c00000
dashboard link: https://syzkaller.appspot.com/bug?extid=dfbdb488f19ba3e44093

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+dfbdb4...@syzkaller.appspotmail.com



---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.

[Dmitry Vyukov]

On Wed, Feb 27, 2019 at 5:22 AM syzbot
<syzbot+dfbdb4...@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 08caa2c8aed2 Compute storage size for a string correctly.
> git tree: netbsd
> console output: https://syzkaller.appspot.com/x/log.txt?x=11f63834c00000
> dashboard link: https://syzkaller.appspot.com/bug?extid=dfbdb488f19ba3e44093

Since the test process runs under root and is not restricted in any
way, it may be a false positive (e.g. bringing down main network
interface). For linux we have a complex system of sandboxing which in
particular includes moving the test process to a separate network
namespace.
We need something similar for netbsd as well (don't mess with if0,
don't kill init, don't consume all memory, etc).
Would also be good to file an issue for this so it's not lost.

[Kamil Rytarowski]

On 27.02.2019 07:40, 'Dmitry Vyukov' via syzkaller-netbsd-bugs wrote:
> On Wed, Feb 27, 2019 at 5:22 AM syzbot
> <syzbot+dfbdb4...@syzkaller.appspotmail.com> wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: 08caa2c8aed2 Compute storage size for a string correctly.
>> git tree: netbsd
>> console output: https://syzkaller.appspot.com/x/log.txt?x=11f63834c00000
>> dashboard link: https://syzkaller.appspot.com/bug?extid=dfbdb488f19ba3e44093
>
> Since the test process runs under root and is not restricted in any
> way, it may be a false positive (e.g. bringing down main network
> interface). For linux we have a complex system of sandboxing which in
> particular includes moving the test process to a separate network
> namespace.
> We need something similar for netbsd as well (don't mess with if0,
> don't kill init, don't consume all memory, etc).
> Would also be good to file an issue for this so it's not lost.
>

Right now there is no support for sandboxing/namespacing.

There are plans to write or port one to the NetBSD kernel, but I'm
afraid that nothing in short term plans.

Wasn't the process running as "nobody"?

[Dmitry Vyukov]

On Wed, Feb 27, 2019 at 7:59 AM Kamil Rytarowski <n...@gmx.com> wrote:
>
> On 27.02.2019 07:40, 'Dmitry Vyukov' via syzkaller-netbsd-bugs wrote:
> > On Wed, Feb 27, 2019 at 5:22 AM syzbot
> > <syzbot+dfbdb4...@syzkaller.appspotmail.com> wrote:
> >>
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit: 08caa2c8aed2 Compute storage size for a string correctly.
> >> git tree: netbsd
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=11f63834c00000
> >> dashboard link: https://syzkaller.appspot.com/bug?extid=dfbdb488f19ba3e44093
> >
> > Since the test process runs under root and is not restricted in any
> > way, it may be a false positive (e.g. bringing down main network
> > interface). For linux we have a complex system of sandboxing which in
> > particular includes moving the test process to a separate network
> > namespace.
> > We need something similar for netbsd as well (don't mess with if0,
> > don't kill init, don't consume all memory, etc).
> > Would also be good to file an issue for this so it's not lost.
> >
>
> Right now there is no support for sandboxing/namespacing.
>
> There are plans to write or port one to the NetBSD kernel, but I'm
> afraid that nothing in short term plans.

Various sandboxing measures can come under other names too. E.g.
setrlimit is also some restrictions. Maybe there are some other
existing knobs that allow to restrict even root processes.

> Wasn't the process running as "nobody"?

I used sandbox=none by inertia (on linux it's now pretty robust).
Should we switch to sandbox=setuid? We will lose lots of useful
coverage too...
Is there something like gradual drop of privileges? E.g. we could drop
some privs that we know cause problems but keep the rest, in
particular access to /dev/ nodes.

[Kamil Rytarowski]

The closest feature seems to be "security.curtain", but it's dedicated
for users.

Information filtering
NetBSD provides administrators the ability to restrict information
passed from the kernel to userland so that users can only view
information they ``own''.

The hooks that manage this restriction are located in various parts
of the system and affect programs such as ps(1), fstat(1), and
netstat(1). Information filtering is enabled as follows:

# sysctl -w security.curtain=1

http://netbsd.gw.com/cgi-bin/man-cgi?security++NetBSD-current

Also chroot(8) is a security feature on NetBSD, compared to other OSs.
On NetBSD it's not escapable.

>> Wasn't the process running as "nobody"?
>
> I used sandbox=none by inertia (on linux it's now pretty robust).
> Should we switch to sandbox=setuid? We will lose lots of useful
> coverage too...
> Is there something like gradual drop of privileges? E.g. we could drop
> some privs that we know cause problems but keep the rest, in
> particular access to /dev/ nodes.
>

We don't support other drop of privileges other than changing UID and GID.

The most complete solution out of sources was Lua-based
secmodel_sandbox, but probably it's not good enough for these purposes.
https://www.bsdcan.org/2017/schedule/track/Security/835.en.html

I was intending to look at this security namespacing.. but it requires
thorough upfront research in order to model and implement it properly.

For now I recommend to ignore these reports. At some point of time we
will add the missing features.

[Kamil Rytarowski]

Thinking about it a bit more probably a good move nowadays is to adapt
the Linux model of cgroups and namespaces, but keeping NetBSD
implementation specifics.

Unfortunately I cannot promise any ETA, but hopefully we will get
feature-parity here sooner than later.

[Maxime Villard]

#syz dup: netbsd test error: lost connection to test machine