Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 23 Mar 2017, 22:42
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
Easy Containers for Puppy Linux
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 2 [24 Posts]   Goto page: 1, 2 Next
Author Message
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 8000
Location: Perth, Western Australia

PostPosted: Wed 25 Jan 2017, 01:35    Post subject:  Easy Containers for Puppy Linux
Subject description: Simple grassroots build-it-yourself containers
 

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.

_________________
http://barryk.org/news/
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 8000
Location: Perth, Western Australia

PostPosted: Wed 25 Jan 2017, 01:59    Post subject:  

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).

_________________
http://barryk.org/news/
Back to top
View user's profile Send private message Visit poster's website 
drunkjedi


Joined: 24 May 2015
Posts: 646

PostPosted: Wed 25 Jan 2017, 03:22    Post subject:  

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:
/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.
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3036
Location: The Blue Marble

PostPosted: Wed 25 Jan 2017, 08:25    Post subject:  

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 Very Happy

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 8000
Location: Perth, Western Australia

PostPosted: Wed 25 Jan 2017, 08:39    Post subject:  

Some interesting comments about Docker here:

https://news.ycombinator.com/item?id=8426764

Quote:
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.

_________________
http://barryk.org/news/
Back to top
View user's profile Send private message Visit poster's website 
drunkjedi


Joined: 24 May 2015
Posts: 646

PostPosted: Wed 25 Jan 2017, 11:05    Post subject:  

jamesbond wrote:
those commands should still work Very Happy
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/chromium/src/+/master/docs/linux_sandboxing.md?_e_pi_=7%2CPAGE_ID10%2C2065670614

Sorry to bother you with my noobish questions.
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3036
Location: The Blue Marble

PostPosted: Thu 26 Jan 2017, 06:15    Post subject:  

@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).

Quote:
Does the sandboxing Google Chrome/Chromium use is of similar idea?

Yes, except that Chrome only use it to protect itself and nobody else.

Quote:
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:
Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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 Smile 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, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1608

PostPosted: Thu 26 Jan 2017, 19:07    Post subject:  

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.
Back to top
View user's profile Send private message 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 8000
Location: Perth, Western Australia

PostPosted: Fri 27 Jan 2017, 02:39    Post subject:  

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.

_________________
http://barryk.org/news/
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 8000
Location: Perth, Western Australia

PostPosted: Fri 27 Jan 2017, 02:54    Post subject:  

jamesbond wrote:

Quote:
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:
# 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:
# 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" Smile

_________________
http://barryk.org/news/
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 8000
Location: Perth, Western Australia

PostPosted: Fri 27 Jan 2017, 03:19    Post subject:  

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

Code:
# xhost -
access control enabled, only authorized clients can connect
#


I don't have a .Xauthority file.

_________________
http://barryk.org/news/
Back to top
View user's profile Send private message Visit poster's website 
jamesbond

Joined: 26 Feb 2007
Posts: 3036
Location: The Blue Marble

PostPosted: Fri 27 Jan 2017, 05:05    Post subject:  

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:
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:
# 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, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
Burn_IT


Joined: 12 Aug 2006
Posts: 2692
Location: Tamworth UK

PostPosted: Fri 27 Jan 2017, 08:58    Post subject:  

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
Back to top
View user's profile Send private message 
drunkjedi


Joined: 24 May 2015
Posts: 646

PostPosted: Fri 27 Jan 2017, 09:12    Post subject:  

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.
Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1608

PostPosted: Fri 27 Jan 2017, 10:49    Post subject:  

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. Crying or Very sad

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. Rolling Eyes
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 2 [24 Posts]   Goto page: 1, 2 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1601s ][ Queries: 11 (0.0095s) ][ GZIP on ]