Easy Containers for Puppy Linux

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

Easy Containers for Puppy Linux

#1 Post by BarryK »

Well, this is "cutting edge" for me, but sandboxes, chroot-jails and containers for Linux have been around for years, with many different ways of doing it.

jamesbond has done a lot of work in this area for Fatdog, and I posted an email he sent me yesterday:

http://barryk.org/news/?viewDetailed=00501

After studying a lot of online documentation, I have put together something very simple, that I have named "Easy Containers". I have just now posted about it on my blog:

http://barryk.org/news/?viewDetailed=00502

The basic idea of containers is to run an app in isolation, with far greater security than the normal running as a non-root user.
But it also has uses other than for security, for example, compile a package in a container, and test it, without messing up the main filesystem.

But, I am new to this, and I am wondering what security holes still exist with what I have done.

Also, there are a couple of issues, a crash-at-first-X-app-run, and no dbus.

This topic is extremely interesting, with enormous potential for our puplets, so I thought I would post to the forum and invite feedback.

One thing, most Puppy kernels do not have overlayfs enabled, though it is part of the kernel source. Instead, they use the third-party aufs. So my instructions for mounting a layered filesystem will be slightly different in the case of aufs.
[url]https://bkhome.org/news/[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#2 Post by BarryK »

Oh, one other important point. You need to have a Linux kernel with namespaces support. Some Puppy kernels, including Quirky, do not have this.

I am currently using kernel 4.4.44, configured as shown here:

http://barryk.org/news/?viewDetailed=00500

Fatdog64 should be OK. Fatdog64 has aufs, probably not overlayfs (I haven't checked, just guessing).
[url]https://bkhome.org/news/[/url]

User avatar
drunkjedi
Posts: 882
Joined: Mon 25 May 2015, 02:50

#3 Post by drunkjedi »

Back in 2014, I used sandbox in Fatdog630 to have a kind of multi-seat setup for my 2 monitors.
Jamesbond provided commands for that

Code: Select all

/usr/share/sandbox/Xephyr -keybd evdev,,device=/dev/input/eventXXX,xkbrules=evdev,xkbmodel=evdev -mouse evdev,,device=/dev/input/eventYYY -screen 1024x768 -retro :1 &
DISPLAY=:1 openbox &
DISPLAY=:1 razor-panel &
DISPLAY=:1 rox -p /root/.config/rox.sourceforge.net/ROX-Filer/PuppyPin 
The eventXXX and eventYYY I found by running "evtest" on terminal and looking for which event devices correspond to my spare usb mouse/keyboard.

But I forgot about that after my need for it vanished.
I had saved those commands in a text file though for future reference.
Your post made me look for it.

A lot has changed in Fatdog since though.
And I am not much knowledgeable in this field either.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#4 Post by jamesbond »

BarryK wrote:Fatdog64 should be OK. Fatdog64 has aufs, probably not overlayfs (I haven't checked, just guessing).
Fatdog64 has overlayfs, but it's not built-in. One needs to "modprobe overlay" first to activate it before use.

@drunkjedi: those commands should still work :D
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#5 Post by BarryK »

Some interesting comments about Docker here:

https://news.ycombinator.com/item?id=8426764
Docker is based on Linux namespaces. The first thing which comes to mind is that Docker does not use user namespaces. Hence, the root within Docker is the same root as on the host side. Of course Docker papers over the issue by using apparmor and other tricks but this does not cure the issue itself.
Interesting, because I am using the 'unshare' utility with everything unshared, including "user namespaces". Does this mean I am one-up on Docker?

For any of you guys reading this thread, who are not developers, a comment about what this could mean for the end-user:

Potentially, could do away with users 'spot' and 'fido'.

Just run Internet apps in a container. In fact, it could just be one container I suppose, for "trusted" apps. To actually do that, I am intending something very simple, just run, seamonkey for example, like this:

# ec-chroot seamonkey

and everything is taken care of. The container is created and chrooted into and seamonkey executed. File downloads are in the container, but accessable from the host system.

Or, there could just be the one container, that has a monitor utility that waits to be told what app to run, but again, all done under-the-hood.

As a user, you will see what looks like the entire Quirky/Puppy/whatever filesystem, but it is actually isolated inside the container and you can't get out. Doing things "outside", such as reading your personal files, will not be possible, well hoping to get close to that complete isolation.
[url]https://bkhome.org/news/[/url]

User avatar
drunkjedi
Posts: 882
Joined: Mon 25 May 2015, 02:50

#6 Post by drunkjedi »

jamesbond wrote:those commands should still work :D
Not as it is, there's no /usr/share/sandbox/Xephyr, but Xephyr is present somewhere.
I didn't look for it then as had some chores.
Will look at it tomorrow, now I am at work.
BarryK wrote:Potentially, could do away with users 'spot' and 'fido'.

Just run Internet apps in a container.
Does the sandboxing Google Chrome/Chromium use is of similar idea?
Is it somehow inferior than using single container as you say?

I tried reading about it, but I am too noob to understand it.
https://chromium.googlesource.com/chrom ... 2065670614

Sorry to bother you with my noobish questions.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#7 Post by jamesbond »

@drunkjedi: Xephyr is now inside your PATH and you con't need to prefix it to run. If you need to know the actual location, run "which Xephyr". (it's inside /usr/bin).
Does the sandboxing Google Chrome/Chromium use is of similar idea?
Yes, except that Chrome only use it to protect itself and nobody else.
Is it somehow inferior than using single container as you say?
The single container exposes the container features to multiple unrelated processes; e.g. you can have both geany and seamonkey running in the same container. With Chrome, the sandboxed part of Chrome runs in a hidden "container" which nobody else can see or access.

@Barry:
Interesting, because I am using the 'unshare' utility with everything unshared, including "user namespaces". Does this mean I am one-up on Docker?
I'm not sure. That link is from over 2 years ago. That being said, I know that Docker uses aufs (at least some variants) - a few Docker guys asked Junjiro a couple of times in the past.
I want to avoid any "mount -bind ..." or "mount -rbind ...", so instead of doing that for /dev, I created static device nodes in q_top1/dev -- you can copy these out of initrd-tree/dev in Woof.

The online advice is to execute "mount --rbind /dev ./q_top1/dev" prior to the chroot, and I don't know what the downside is with just having static device nodes.
Those who provide you that advice usually uses devtmpfs (or at least tmpfs) attached to /dev. Sharing the mount to inside the container means that the host performs device management for the container - e.g. plug in a USB flash drive, and a device node will appear on *both* host and container.
A device node that is in-use in the host, what of that? -- having a copy of the node in the rootfs, is that unusable? In what situation would this matter?
mount --rbind doesn't make a copy. It makes the same subset of filesystems shows up in two different places. For device nodes this isn't a problem. But if you have normal file that you put in /dev, and at the same thing you have both host and container trying to write to it, of course you'll be hosed.
It is interesting that ":0" works inside the chroot, some online docs state that won't work, and you need to use other methods, such as the following...
I can't reproduce this. I can't get it to work, and I expect it to work. For DISPLAY=:0 to work, /tmp must be shared from host to the container, because X apps needs to access an Unix socket which is located in /tmp.
Second, I could not get it to work, the value of DISPLAY is reported as invalid inside the chroot environment.
This is odd. I can connect to it just fine.
Here is something interesting to think about. Inside the container:
sh-4.3# mkdir /mnt/sda2
sh-4.3# busybox mount -t ext4 /dev/sda2 /mnt/sda2
mount: permission denied (are you root?)
sh-4.3# whoami
root
Well, you are not, that's point. You have uid=0 inside the container, but of course in reality you're not. Run the ec-chroot, and while it's running, on **the host**, run "ps -ef f w" and you will see that that process is run as a normal user. Everything you do is limited to what that user can do.
Another example - while you're still on the root, before creating the overlay, try this:
1. create a file in q_rw/rw1
2. chmod 0700 that file, so that only root can read it
3. Then launch your ec-chroot, and see if you can read that file (or modify it).
You should not be able to.

So when you run and use user_ns (the marketing name for that is "unprivileged container"), there are a lot of restrictions you can't do in addition to the above. You can't mount, you can't create device nodes, etc.
It is most pertinent to now ask, how secure is this? I have used 'unshare' to unshare everything, have not run "mount --bind" or "mount --rbind", "env -i" has removed most environment variables. What more can we do to improve security?
You did not unshare the network :) Next level would be to unshare the network so that host and container uses different network stack, and then using iptables to NAT between the container and the host.

Another level of security is also to launch "unshare" as non-root user (e.g. "unshare" executing under spot) although I haven't managed to do this myself.

Then there is a slew of knobs you can tune on the container - e.g. max memory it can use, max CPU time it can use (it's no good to have a container that eat 100% of CPU time and leaves the host with no CPU time to do anything else) - these are what cgroups are for. But whether these are needed, of course, depends on what you use it for.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

#8 Post by prehistoric »

This has been a subject I've thought about off-and-on since I first used chroot in Gentoo. Over time I've seen a variety of solutions, and later problems with them caused by clever people trying to break out of a chroot jail.

I even remember earlier attempts in Unix to use a restricted shell for similar purposes, which lasted less than a day when Dennis Ritchie got involved in breaking out.

I'm not willing to bet that any method is entirely bulletproof, but that raises a new possibility in my mind. It is hard to break out on the first attempt, and attackers typically try multiple methods, including some well-known ones.

Suppose there were an inner "leaky" container which would trigger a command to kill the entire process tree when it was breached. You don't need to make everything foolproof if you can use evidence of attempted breakout to detect hostile activity.

This idea is not fully formed just yet, but I think the concept of detecting hostile activity to terminate malicious processes is worth pursuing. I will admit I'm no longer sharp enough to pursue this myself. We don't all age as well as Barry.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#9 Post by BarryK »

prehistoric wrote:I will admit I'm no longer sharp enough to pursue this myself. We don't all age as well as Barry.
I'm still a young fellow, only 67.
[url]https://bkhome.org/news/[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#10 Post by BarryK »

jamesbond wrote:
It is interesting that ":0" works inside the chroot, some online docs state that won't work, and you need to use other methods, such as the following...
I can't reproduce this. I can't get it to work, and I expect it to work. For DISPLAY=:0 to work, /tmp must be shared from host to the container, because X apps needs to access an Unix socket which is located in /tmp.
I have just done it now:

Code: Select all

# mount -t squashfs -o loop,noatime q.sfs q_ro/ro1
# mount -t overlay -o lowerdir=q_ro/ro1,upperdir=q_rw/rw1,workdir=q_rw/work1 overlay q_top1
# cp -f /etc/resolv.conf ./q_top1/etc/resolv.conf
# unshare -piumU --fork --mount-proc --map-root-user --setgroups=deny env -i TERM=xterm DISPLAY=:0 /bin/busybox chroot ./q_top1 /bin/sh
Then inside the "container":

Code: Select all

# mount -t proc proc /proc
# mount -t tmpfs shmfs /dev/shm
# leafpad
# leafpad
Apart from the first-time crash, leafpad works, and there is no /tmp/.X11-unix

Why does it work for me?

I am happy that it works, as the socat method has a noticeable slowness. However, I would like to know why it works, and if something is wrong with doing it this way.

Note: Just as an extra verification that I am isolated from the host system, "rox" does not need that "-n" :)
[url]https://bkhome.org/news/[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#11 Post by BarryK »

I also did this in the host system, leafpad still works in the container:

Code: Select all

# xhost -
access control enabled, only authorized clients can connect
#
I don't have a .Xauthority file.
[url]https://bkhome.org/news/[/url]

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#12 Post by jamesbond »

I can reproduce the the BadShmSeg error. This is how I did it:
1. I run "unshare -piumUrfn --mount-proc" in a terminal (this launches the "container", but sharing the filesystem with the host).
2. Inside that terminal then I launch geany (or anything else)
3. Then I got this:

Code: Select all

The program 'geany' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadShmSeg (invalid shared segment parameter)'.
  (Details: serial 2165 error_code 128 request_code 130 minor_code 3)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Subsequent invocation of geany (or any other X programs) will work without error.

I have an explanation: Modern X server tries to enable shared memory support for X clients for performance purposes. Since we have specified "-i" switch (=don't share IPC, including shared memory segments), shared memory created by X server on the host cannot be accessed by X clients in the container. Thus it fails. Now my guess: when this fails, some flag is set (perhaps in the X server itself?), so that subsequent X server will access the server without using shared memory anymore. To see the list of shared memory, run "ipcs". Run this on the host, and in the container, to see the difference.

I still don't know why you can still connect to the host. In my example above I can do it because basically I'm sharing the entire / of the host to the container. As soon as I do "mount -t tmpfs tmpfs /tmp" inside the container (effectively hiding the host's /tmp under an empty filesystem), no other X program will work.

Perhaps, in your case, try to launch geany or leafpad inside the container, and then geany is running, run "netstat -apn". Here is my output:

Code: Select all

# netstat -apn
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name    Path
unix  2      [ ACC ]     STREAM     LISTENING     62089    39/geany            /tmp/geany_socket.e32d8f79
unix  3      [ ]         STREAM     CONNECTED     59235    -                   /tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     61057    45/gnome-pty-helper 
unix  3      [ ]         STREAM     CONNECTED     62087    39/geany            
unix  3      [ ]         STREAM     CONNECTED     61056    39/geany 
As you can see geany is talking to X server via the X0 socket. Perhaps in your case the socket is located elsewhere?

@prehistoric: the standard chroot is easy to get out of. It's not even considered as a bug, it is a "feature". This "container" stuff is another approach to this problem, and it has been an ongoing effort started as early as Linux 2.6.24. They finally got the user_ns working on Linux 3.9 (not that long ago right!) but of course it was still full of bugs - they even admitted that the implementation is not complete and is still an on-going effort. I'm sure if you try hard enough, you'll find a way to break out. For better isolation, I would still suggest to using something like qemu; and even that has its share of weakness.

The problem with "detecting hostile activity" is that it requires intelligence that a silicon doesn't have. That doesn't stop people selling AV and IDS though, and making tons of money along the way.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
Burn_IT
Posts: 3650
Joined: Sat 12 Aug 2006, 19:25
Location: Tamworth UK

#13 Post by Burn_IT »

Can someone explain to me what the difference is between the use of containers and the use of virtual machines such as virtualbox.
"Just think of it as leaving early to avoid the rush" - T Pratchett

User avatar
drunkjedi
Posts: 882
Joined: Mon 25 May 2015, 02:50

#14 Post by drunkjedi »

To generalize what difference I see is, VMs take up a lot of system resources. Each VM runs not just a full copy of an operating system, but a virtual copy of all the hardware that the operating system needs to run. So VM need lots of RAM and CPU power.
In contrast, all that a container requires is enough of an operating system, supporting programs and libraries, and system resources to run a specific program or many.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

#15 Post by prehistoric »

jamesbond wrote:...@prehistoric: the standard chroot is easy to get out of. It's not even considered as a bug, it is a "feature". This "container" stuff is another approach to this problem, and it has been an ongoing effort started as early as Linux 2.6.24. They finally got the user_ns working on Linux 3.9 (not that long ago right!) but of course it was still full of bugs - they even admitted that the implementation is not complete and is still an on-going effort. I'm sure if you try hard enough, you'll find a way to break out. For better isolation, I would still suggest to using something like qemu; and even that has its share of weakness.

The problem with "detecting hostile activity" is that it requires intelligence that a silicon doesn't have. That doesn't stop people selling AV and IDS though, and making tons of money along the way.
You don't have to tell me that breaking out via cntrl-d or cntrl-c was never intended to be a security feature. I used this in setting up Gentoo, back when I was downloading source over a dial-up connection. :cry:

What I'm suggesting does not require intelligence. I'm just noting that attackers typically try several approaches that work when defenders make elementary mistakes. I'm suggesting that escaping via one of these known weaknesses could put them in a new environment where any action, except termination of the whole process, triggers a defensive response.

This won't protect you from targeted attacks by someone who knows all about your code and environment, but it will stop a wide range of attempts to acquire information about your system. I'm assuming that some of the tricks to break out of a chroot jail will only occur as a result of hostile activity.

Perhaps there are legitimate uses. I just can't think of any.

Added: I'll admit I don't have the free brainpower to cope with all the details. I'm kept busy with things like updating my browser, which notified me it was out of date while I was posting. :roll:

User avatar
Burn_IT
Posts: 3650
Joined: Sat 12 Aug 2006, 19:25
Location: Tamworth UK

#16 Post by Burn_IT »

Surely one of the reasons for using a seperate "thing" for testing is that anything nasty is isolated - and that includes all reources and device drivers.
Is it not devices and drivers that much modern malware attacks?
"Just think of it as leaving early to avoid the rush" - T Pratchett

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#17 Post by BarryK »

jamesbond wrote:I can reproduce the the BadShmSeg error. This is how I did it:
1. I run "unshare -piumUrfn --mount-proc" in a terminal (this launches the "container", but sharing the filesystem with the host).
2. Inside that terminal then I launch geany (or anything else)
3. Then I got this:

Code: Select all

The program 'geany' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadShmSeg (invalid shared segment parameter)'.
  (Details: serial 2165 error_code 128 request_code 130 minor_code 3)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Subsequent invocation of geany (or any other X programs) will work without error.

I have an explanation: Modern X server tries to enable shared memory support for X clients for performance purposes. Since we have specified "-i" switch (=don't share IPC, including shared memory segments), shared memory created by X server on the host cannot be accessed by X clients in the container. Thus it fails. Now my guess: when this fails, some flag is set (perhaps in the X server itself?), so that subsequent X server will access the server without using shared memory anymore. To see the list of shared memory, run "ipcs". Run this on the host, and in the container, to see the difference.

I still don't know why you can still connect to the host. In my example above I can do it because basically I'm sharing the entire / of the host to the container. As soon as I do "mount -t tmpfs tmpfs /tmp" inside the container (effectively hiding the host's /tmp under an empty filesystem), no other X program will work.

Perhaps, in your case, try to launch geany or leafpad inside the container, and then geany is running, run "netstat -apn". Here is my output:

Code: Select all

# netstat -apn
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name    Path
unix  2      [ ACC ]     STREAM     LISTENING     62089    39/geany            /tmp/geany_socket.e32d8f79
unix  3      [ ]         STREAM     CONNECTED     59235    -                   /tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     61057    45/gnome-pty-helper 
unix  3      [ ]         STREAM     CONNECTED     62087    39/geany            
unix  3      [ ]         STREAM     CONNECTED     61056    39/geany 
As you can see geany is talking to X server via the X0 socket. Perhaps in your case the socket is located elsewhere?

@prehistoric: the standard chroot is easy to get out of. It's not even considered as a bug, it is a "feature". This "container" stuff is another approach to this problem, and it has been an ongoing effort started as early as Linux 2.6.24. They finally got the user_ns working on Linux 3.9 (not that long ago right!) but of course it was still full of bugs - they even admitted that the implementation is not complete and is still an on-going effort. I'm sure if you try hard enough, you'll find a way to break out. For better isolation, I would still suggest to using something like qemu; and even that has its share of weakness.

The problem with "detecting hostile activity" is that it requires intelligence that a silicon doesn't have. That doesn't stop people selling AV and IDS though, and making tons of money along the way.
Just a quick reply, will get back to looking at containers very soon.

When inside my container, I only mount /proc and /dev/shm, don't mount a tmpfs on /tmp.

Right now, I'm busy designing a "container friendly" infrastructure for Quirky. At first, I thought that I needed to be able to create overlay filesystems inside an overlay filesystem -- but found it doesn't work -- well, it was fixed back at kernel 4.2 but seems to have become broken again.
But I figured out another way to do it, details will be posted soon.
[url]https://bkhome.org/news/[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#18 Post by BarryK »

jamesbond wrote: I still don't know why you can still connect to the host. In my example above I can do it because basically I'm sharing the entire / of the host to the container. As soon as I do "mount -t tmpfs tmpfs /tmp" inside the container (effectively hiding the host's /tmp under an empty filesystem), no other X program will work.

Perhaps, in your case, try to launch geany or leafpad inside the container, and then geany is running, run "netstat -apn". Here is my output:

Code: Select all

# netstat -apn
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name    Path
unix  2      [ ACC ]     STREAM     LISTENING     62089    39/geany            /tmp/geany_socket.e32d8f79
unix  3      [ ]         STREAM     CONNECTED     59235    -                   /tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     61057    45/gnome-pty-helper 
unix  3      [ ]         STREAM     CONNECTED     62087    39/geany            
unix  3      [ ]         STREAM     CONNECTED     61056    39/geany 
As you can see geany is talking to X server via the X0 socket. Perhaps in your case the socket is located elsewhere?
Have to make the time to respond now to this though, it is too intriguing!

Running "netstat -apn" I get lots of lines with something like this:

Code: Select all

unix  2      [ ACC ]     STREAM     LISTENING     14424    -                   @/tmp/.X11-unix/X0
...so what does the "@" mean?

I quit geany, then mounted a tmpfs on /tmp (inside the container):

Code: Select all

sh-4.3# busybox mount -t tmpfs tmpfs /tmp
Then ran geany again, geany still works. Still get the same stuff with the "netstat -apn".
[url]https://bkhome.org/news/[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#19 Post by BarryK »

BarryK wrote:
jamesbond wrote: I still don't know why you can still connect to the host. In my example above I can do it because basically I'm sharing the entire / of the host to the container. As soon as I do "mount -t tmpfs tmpfs /tmp" inside the container (effectively hiding the host's /tmp under an empty filesystem), no other X program will work.

Perhaps, in your case, try to launch geany or leafpad inside the container, and then geany is running, run "netstat -apn". Here is my output:

Code: Select all

# netstat -apn
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name    Path
unix  2      [ ACC ]     STREAM     LISTENING     62089    39/geany            /tmp/geany_socket.e32d8f79
unix  3      [ ]         STREAM     CONNECTED     59235    -                   /tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     61057    45/gnome-pty-helper 
unix  3      [ ]         STREAM     CONNECTED     62087    39/geany            
unix  3      [ ]         STREAM     CONNECTED     61056    39/geany 
As you can see geany is talking to X server via the X0 socket. Perhaps in your case the socket is located elsewhere?
Have to make the time to respond now to this though, it is too intriguing!

Running "netstat -apn" I get lots of lines with something like this:

Code: Select all

unix  2      [ ACC ]     STREAM     LISTENING     14424    -                   @/tmp/.X11-unix/X0
...so what does the "@" mean?

I quit geany, then mounted a tmpfs on /tmp (inside the container):

Code: Select all

sh-4.3# busybox mount -t tmpfs tmpfs /tmp
Then ran geany again, geany still works. Still get the same stuff with the "netstat -apn".
Ah ha, someone asked the same question and got an answer here:

http://unix.stackexchange.com/questions ... -in-chroot

...my Xorg is using an "abstract socket" in the chroot. The host system does have /tmp/.X11-unix/X0 though.
[url]https://bkhome.org/news/[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#20 Post by BarryK »

Quoting from here:
http://unix.stackexchange.com/questions ... act-socket
On Linux (in recent versions), Xorg listens on both a Unix domain socket on the filesystem (/tmp/.X11-unix/X<n>) and in the abstract domain (shown as @/tmp/.X11-unix/X<n> in netstat output).

It also listens on TCP (port 6000 + <n>).

One can stop it from listening on TCP by adding a -nolisten tcp,
A useful read on abstract sockets, though it is unclear to me why they should be a security threat:

http://tstarling.com/blog/2016/06/x11-s ... isolation/
[url]https://bkhome.org/news/[/url]

Post Reply