From: Eric Wong <firstname.lastname@example.org> To: Jeremy Evans <email@example.com> Cc: firstname.lastname@example.org Subject: Re: Patch: Add support for chroot to Worker#user Date: Tue, 21 Feb 2017 19:53:50 +0000 Message-ID: <20170221195350.GB26617@whir> (raw) In-Reply-To: <20170221192421.GI93742@jeremyevans.local> Jeremy Evans <email@example.com> wrote: > Any chrooting would need to happen inside Worker#user, because > you can't chroot until after you have parsed the list of groups, > and you must chroot before dropping root privileges. > > chroot is an important security feature, so that if the unicorn > process is exploited, file system access is limited to the chroot > directory instead of the entire system. I'm hesitant to document this as "an important security feature". Perhaps "an extra layer of security" is more accurate, as there are ways of breaking out of a chroot. > This is not a complete patch as it does not include tests. I can > add tests if you would consider accepting this feature. I wouldn't worry about automated tests if elevated privileges are required. > - # Changes the worker process to the specified +user+ and +group+ > + # Changes the worker process to the specified +user+ and +group+, > + # and chroots to the current working directory if +chroot+ is set. > # This is only intended to be called from within the worker > # process from the +after_fork+ hook. This should be called in > # the +after_fork+ hook after any privileged functions need to be > @@ -123,7 +124,7 @@ def close # :nodoc: > # directly back to the caller (usually the +after_fork+ hook. > # These errors commonly include ArgumentError for specifying an > # invalid user/group and Errno::EPERM for insufficient privileges > - def user(user, group = nil) > + def user(user, group = nil, chroot = false) > # we do not protect the caller, checking Process.euid == 0 is > # insufficient because modern systems have fine-grained > # capabilities. Let the caller handle any and all errors. > @@ -134,6 +135,10 @@ def user(user, group = nil) > Process.initgroups(user, gid) > Process::GID.change_privilege(gid) > end > + if chroot > + Dir.chroot(Dir.pwd) > + Dir.chdir('/') > + end Perhaps this can be made more flexible by allowing chroot to any specified directory, not just pwd. Something like: chroot = Dir.pwd if chroot == true if chroot Dir.chroot(chroot) Dir.chdir('/') end Anyways I'm inclined to accept this feature.
next prev parent reply index Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-02-21 19:24 Jeremy Evans 2017-02-21 19:53 ` Eric Wong [this message] 2017-02-21 20:15 ` Jeremy Evans
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://yhbt.net/unicorn/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170221195350.GB26617@whir \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help Archives are clonable: git clone --mirror https://yhbt.net/unicorn-public git clone --mirror http://ou63pmih66umazou.onion/unicorn-public Example config snippet for mirrors Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.unicorn note: .onion URLs require Tor: https://www.torproject.org/ AGPL code for this site: git clone https://public-inbox.org/public-inbox.git