Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 463318 - [powerman overlay] sys-apps/sandbox: incompatible with OS Inferno
Summary: [powerman overlay] sys-apps/sandbox: incompatible with OS Inferno
Status: RESOLVED OBSOLETE
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Sandbox (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Sandbox Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-26 07:39 UTC by Alex Efros
Modified: 2017-09-27 16:25 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
strace-emu-segfault.log (sandbox-emu-segfault.log,32.55 KB, text/plain)
2013-03-26 21:12 UTC, Alex Efros
Details
strace-emu-ok.log (sandbox-emu-ok.log,86.26 KB, text/plain)
2013-03-26 21:12 UTC, Alex Efros
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Efros 2013-03-26 07:39:17 UTC
This issue is somewhat exotic, so I suppose this report will be ignored.

There is such a thing as OS Inferno. To make things simpler you can think about it just like about another one virtual machine (like Java) - usual Linux application /usr/inferno/Linux/386/bin/emu which should be used to execute Inferno applications compiled in bytecode format. On hardened system `emu` should be paxmarked just like any other virtual machine.

Some applications try to run `emu` inside ebuild - for example, perl module dev-perl/Inferno-RegMgr do this while `make test`.

Problem is, everything works fine about a year ago, but today I notice it doesn't work anymore - when emu executed while emerging some package I got this in kernel log and emerge fails:

kern.alert: grsec: Segmentation fault occurred at            (nil) in /usr/inferno/Linux/386/bin/emu-g[emu-g:23122] uid/euid:250/250 gid/egid:250/250, parent /usr/bin/perl5.12.4[perl5.12.4:23117] uid/euid:250/250 gid/egid:250/250

I found it's possible to work around this issue using FEATURES="-usersandbox".
I've tried to run `make test` inside `sudo -u portage` - it works fine, so switching UID isn't a problem.

If anyone wanna try to debug this issue - add overlay "powerman" - it contain ebuilds both for OS Inferno (dev-inferno/inferno) and for dev-perl/Inferno-RegMgr.



Portage 2.1.11.55 (hardened/linux/amd64, gcc-4.6.3, glibc-2.15-r3, 3.8.4-hardened x86_64)
=================================================================
System uname: Linux-3.8.4-hardened-x86_64-Intel-R-_Core-TM-_i7-2600K_CPU_@_3.40GHz-with-gentoo-2.1
KiB Mem:     8160176 total,   2949108 free
KiB Swap:    4200960 total,   4197988 free
Timestamp of tree: Tue, 26 Mar 2013 01:45:01 +0000
ld GNU ld (GNU Binutils) 2.22
app-shells/bash:          4.2_p37
dev-java/java-config:     2.1.12-r1
dev-lang/python:          2.7.3-r3, 3.2.3-r2
dev-util/cmake:           2.8.9
dev-util/pkgconfig:       0.28
sys-apps/baselayout:      2.1-r1
sys-apps/openrc:          0.11.8
sys-apps/sandbox:         2.5
sys-devel/autoconf:       2.13, 2.69
sys-devel/automake:       1.11.6
sys-devel/binutils:       2.22-r1
sys-devel/gcc:            4.6.3
sys-devel/gcc-config:     1.7.3
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 3.7 (virtual/os-headers)
sys-libs/glibc:           2.15-r3
Repositories: gentoo powerman perl-experimental-snapshots gamerlay hardened-dev local
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /opt/upsmon-usb/EXT/DownOS /opt/upsmon-usb/EXT/JSystem /service /usr/inferno/keydb /usr/inferno/lib /usr/inferno/services /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa /var/log /var/qmail/alias /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=native -O2 -pipe"
DISTDIR="/usr/portage-distfiles"
EMERGE_DEFAULT_OPTS="--with-bdeps=y"
FCFLAGS="-march=native -O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync webrsync-gpg xattr"
FFLAGS="-march=native -O2 -pipe"
GENTOO_MIRRORS="http://gentoo.kiev.ua/ftp/ http://mirror.yandex.ru/gentoo-distfiles/ http://gentoo.iteam.net.ua/"
LANG="ru_RU.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j8"
PKGDIR="/usr/portage-packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_EXTRA_OPTS="--exclude ChangeLog --delete-excluded"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/var/lib/layman/powerman /var/lib/layman/perl-experimental-snapshots /var/lib/layman/gamerlay /var/lib/layman/hardened-development /usr/local/portage"
SYNC="rsync://rsync.ua.gentoo.org/gentoo-portage"
USE="X a52 aac acl alac alsa amd64 avx bash-completion berkdb bzip2 caps cdda cddb cli cracklib crypt cxx dbus dri dts dvb dvd flac fontconfig gdbm gif gnutls gpg gpm hardened iconv icu id3tag idn ipv6 jpeg jpeg2k justify libnotify mac mad matroska mbox mmx mng modules mp3 mpeg mudflap multilib musepack mysql ncurses network-cron nls nptl nsplugin ogg opengl openmp pam pax_kernel pcre perl png qt3support readline session spell sse sse2 sse3 sse4_1 sse4_2 ssl ssse3 svg tcpd theora tiff truetype unicode urandom vdpau vim-syntax vorbis wavpack x264 xattr xosd xv xvid xvmc zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="log_config vhost_alias autoindex alias rewrite dir deflate filter mime negotiation auth_basic authn_file authz_host authz_user authz_groupfile cgi actions headers env setenvif" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en ru" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" QEMU_SOFTMMU_TARGETS="x86_64 i386" QEMU_USER_TARGETS="x86_64 i386" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="nvidia nv nouveau" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, USE_PYTHON
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2013-03-26 18:53:33 UTC
The problem with this bug report is that all the ebuilds that fail are in the overlay you maintain. If and when you find an actual sandbox bug, please do report that to the sandbox developers, but I don't see how sys-apps/sandbox is even involved here so the bug's Summary could use some (more) work.
Comment 2 Alex Efros 2013-03-26 19:43:05 UTC
(In reply to comment #1)
> The problem with this bug report is that all the ebuilds that fail are in
> the overlay you maintain.

Hmm. I don't understand. Bug isn't in ebuilds, so what's the difference in which overlay they are located? Copy them into /usr/local/portage, if you like to avoid my overlay.

> If and when you find an actual sandbox bug, please
> do report that to the sandbox developers, but I don't see how
> sys-apps/sandbox is even involved here

It's involved because FEATURES=-usersandbox fix this issue.

Actually you can avoid installing dev-perl/Inferno-RegMgr by simple adding command to run `emu` in, say, /etc/portage/bashrc - so it will be executed inside sandbox when emerging any ebuild. And you can avoid dev-inferno/inferno ebuild by installing OS Inferno manually from sources. This way you completely avoid using my overlay and still will be able to see this issue.

I can understand if sandbox developers refuse to fix this bug because they don't wanna support OS Inferno at all (and they are not curious enough to just wonder what's can be wrong between sandbox and inferno), but question where are located these ebuilds are completely irrelevant to this issue.
Comment 3 Jeroen Roovers (RETIRED) gentoo-dev 2013-03-26 20:06:25 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > The problem with this bug report is that all the ebuilds that fail are in
> > the overlay you maintain.
> 
> Hmm. I don't understand. Bug isn't in ebuilds, so what's the difference in
> which overlay they are located? Copy them into /usr/local/portage, if you
> like to avoid my overlay.

You haven't described an actual sandbox bug yet.
Comment 4 Alex Efros 2013-03-26 21:06:21 UTC
(In reply to comment #3)
> You haven't described an actual sandbox bug yet.

That's partially because I can't find any documentation describing what sandbox actually does and how to configure it - so I've no ideas how it limit sandboxed app and thus I can't guess what may be wrong.

Here is minimal example (only thing you need is OS Inferno installed):

# LD_PRELOAD=libsandbox.so SANDBOX_ACTIVE=armedandready SANDBOX_ON=1 SANDBOX_READ=/ emu echo ok
Segmentation fault

# LD_PRELOAD=libsandbox.so emu echo ok
ok

I've tried to check sandbox logs (usual and debug), use SANDBOX_VERBOSE=1, SANDBOX_INTRACTV=1 and __SANDBOX_TESTING=yes - no signs of anything wrong in logs.
I'm going to attach output of `strace -ff emu echo ok` for both cases, maybe sandbox developers will got an idea what goes wrong.
Comment 5 Alex Efros 2013-03-26 21:12:12 UTC
Created attachment 343360 [details]
strace-emu-segfault.log
Comment 6 Alex Efros 2013-03-26 21:12:58 UTC
Created attachment 343362 [details]
strace-emu-ok.log
Comment 7 SpanKY gentoo-dev 2013-03-27 01:43:17 UTC
(In reply to comment #4)

the README in the sandbox source code explains things pretty clearly
Comment 8 Alex Efros 2013-03-27 03:30:00 UTC
(In reply to comment #7)
> the README in the sandbox source code explains things pretty clearly

Actually I've looked for docs in sources before whine here about lack of docs.

I've read README, but it doesn't explain things I wanna know to be able to guess what may be wrong with inferno:
1) list of all environment variables and their values which let me control sandbox
2) list of all operations intercepted/limited by sandbox, which may help me guess which one may conflict with inferno (btw, after looking at strace log this probably doesn't helps anymore)
3) known bugs/incompatibilities
Comment 9 SpanKY gentoo-dev 2013-03-27 04:21:18 UTC
(In reply to comment #8)

you said you couldn't find docs on what sandbox does.  the README file explains that clearly.

there is no real documentation on what vars do what.  the only real stable interface is the vars that the PM relies on.  otherwise, you can read libsbutil/sbutil.h and the ENV_XXX defines.

there is no real list of what functions the sandbox intercepts.  "anything that can write/modify the filesystem" is candidate for overloading, and that exact symbol list is determined at configure time by analyzing the C library that sandbox is being compiled against.  you can run `readelf -sW /usr/lib64/libsandbox.so` and look at all the exported symbols to see which ones it is actively overriding.

setting SANDBOX_VERBOSE=1 gives the best "high level" view into what is happening at runtime.

SANDBOX_DEBUG=1 really needs a sandbox compiled with debug code enabled to be useful.

__SANDBOX_TESTING won't work on installed libraries (by design).  it gets binary patched out during install.

stracing doesn't really help because sandbox operates at the C library level -- before syscalls are made.

only other documentation is in the TODO file.
Comment 10 Alex Efros 2013-03-27 04:35:30 UTC
Not sure is this helps, but here is what I have for now.
I've commented all open/creat wrappers in sandbox source, and inferno started ok:

# LD_PRELOAD=/var/tmp/portage/sys-apps/sandbox-2.5/work/build-x86/libsandbox/.libs/libsandbox.so SANDBOX_ACTIVE=armedandready SANDBOX_ON=1 SANDBOX_READ=/ SANDBOX_VERBOSE=1 SANDBOX_DEBUG=1 emu echo ok
ok

Next I tried to do something inside inferno (the ";" is inferno shell's prompt):

# LD_PRELOAD=/var/tmp/portage/sys-apps/sandbox-2.5/work/build-x86/libsandbox/.libs/libsandbox.so SANDBOX_ACTIVE=armedandready SANDBOX_ON=1 SANDBOX_READ=/ SANDBOX_VERBOSE=1 SANDBOX_DEBUG=1 emu 
; ls >/dev/null
ACCESS ALLOWED  opendir:    /usr/inferno
; mkdir 1
Segmentation fault

Outside of sandbox it works, of course:

# emu
; mkdir 1
; ls -ld 1
d-rwx------ U 4 root root 0 Mar 27 06:18 1
; rm 1
; 

I've tested few more wrappers, these are works:
  opendir, utime, remove, rmdir, chmod, execvp
and these are fail:
  mkdir, rename, open(according to strace, fail on second call)
Comment 11 Alex Efros 2013-03-27 04:50:36 UTC
wrapper-funcs/rename.c contain this line:
  #define WRAPPER_SAFE() SB_SAFE(oldpath) && SB_SAFE(newpath)
and doesn't work. If I change it this way:
  #define WRAPPER_SAFE() SB_SAFE(newpath)
it still doesn't work. But this way:
  #define WRAPPER_SAFE() SB_SAFE(oldpath)
it stop crashing emu and works! See:

# LD_PRELOAD=/var/tmp/portage/sys-apps/sandbox-2.5/work/build-x86/libsandbox/.libs/libsandbox.so SANDBOX_ACTIVE=armedandready SANDBOX_ON=1 SANDBOX_READ=/ SANDBOX_VERBOSE=1 SANDBOX_DEBUG=1 SANDBOX_WRITE=/ emu
; mv 1 2
ACCESS ALLOWED  rename:     /usr/inferno/1
; mv 2 1
ACCESS ALLOWED  rename:     /usr/inferno/2
;
Comment 12 SpanKY gentoo-dev 2013-03-27 05:35:42 UTC
(In reply to comment #10)

you might be hitting bug 404013.  there are two patches referenced in there you might want to try against sandbox-2.6-r1.
Comment 13 Alex Efros 2013-03-27 05:49:07 UTC
(In reply to comment #12)
> you might be hitting bug 404013.  there are two patches referenced in there
> you might want to try against sandbox-2.6-r1.

I've already tried 2.6-r1, no difference.

I've traced code line which result in segfault. It's in libsandbox.c, when function resolve_path() called with follow_link=1, at lines:

		if (!ret) {
			char tmp_str1[SB_PATH_MAX];
			snprintf(tmp_str1, SB_PATH_MAX, "%s", path);

It crash on snprintf() call, but I see nothing wrong with it. The path variable is correct string, I've checked this.

Moreover, if I add at very beginning of this function something like this:

	char __tmp_str1[SB_PATH_MAX];
	snprintf(__tmp_str1, SB_PATH_MAX, "%s", path);

it won't crash anymore. This added code is NO-OP, so probably something is wrong with memory layout (which is change because of added var and code).
Actually I've seen similar symptoms some time ago in few other applications, but don't remember what's was the problem and how to fix it.
Comment 14 Alex Efros 2013-03-27 05:59:44 UTC
Here is how it looks (I've added debug sb_printf()).

; mv 1 2
ENTER before_syscall(-100, 21, 0xe7a30ba0, 0x0fe95fe0 '/usr/inferno/1', 0)
ENTER resolve_path(0xe79f6004 '/', 0)
ENTER resolve_path(0xe7541004 '/', 0)
before_syscall: call check_syscall()
ENTER check_syscall(0xe7a34160, 21, 0xe7a30ba0, 0x0fe95fe0, 0)
ENTER resolve_path(0x0fe95fe0 '/usr/inferno/1', 0)
check_syscall: absolute_path='/usr/inferno/1'
ENTER resolve_path(0x0fe95fe0 '/usr/inferno/1', 1)
check_syscall: resolved_path='/usr/inferno/1'
ACCESS ALLOWED  rename:     /usr/inferno/1
before_syscall: returned from check_syscall()
ENTER before_syscall(-100, 21, 0xe7a30ba0, 0x0fe9cde0 '/usr/inferno/2', 0)
before_syscall: call check_syscall()
ENTER check_syscall(0xe7a34160, 21, 0xe7a30ba0, 0x0fe9cde0, 0)
ENTER resolve_path(0x0fe9cde0 '/usr/inferno/2', 0)
check_syscall: absolute_path='/usr/inferno/2'
ENTER resolve_path(0x0fe9cde0 '/usr/inferno/2', 1)
resolve_path: call snprintf(0xe7a1436c, 8192, 0x0fe9cde0)
Segmentation fault

Instead of segfault it should print:
resolve_path: returned from snprintf()
Comment 15 SpanKY gentoo-dev 2013-03-27 17:02:04 UTC
(In reply to comment #13)

i think you misread my comment.  i didn't say "try 2.6-r1", i said "try 2.6-r1 with the two patches from that bug".
Comment 16 Alex Efros 2013-03-27 17:54:24 UTC
(In reply to comment #15)
> i think you misread my comment.  i didn't say "try 2.6-r1", i said "try
> 2.6-r1 with the two patches from that bug".

They doesn't apply (I tried `ebuild ...-2.6-r1.ebuild prepare` and then manually `patch --dry-run -p1` inside /var/tmp/portage). First patch looks like already (partially?) applied, second fail at last section AFAIR.
Comment 17 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-09-26 10:24:35 UTC
Alex, if you're still interested in this, could you try the current version? There were some segv fixes over the years, so the problem may be gone now.
Comment 18 Alex Efros 2017-09-27 12:05:35 UTC
(In reply to Michał Górny from comment #17)
> Alex, if you're still interested in this, could you try the current version?
> There were some segv fixes over the years, so the problem may be gone now.

No. I don't have this ebuild in overlay any more because I don't install Perl modules using portage for years. I think this issue can be closed now.