From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 5D8601396D0 for ; Sat, 9 Sep 2017 09:39:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 626021FC05D; Sat, 9 Sep 2017 09:39:43 +0000 (UTC) Received: from powerman.name (powerman.name [109.86.197.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C61631FC052 for ; Sat, 9 Sep 2017 09:39:42 +0000 (UTC) Received: (qmail 1304 invoked by uid 1000); 9 Sep 2017 09:39:40 -0000 Date: Sat, 9 Sep 2017 12:39:40 +0300 From: Alex Efros To: gentoo-hardened@lists.gentoo.org Subject: Re: [gentoo-hardened] GRKERNSEC_PROC_USERGROUP and docker exec Message-ID: <20170909093940.GD2677@home.power> Mail-Followup-To: gentoo-hardened@lists.gentoo.org References: <20170908192045.GC2677@home.power> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-hardened@lists.gentoo.org Reply-to: gentoo-hardened@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: http://powerman.name/ User-Agent: Mutt/1.8.3 (2017-05-23) X-Archives-Salt: cda6e307-28bf-4063-bc85-70154995778a X-Archives-Hash: 0bc5ea3fcfd96efbc553e3692ae4fc03 Hi! On Sat, Sep 09, 2017 at 11:23:46AM +0200, "Tóth Attila" wrote: > I don't use docker myself, but if we are speaking about > CONFIG_GRKERNSEC_PROC_USER and CONFIG_GRKERNSEC_PROC_USERGROUP, it would > be important to know what GID is specified in CONFIG_GRKERNSEC_PROC_GID? It's 3 (group "sys"). :) # zgrep GRKERNSEC_PROC_GID /proc/config.gz CONFIG_GRKERNSEC_PROC_GID=3 > So if you can figure out the important > process's GID, you can officially circumwent the restrictions. Too bad if > the incriminated process runs as root... If you can influence with what > GID the important process starts, you have a key for a solution. It's a docker's "root", it has fewer capabilities than real root. But, anyway, docker's "root" has mostly same groups (including "sys") as host root: $ docker run -it --rm alpine id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video) $ sudo id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),26(tape),27(video) Looks like being in group 3(sys) within container just doesn't have same effect as on host. Maybe it's because of some capabilities dropped from container's root account by docker? -- WBR, Alex.