genuinetools / amicontained Goto Github PK

View Code? Open in Web Editor NEW

976.0 36.0 67.0 3.32 MB

Container introspection tool. Find out what container runtime is being used as well as features available.

License: MIT License

Makefile 24.09% Go 73.46% Dockerfile 2.45%

containers docker rkt lxc openvz libvirt linux security apparmor capabilities

amicontained's People

Contributors

Stargazers

Watchers

Forkers

markjacksonfishing kinvolk-archives superpoussin22 grantseltzer subfuzion mbrukman alexitosrv karlmutch williammartin cjcjameson ipmb westonsteimel bugwrangler alejandroortuno staaldraad tklauser brompwnie pombredanne triplekill modulexcite genslein gwenall weteamsteve backwardn tools-env sanddorn 5l1v3r1 tomazb abousselmi dshamanthreddy unodive pentagramz pancudaniel7 magnologan hien maxpeal berney ttys3 timb-machine-mirrors mrjrieke suresh31babu-sec chrisumbel awgh marquesledivan leaderdevops minkione syllogy alainlompo fuzzyun1c0rn darkoneiroi patrickdung adamhurm ofturanc chosen1 jonathanhle sokratis1988 godwhoa ppopth krouser doraa7 cxz rajkrishnamurthy sgnconnects layzhi anshulsahu1990 pankajdubeyjava daviderestivo

amicontained's Issues

multi arch binanrys are missing

multi arch binanrys are missing,
so it dont work on any arch apart form x86_64
see also #23

by mistake, please delete

Releases after v0.4.3 are missing container package

I have a project which uses this package on v0.4.3 and in trying to upgrade newer versions do not contain the /container package. You can view the godoc for v0.4.4 which does not have /container.

Is this project still supported? It looks to only support x86, but in needing to support ARM is there a replacement?

Trying to update ibm-message projects

https://github.com/adamdecaf/mq-golang/tree/arm64-support

https://github.com/adamdecaf/mq-container/tree/arm64-support

PID namespace check seems to no longer be valid

Running on an Ubuntu 22 VM with a 5.15 kernel the PID namespace check incorrectly identified that it was in a namespace.

This looks like the check for the device number being greater than 4 is outdated.

Debugging Information

user@claus:~/src/amicontained$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.1 LTS
Release:	22.04
Codename:	jammy

user@claus:~/src/amicontained$ uname -a
Linux claus 5.15.0-46-generic #49-Ubuntu SMP Thu Aug 4 18:03:25 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

user@claus:~/src/amicontained$ ./amicontained -d
Container Runtime: not-found
Has Namespaces:
	pid: true.     <--- Unexpected
	user: false
//Snipped

user@claus:~/src/amicontained$ stat /proc/1/ns
  File: /proc/1/ns
  Size: 0         	Blocks: 0          IO Block: 1024   directory
Device: 17h/23d	Inode: 28440       Links: 2
Access: (0511/dr-x--x--x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-04-05 02:33:18.504000164 +0000
Modify: 2023-04-05 02:33:18.504000164 +0000
Change: 2023-04-05 02:33:18.504000164 +0000
 Birth: -

Logrus changed to lower case, pkg now duplicated in vendor directory.

Logrus went lower case sirupsen/logrus#384

The issue is there is now 2 directories in vendor folder.

amicontained//vendor/github.com/Sirupsen/logrus
amicontained//vendor/github.com/sirupsen/logrus

Latest release only includes amd64 binaries

Even though the README lists several architectures, the release page only has the amd64 binaries :)

"Container Runtime: not-found" when running with lxc-execute

When running amicontained-linux-amd64 from a container that I am attached to (with lxc-attach), I get the following correct output:

root@xenial:# ./amicontained-linux-amd64 
Container Runtime: lxc
Host PID Namespace: true
AppArmor Profile: lxc-container-default-cgns (enforce)
User Namespace: true
User Namespace Mappings:
	Container -> 0	Host -> 100000	Range -> 1000
	Container -> 1000	Host -> 1000	Range -> 1
	Container -> 1001	Host -> 101001	Range -> 64535
Capabilities:
	BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_tty_config mknod lease audit_write audit_control setfcap syslog wake_alarm block_suspend audit_read

However, if I try to run amicontained-linux-amd64 directly from lxc-execute (i.e. using LXC as an application container), then it fails to detect the runtime:

$ lxc-execute -n xenial -- /home/florian/tmp/amicontained-linux-amd64
init.lxc.static: initutils.c: mount_fs: 36 failed to mount /proc : Device or resource busy
Container Runtime: not-found
Host PID Namespace: true
AppArmor Profile: lxc-container-default-cgns (enforce)
User Namespace: true
User Namespace Mappings:
	Container -> 0	Host -> 100000	Range -> 1000
	Container -> 1000	Host -> 1000	Range -> 1
	Container -> 1001	Host -> 101001	Range -> 64535
Capabilities:
	BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_tty_config mknod lease audit_write audit_control setfcap syslog wake_alarm block_suspend audit_read

The -EBUSY seems like a LXC userland glitch to me: if the container were really unable to mount /proc, then parsing the uid map wouldn't work — but it does.

The same is true when I have lxc-execute start a shell, and then run amicontained-linux-amd64 from there.

chroot test not working?

I'm looking for a good chroot test, because the one in Go syscall tests does not work on XFS where I've seen inode 64 and 128.

But this test does not seem to work, here I run the test on without any container/chroot. On Fedora 26, 4.11.9-300.fc26.x86_64 (with ext4 /):

chlunde@localhost ~/.../jessfraz/amicontained$ sudo ./amicontained  | tail -n 1
Chroot/PivotRoot: true
chlunde@localhost ~/.../jessfraz/amicontained$ ./amicontained  | tail -n 1
Chroot/PivotRoot: false

$ sudo stat -L /proc/1/root /
  File: /proc/1/root
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: fd00h/64768d	Inode: 2           Links: 19
Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:root_t:s0
Access: 2017-08-08 22:07:52.120771955 +0200
Modify: 2017-06-14 21:49:49.338056567 +0200
Change: 2017-06-14 21:49:49.338056567 +0200
 Birth: -
  File: /
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: fd00h/64768d	Inode: 2           Links: 19
Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:root_t:s0
Access: 2017-08-08 22:07:52.120771955 +0200
Modify: 2017-06-14 21:49:49.338056567 +0200
Change: 2017-06-14 21:49:49.338056567 +0200
 Birth: -

I'm not sure if this is possible?

Runtime detection of Kubernetes/Docker

Neat tool!

Just ran it inside a container on kubernetes 1.7.x (docker 1.12.x) an an AWS node, and this is the output:

./amicontained-linux-amd64 -d
Container Runtime: not-found
Host PID Namespace: false
AppArmor Profile: docker-default (enforce)
User Namespace: false
Capabilities:
	BOUNDING -> chown dac_override fowner fsetid kill setgid setuid setpcap net_bind_service net_raw sys_chroot mknod audit_write setfcap
Chroot/PivotRoot: true

And it's having trouble detecting the runtime correctly.

Peeking at conainer.go, I see that you're looping through the runtime names and seeing if they're in /proc/self/cgroup.

# cat /proc/self/cgroup 
11:memory:/kubepods/besteffort/pod6c85216c-82ad-11e7-9fb0-061c2985ea4a/162a25c865d3117f158a598f94b1a14436519ba18c8c1969727b9d3f7bdee25e
10:pids:/kubepods/besteffort/pod6c85216c-82ad-11e7-9fb0-061c2985ea4a/162a25c865d3117f158a598f94b1a14436519ba18c8c1969727b9d3f7bdee25e
9:cpuset:/kubepods/besteffort/pod6c85216c-82ad-11e7-9fb0-061c2985ea4a/162a25c865d3117f158a598f94b1a14436519ba18c8c1969727b9d3f7bdee25e
8:blkio:/kubepods/besteffort/pod6c85216c-82ad-11e7-9fb0-061c2985ea4a/162a25c865d3117f158a598f94b1a14436519ba18c8c1969727b9d3f7bdee25e
7:perf_event:/kubepods/besteffort/pod6c85216c-82ad-11e7-9fb0-061c2985ea4a/162a25c865d3117f158a598f94b1a14436519ba18c8c1969727b9d3f7bdee25e
6:devices:/kubepods/besteffort/pod6c85216c-82ad-11e7-9fb0-061c2985ea4a/162a25c865d3117f158a598f94b1a14436519ba18c8c1969727b9d3f7bdee25e
5:net_cls,net_prio:/kubepods/besteffort/pod6c85216c-82ad-11e7-9fb0-061c2985ea4a/162a25c865d3117f158a598f94b1a14436519ba18c8c1969727b9d3f7bdee25e
4:hugetlb:/kubepods/besteffort/pod6c85216c-82ad-11e7-9fb0-061c2985ea4a/162a25c865d3117f158a598f94b1a14436519ba18c8c1969727b9d3f7bdee25e
3:cpu,cpuacct:/kubepods/besteffort/pod6c85216c-82ad-11e7-9fb0-061c2985ea4a/162a25c865d3117f158a598f94b1a14436519ba18c8c1969727b9d3f7bdee25e
2:freezer:/kubepods/besteffort/pod6c85216c-82ad-11e7-9fb0-061c2985ea4a/162a25c865d3117f158a598f94b1a14436519ba18c8c1969727b9d3f7bdee25e
1:name=systemd:/kubepods/besteffort/pod6c85216c-82ad-11e7-9fb0-061c2985ea4a/162a25c865d3117f158a598f94b1a14436519ba18c8c1969727b9d3f7bdee25e

It seems that finding kubepods in /proc/self/cgroup probably means docker, at least for the near future. ;-)

Thanks!

ftjrkdeigbnvuhgiicbbbuejnuie

hang on msgrcv if allowed

running with docker run --privileged hangs on ubuntu 18.04 Linux 5b045500201a 4.15.0-13-generic #14~16.04.1-Ubuntu SMP Sat Mar 17 03:04:59 UTC 2018 x86_64 Linux

strace:

...
uname(NULL)                             = -1 EFAULT (Bad address)
semget(IPC_PRIVATE, 0, 000)             = -1 EINVAL (Invalid argument)
semop(0, NULL, 0)                       = -1 EINVAL (Invalid argument)
semctl(0, 0, IPC_RMID, NULL)            = -1 EINVAL (Invalid argument)
shmdt(NULL)                             = -1 EINVAL (Invalid argument)
msgget(IPC_PRIVATE, 000)                = 0
msgsnd(0, NULL, 0, 0)                   = -1 EFAULT (Bad address)
msgrcv(0, ^

Unprivileged LXC container says "User Namespace: false"

I just gave this a whirl because it's super useful, thanks for writing this!

I'm getting this result from amicontained-linux-amd64 while attached to an unprivileged LXC container:

root@xenial:~/tmp# ./amicontained-linux-amd64 
Container Runtime: lxc
Host PID Namespace: false
AppArmor Profile: lxc-container-default-cgns (enforce)
User Namespace: false
Capabilities:
	BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_tty_config mknod lease audit_write audit_control setfcap syslog wake_alarm block_suspend audit_read

Is the User Namespace: false line expected? Maybe I'm misunderstanding something, but I would have expected that to return true when an lxc.id_map option is set in the container config file.

Host is Ubuntu zesty, kernel 4.10.0-28, lxc 2.0.8. The unprivileged container runs Ubuntu Xenial.