Date: Tue, 5 Apr 2016 14:02:31 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@FreeBSD.org> To: Dirk-Willem van Gulik <dirkx@webweaving.org> Cc: FreeBSD Hackers <hackers@freebsd.org> Subject: Re: reboot with reroot / 10.3 Message-ID: <20160405120231.GB47120@brick.home> In-Reply-To: <B2CCFC6F-C8E9-4523-9CAB-345638D121D0@webweaving.org> References: <B2CCFC6F-C8E9-4523-9CAB-345638D121D0@webweaving.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 0404T1350, Dirk-Willem van Gulik wrote: > Trasz, > > Thanks for the wonderful reroot present in 10.3 :) First tries work well for us for a couple of scenario’s around pivoting early from an ro-mounted bootup to mount the ‘real' encrypted root FS that has its key stored on remote hardware (previously we used Adrian Steinmann / ast his work on Pivot Root with a lot of care/order puzzles). > > I gather that it creates a /de/reroot tempfs; copies the, at that time, on-disk version of init (as learned from a trusted kern.proc.pathname); executes init with a new -r; that essentially does (just) a kill (as only init can kill init) - and then things are mounted/cleaned up from there after attempting to run at least something from ‘kern.init_path’ > > Where would one go to understand the trust-chain/security aspects of this ? I.e. what locks the kill(1, SIGEMT) to the copy of the real init(8) ? Where are the places most at risk ? There shouldn't be any security aspects - only the root can trigger it. The source destination for copying the init(8) binary is obtained from the kernel, using KERN_PROC_PATHNAME sysctl - it's the path of on-disk init(8) binary itself.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160405120231.GB47120>