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.
