[Bug 195984] New: [jail] security bug in jail utility: setgid missing/fails during creation
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Mon Dec 15 01:24:51 UTC 2014
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195984
Bug ID: 195984
Summary: [jail] security bug in jail utility: setgid
missing/fails during creation
Product: Base System
Version: 10.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: nospam at mgedv.net
CC: jamie at FreeBSD.org
Created attachment 150594
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=150594&action=edit
jail setgid bug analysis and reproduce steps
initial analysis [2014-12-06]:
as the "real" application faces the same problems, i created a test
jail on a clean box just to check the behaviour using "/usr/bin/id".
problem description (hopefully i nailed it):
if a jailed process needs any .so for startup, the path to those *.so
needs to be world r-x, although the GID of the jail execute user
is allowed to r/x the dirs, where the *.so files are to be found.
there could be (ordering) errors with SET(e)GID in jail_* functions,
because it works as expected when prefixing with "chroot -g test /".
the EGID is dropped to the jail user's gid, but the GID is still 0!
we end up with a jailed proc (UID=999, GID=0), which of course is
not allowed to access the dirs for the *.so's to be loaded by exec.
update from james gritton [2014-12-13]:
There does indeed seem to be a missing setgid() in jail (compared to
jexec, which gets it right).
more details to be found in freebsd-questions list (attached, too). subject:
freebsd 10.1-RELEASE: jail security errors - GID 0 not dropped completely
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list