Running Browser in a Container with LXC

[Neo_78]

Using the default sandbox feature in FatDog64 to run Firefox in a browser is straight forward with sandbox.sh. However, it is not considered a security tool and is easy to escape as the documentation states.

Has someone manged to get Firefox running in the suggested alternative sandbox-lxc with sandbox-lxc.sh?

It's complaining with an error that the display variable has not been defined and Firefox cannot be started.

[jamesbond]

When you launch sandbox-lxc.sh and it ask you about the network, choose either Proxy ARP or NAT.
Do not choose None.

If you choose one of those, the next screen you will be asked if you want to enable desktop emulation.
Answer yes.

A new "desktop in a desktop" will start, and you can launch your firefox from there.

PS: Sound does not work. If you need it to work, you need to specify special parameters. Let me know if you need it.

[Neo_78]

@jamesbond following your instructions, I can start a window. However, it remains all black and I am not able to execute anything. What am I missing?

If I am executing the whole desktop in this way isn't that like creating a clone of my complete system in a LXC container?
Because I was trying to isolate Firefox from the rest of the system. I am wondering if running FatDog on top of FatDog as a VM in QEMU might be a better approach...

Also, would it be possible to start the window screen with a specific size?

Is it possible to put all options including NAT configuration etc in one command that could be placed in a bash script to execute the screen without having to keep a terminal open?

[jamesbond]

@jamesbond following your instructions, I can start a window. However, it remains all black and I am not able to execute anything. What am I missing?

Is there any error in the terminal? Did you load the standard Fatdog SFS (fd64.sfs, etc)?
You will need to load at least fd64.sfs, and pup_init.

If I am executing the whole desktop in this way isn't that like creating a clone of my complete system in a LXC container?

Correct, but you can run it without involving your privata data (your savefile).

Because I was trying to isolate Firefox from the rest of the system.

I'm sorry, it's not possible. sandbox-lxc isn't meant to run a single application in a container like docker or EasyOS' container. It is meant to run an isolated copy of Fatdog.

I am wondering if running FatDog on top of FatDog as a VM in QEMU might be a better approach...

You can certainly do that too, if you need even more isolation / security than what LXC provides.

Also, would it be possible to start the window screen with a specific size?

Code: Select all

WINDOW_SIZE=1280x720 sandbox-lxc.sh

Use whatever resolution instead of 1280x720. The default is 1024x600.

Is it possible to put all options including NAT configuration

Yes, you can do

Code: Select all

USE_NETWORK=nat sandbox-lxc.sh

etc in one command that could be placed in a bash script to execute the screen without having to keep a terminal open?

I'm sorry, it's not possible either. Sandbox (all variations) are meant to be run interactively. Some of the options you can automate as I show above, but at the very least you will have to choose which SFS you want to load, and this cannot be bypassed.
You can run sandbox in a background (without being detached to a terminal), but you cannot start it from a script.

To run sandbox and close the terminal, you can start a "screen" session (or equivalent, like "tmux"), and then run sandbox within it. Once it runs, you can detach the screen and close the terminal. Whenever you need to control the sandbox again, launch "screen" again and re-attach the session.

[JakeSFR]

@jamesbond following your instructions, I can start a window. However, it remains all black and I am not able to execute anything. What am I missing?

Is there any error in the terminal? Did you load the standard Fatdog SFS (fd64.sfs, etc)?
You will need to load at least fd64.sfs, and pup_init.

It was also all black for me, but I figured out why.
It's a firewall (eztables) thing, at least in my case. I have it always enabled plus there are some additional rules created by create_ap script.
After disabling it all works now.

Greetings!

[Neo_78]

Ok, I start to understand how LXC is meant to work. No error output when I tried; the new desktop screen would simply stay black.

@JakeSFR so you would have to disable the eztables firewall? Or are there specific rules that need to be adjusted? Whats the best tool / way to configure the firewall?

My objective was really to run Firefox or Chrome in a container that is completely isolated from the rest of the system. So if the browser would get infected, the intruder would not be able to escape the browser and access system files.

Do you havd any recommendations for that scenario? Which container tool is EasyOS using?

[williwaw]

Which container tool is EasyOS using?

https://easyos.org/user/using-easy-containers.html

[Neo_78]

Has "Easy Containers" been specifically developed for EasyOS ? Could it be ported to FatDog?

[JakeSFR]

Ok, I start to understand how LXC is meant to work. No error output when I tried; the new desktop screen would simply stay black.

@JakeSFR so you would have to disable the eztables firewall? Or are there specific rules that need to be adjusted? Whats the best tool / way to configure the firewall?

My objective was really to run Firefox or Chrome in a container that is completely isolated from the rest of the system. So if the browser would get infected, the intruder would not be able to escape the browser and access system files.

Do you havd any recommendations for that scenario? Which container tool is EasyOS using?

Well, I've never been trying sandbox-lxc before, except for this one time, to see what's with that black Xephyr window.
Anyway, I just checked and it seems that it's enough to unblock these in order to get to the destkop:

Code: Select all

iptables -A INPUT -p tcp --dport 6001 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 6001 -j ACCEPT

But if it comes for the internet, I can't get it inside the sandbox.
And that's where my knowledge about networking ends...

Greetings!

[Neo_78]

@JakeSFR this is the firewall that is being used in FatDog, correct?

https://github.com/louwrentius/eztables

I just wondered about the "abandoned project" warning...

[jamesbond]

@JakeSFR this is the firewall that is being used in FatDog, correct?
https://github.com/louwrentius/eztables

That's correct. That's the "frontend", that is, the tool to manage the firewall.
The actual firewall used by Fatdog is inside the Linux kernel itself.
The low-level control program for this firewall is called "iptables", which is quite cryptic to use, and "eztables" is just a wrapper to things more user-friendly (but behind the scenes, eztables actually calls iptables to do its job).

I just wondered about the "abandoned project" warning...

Well that's a bit unfortunate isn't it. It wasn't abandoned when I last looked at it - but apparently it is, now.
But just because it's abandoned doesn't mean it suddenly stops working. It will continue working, only that it won't get any further update. But again, if you feel unsure, you can always use iptables directly, as JakeSFR showed you above.

@JakeSFR, the actual command to allow the outgoing connection depends on which network mode you choose (either proxyarp or nat), and of course it also depends on your current firewall settings.

[Neo_78]

Ok, that makes sense.

What's the actual difference between Proxy ARP and NAT when selecting the network settings of LXC?

Update:

I was able to start the desktop and Firefox with Internet access if eztables is disabled.

So the initial black screen and problem to access the internet seems to be a firewall configuration problem.

Haven't figured out yet which ports LXC requires exactly.

Overall, not really an ideal solution if a complete desktop clone has to be started if only browser access is required.

[Neo_78]

I am still trying to figure out how to get my LXC desktop with Internet access running while eztables is enabled. I am using the default eztables.cfg configuration.

Could you provide some insight how eztables has to be configured to get this working?

Also, LXC complains that it can only be executed under the root account if you try to run it as a non-root user. Is this the expected result?

[jamesbond]

1. Proxy ARP creates an IP address which is a peer of the host's IP address (=same subnet).
NAT creates an IP address which is located in a different network, where the host acts as a NAT router.

2. LXC is a privileged container. You can't run it as non-root. That's just what it is.

There are other "container"-type software included in Fatdog: "unshare", "pflask", and another one on gslapt ("bubblewrap"). They're all CLI and are rather raw, in the sense that you need to actually pass tons of command-line parameters to get them up and running; unlike sandboxes' family of scripts. I can't remember if any of them supports non-privileged container, so you will just have to experiment.

PS: Fatdog's standard sandbox (sandbox.sh and rw-sandbox.sh) already uses "unshare"; so while it's not as strongly isolated as sandbox-lxc, it's a bit better than just a "chroot".

3. eztables: Unfortunately I'm not very well versed with eztables myself. Hopefully other Fatdog users can offer their insights to help you.

[Neo_78]

Thanks for the explanation @jamesbond

NAT sounds more secure, but with a Proxy ARP any extra configuration of eztables probably does not apply. Will have to test that...

I guess the right container solution depends on the potential attack vector and that is frequently the web browser nowadays. So I could imagine that with LXC desktop, an attacker who manages to escape the browser would be trapped in the virtual desktop first before he could get into the main desktop. So in this case, you could simply power off the LXC instance and create a fresh desktop in seconds, which has an advantage. With a simple container solution (probably better than nothing), an attacker who escapes the browser would be directly in the main system and you would have to reboot the whole system.

eztables: Unfortunately I'm not very well versed with eztables myself. Hopefully other Fatdog users can offer their insights to help you.

Would be great if someone could share their knowledge how to correctly configure eztables to get it working with LXC.

Thanks everyone!

[Neo_78]

It looks like pflask supports unprivileged containers:

All the commands above have been executed with root privileges, but pflask can be invoked, with some limitations, by unprivileged users as well, as long as user namespaces are supported by the host system.

$ pflask --user=$USER -- id
uid=1000(ghedo) gid=1000(ghedo) gruppi=1000(ghedo)

For example, on recent Debian versions user namespaces are enabled, but are restricted to the root user only. To enable them for unprivileged users run:

$ sudo sysctl kernel.unprivileged_userns_clone=1

This functionality can be used to run every-day user applications such as a web browser inside a container:

$ pflask --user=$USER --mount=tmp:$HOME -- chromium --disable-setuid-sandbox

Are namespaces enabled in FatDog?

[step]

Are namespaces enabled in FatDog?

Yes.

Code: Select all

♯ ls /proc/$$/ns
cgroup  ipc  mnt  net  pid  pid_for_children  user  uts

[Neo_78]

Trying to start Firefox with pflask --user=$USER --mount=tmp:$HOME -- firefox --disable-setuid-sandbox I get the following error:

Code: Select all

No protocol specified
Error: cannot open display :0.0
[x] child failed with code '1'

[mikeslr]

@ Neo_78,

I don't know FatDog64. But if it can make use of auf to mount file-systems, it can run a web-browser located in a Chrooted-puppy. My tests --subject to my ignorance of the internal workings of Linux-- indicated that a thus 'chrooted-web-browser' can NOT escape the Chroot. The technique for creating one is spelled out in detail here, viewtopic.php?p=33971#p33971.

Chromium and clones do not provide an 'Open File' menu entry (either by default or by customizing the Tool-bar). But by the time of that post I had realized that Ctr-o could be used with them. So I tested Web-browsers of both mozilla and chromium heritage. I also tested file-browsers within the Chroot to see if it was possible for them to access files outside of the Chroot. It wasn't.

However, because of the instructions by which the ChrootedOS is made use of by the MainOS 'finger-printing' of the source of the internet activity IS possible:

#!/bin/sh
export LC_ALL=C
mount --bind /dev /cont/dev
mount --bind /proc /cont/proc
mount --bind /sys /cont/sys
mount -t devpts devpts /cont/dev/pts
cp /etc/resolv.conf /cont/etc/resolv.conf
cp /var/lib/dbus/machine-id /cont/var/lib/dbus/machine-id
xhost +
mkdir -p /cont/tmp/.X11-unix
mount --bind /tmp/.X11-unix /cont/tmp/.X11-unix
chroot /cont NAME-WITHIN-CONT-TO-START-APPLICATION "$@"
# for example: chroot /cont ff "$@" > ff being the name of the script to start portable-firefox.
exit

Extensions/Addons in the Chrooted-Web-browser can provide some measure of identity concealment. Running a VPN more.

[jamesbond]

Trying to start Firefox with pflask --user=$USER --mount=tmp:$HOME -- firefox --disable-setuid-sandbox I get the following error:

Code: Select all

No protocol specified
Error: cannot open display :0.0
[x] child failed with code '1'

You're not telling me a lot of the information needed to troubleshoot your problem.
1. What's $USER? Is it "root", or "spot", or any other user?
2. Are you using Login Manager, or do you auto-login as root?
3. What other customisations have you done?

I booted pristine Fatdog, and opened terminal, and run Seamonkey exactly as you described, and it worked.
I wish I can show you, but it's image file is about 650KB and it's too big for this forum.
Instead, I can only show you this blurry picture.

@mikeslr, thank you for the pointer. Yes, Fatdog64 uses aufs too, so what you suggested is possible. Actually, Fatdog64 already has pre-packaged "chrooted-sandbox" as a feature, it's called sandbox.

[Neo_78]

@jamesbond I am able to start both Firefox and Chrome in an unmodified FatDog64 system both in the root and non-root account. So I must have accidentally uninstalled a package in Gslapt that is required by pflask.

So which solution provides better security to run the browser? FatDog's sandbox or pflask each executed from a non-root account?

I remember the note in the FatDog documentation regarding the sandbox: "The sandbox is not a security tool. It is still possible for malicious apps to create havoc on the system. It is possible for malicious application to "escape" from the sandbox."

This basically led me to the attempt of trying LXC, where I am unfortunately struggeling with the firewall configuration...

[jamesbond]

So which solution provides better security to run the browser? FatDog's sandbox or pflask each executed from a non-root account?

I am not a security expert, so I'm not the right guy to ask.
Generally speaking however, security is commensurate with the threat, as well as the possible loss, as it is usually a trade-off with inconvenience (among other things).
There is no single right answer.

Others will say that running the browser under a non-root account is enough.
If you see @mikeslr's answer, he's quite convinced that a chroot-sandbox is sufficient.
Yet others will say running it under chroot-sandbox, as a non-root user, is enough.
If you ask @rufwoof, however, who is/was an actual security consultant, he will say Xorg is not secure enough to begin with, so you need to run it under VNC over ssh so the Xorg session can't be hijacked with a keylogger (and he's right). This has nothing to do with Fatdog, it has to do with Xorg design itself.

So where does it end?
How secure do you want to go?
What is your threat level?
How far are you prepared to go to secure your system?
What is it that you're going to do that will attract hostiles to come at you?
Etc ... so many aspects to consider.

I remember the note in the FatDog documentation regarding the sandbox: "The sandbox is not a security tool. It is still possible for malicious apps to create havoc on the system. It is possible for malicious application to "escape" from the sandbox."

The comment is still generally true, however, the sandbox we have today is a teeny weenie bit more secure than when that FAQ entry was written.
Back then, sandbox was just a glorified chroot, basically.
Today, however, it uses "unshare" to run under separate namespaces, just like pflask does.

However, namespaces is a ten-headed monster; it has so many knobs you can adjust.
pflask does it one way, and sandbox does it in another way.
I really can't comment on which one is more secure.
But it's important to remember that the tool is only as good as the one who calibrates it.
When improperly configured, an attacker __can__ escape both.

This basically led me to the attempt of trying LXC, where I am unfortunately struggeling with the firewall configuration...

sandbox-lxc is definitely more secure than the standard sandbox.
But I can't provide you with any guarantee either that nobody can escape from it.

Fatdog users who have serious security requirements need to go and pay security consultants to do penetration testing to see where all the holes are; and then report them to us so we can fix it - if it's feasible for us to do so without inconveniencing general usage. Otherwise, you can take their advise and customise Fatdog for your own needs - like @rufwoof does.

I need to thank @rufwoof who shares his knowledge (in this forum) on how to make Fatdog seriously more secure. I apply as much as I can from his recommendations, but I can't apply all of them because like I said above, security and convenience are (usually) diametrically opposite.

[Neo_78]

Thanks for your detailed explanation @jamesbond.

I just noticed that sandbox.sh cannot be executed from a non-root account: You must be root to use sandbox.

Is there a way around this?

The mentioned pflask solution can be executed by a non-root user.

[jamesbond]

I just noticed that sandbox.sh cannot be executed from a non-root account: You must be root to use sandbox.
Is there a way around this?

No, sorry. Sandbox.sh runs "mount" command and "mount" won't work if you're not root (or if "mount" is made setuid, but that opens the pandora box ...)

[user1111]

This is pretty much the core of what I use, but extended quite a lot for other customisations that I like for the desktop/environment. Might be of some help/guidance. Copy it to /root and run it from there. pflask/unshare/Xephyr/capabilities dropped based containment. Requires fd64.sfs to have been loaded into ram at system bootup

Code: Select all

#!/bin/bash

i=$1
((i=i+1)) # increment so if invoked without a parameter it will at least start

XEPHYR="-fullscreen -name Xephyr$i -dpi 144 -nolisten tcp"
#XEPHYR="-screen 680x369 -name Xephyr$i -dpi 144 -nolisten tcp"
MOUNTS="--mount=bind:/root/shared:/root/shared --mount=bind:/dev/video:/dev/video \
        --mount=bind:/dev/video:/dev/video0 --mount=bind:/dev/video:/dev/video1 \
        --mount=bind:/dev/snd:/dev/snd --mount=bind:/dev/mixer:/dev/mixer"
CAPS="--caps=all,-sys_admin,-sys_boot,-sys_chroot,-sys_ptrace,-sys_time,\
-sys_tty_config,-chown,-kill,-dac_override,-dac_read_search,-fowner,-setfcap,\
-setpcap,-net_admin,-mknod,-sys_module,-sys_nice,-sys_resource"
PFLASK="--keepenv --no-ipcns --no-netns ${MOUNTS} ${CAPS} --chroot=/container$i/top$i"
        
[[ ! -d /root/shared ]] && mkdir /root/shared
[[ ! -d /container$i ]] && mkdir /container$i
cd /container$i
if [ -d top$i -o -d sfs$i ];then umount -f top$i sfs$i;rmdir top$i sfs$i;fi
mkdir top$i sfs$i
[[ ! -d /changes$i ]] && mkdir /changes$i
[[ $(mount | grep "tmpfs on /changes${i} type tmpfs" | wc -l) -eq 0 ]] && \
                                                    mount -t tmpfs tmpfs /changes$i
mount -t aufs -o br=/changes$i:/aufs/pup_ro none top$i
[[ $? -ne 0 ]] && _error_exit "aufs layering mount failed"
if [ $(ps -ef | grep "Xephyr :$i" | wc -l) -ne 2 ];then
     Xephyr :$i $XEPHYR &
     XEPHYR_PID=$!
else
     xmessage "Start Xephyr on :$i failed"
fi
# configure the container environment
cp /var/lib/dbus/machine-id top$i/var/lib/dbus/machine-id
cp /etc/resolv.conf top$i/etc/resolv.conf
ln -s top$i/var/lib/dbus/machine-id top$i/etc/machine-id
printf "#!/bin/sh\n\nexport PATH=$PATH:/usr/local/bin\nrox -p\njwm\n"   >top$i/init
chmod +x top$i/init

DISPLAY=:$i empty -f unshare -m pflask $PFLASK -- /init            # The big chroot
wait $!                                    # Backgrounds so wait for its PID to end
umount top$i sfs$i >/dev/null 2>&1;rmdir top$i sfs$i >/dev/null 2>&1 # HOUSEKEEPING
rm -rf /container$i;umount /changes$i;rmdir /changes$i

exit 0

Everything below the above exit 0 is not interpretted so we use this space
to include notes/documentation

Requires fatdog fd64.sfs to be loaded into ram. I use multi-session save style
so my menu.lst looks like (actual UUIDs rebalaced with xxx) ...

title Fatdog 812 Final
root (hd0,0)
kernel /FATDOG812-FINAL/vmlinuz basesfs=ram:uuid:xxx:/FATDOG812-FINAL/fd64.sfs savefile=direct:multi:uuid:xxx:/FATDOG812-FINAL/: 
initrd /FATDOG812-FINAL/initrd

Copy/keep this script in /root and run it with a number to start another Xephyr
(X session) with unsharing, capabilities dropped, chroot ... container i.e. where
root within that container is root in name only, more like a heavily restricted
userid.

Each such container is isolated. However we can share files between the main
system and/or other containers via /root/shared folder

This script is a base/foundation example, works, but has not been extensively
tested and validations/checks etc. are minimal.

Each container runs with the image within fd64.sfs, there are no save files
contents loaded and any changes made during a container session are lost after
closing the container.

Xephyr uses Ctrl-Alt-X to exit, Ctrl-Alt-D to minimise, Ctrl-Shift to toggle
focus/locked and unlocked state. That state can normally be seen in the Xephyr
main window title, but as we use fullscreen Xephyr that is not visible, so if
Ctrl-Alt-D ..whatever do not work then try pressing ctrl-shift first,
otherwise if Xephyr is set to locked those ctrl-alt-D .. whatever key combinations
will seemingly not work.

As we use the same fd64.sfs for each container and where that is already copied
into ram, each container is very light, just mostly a bunch of files/pointers 
and where each container is isolated from each other and from the main session
Xephyr isolates X
pflast (chroot) restricts access
capabilities dropped and unsharing restrict access/control
A hack of one session is very limited in what it can do, even though it is root

If this script is called container then you might for instance start a number
of containers

for i in {1..3}
do
	./container $i
done

and maybe alt-tab between those and have a brower running in one, music
playing in another, document processing in the third. If one of those
gets hacked then it wont be able to break out and into the main session
or other container sessions, nor monitor the X sessions key strokes or
stuff commands into other sessions key buffer ...etc. Attempts to break
out of the container will be blocked due to even though its root, that
root does not have the priviledges.

Could still attack the local network so you might like to iptables drop
access to your router admin IP address. Whilst root in the main session
can easily reinstate that access, in the container sessions again it 
does not have the authority. To drop access to a router admin IP
of 192.168.100.1 ...

iptables -A INPUT -s 192.168.100.1 -j DROP

Personally I remaster fd64.sfs to include the setup I like, such as
including chrome ...etc. There are issues with seamonkey and how it
is configured in the standard Fatdog fd64.sfs when working with this
container script such as it saving downloaded files into /home/spot/Downloads
which is owned by spot and which root in the container can not access.
As I said earlier, very much a base/foundation script rather than a fully
fledged and extensively tested script. It is after all just 40 odd lines
of script.

Ctrl-Alt-D minimises the full screened Xephyr (container) window.
Ctrl-Alt-X exits the container
Ctrl-Shift toggles Xephyr mouse capture, where the status of that can usually be seen in the Xephyr window title, but as we full-screen Xephyr that isn't visible. So if Ctrl-Alt-D doesn't minimise the window, try pressing Ctrl-Shift to toggle the Xephyr focus and try Ctrl-Alt-D again.

Coded the above to be generic so you can run multiple containers by passing a numeric value. Each instance is separate from each other (isolation) but /root/shared is set up to be a common shared folder across all containers and the main session.

If for instance the script is called 'container' then you could start four sessions with

Code: Select all

for i in {1..4}
do
  ./container $i
done

[Neo_78]

Thanks @rufwoof. If I understand you correctly this is a pflask container configuration with limited capabilities that would have to be executed from root?

Or could it also be executed from a non-root account?

And you would basically run a complete image of FatDog64 inside that container?

[user1111]

Thanks @rufwoof. If I understand you correctly this is a pflask container configuration with limited capabilities that would have to be executed from root?

Or could it also be executed from a non-root account?

And you would basically run a complete image of FatDog64 inside that container?

Yes a pflask based containment with unsharing, capabilities dropped and running a separate X session (Xephhyr). Has to be executed by root.
Yes, uses the fd64.sfs that's already loaded into ram, so a very small footprint and quick to start. EasyOS or a revised version can/could load other images.

[Neo_78]

Thanks @rufwoof. Following your guide, I am able to execute your script. However, I encounter a couple of problems and have a couple of questions if you don't mind:

- How do you run the script "with a number"? Something simple like my_script.sh 1?

- Once running, I am not able to minimize the container with Ctrl-Alt-D or exit it with Ctrl-Alt-X. Also tried to toogle focus with Ctrl-Shift without any success. The normal FatDog menu inside the container cannot be used to shutdown or reboot the instance (no reaction).

- FatDog inside the container shows a black desktop and a different menu interface than the normal FatDog. Also font and window sizes seem to differ. I usually use a remastered FatDog version only with the programs, browser and configuration that I really need, which is booted from DVD into RAM. Is there a way run that remastered copy of FatDog inside the container instead of having to manually configure the setup again every time a new container is started?

- To restrict router panel access from inside the container, the mentioned iptable rule iptables -A INPUT -s 192.168.100.1 -j DROP would have to be executed from inside the container's FatDog instance, correct? I always had difficulties to get internet access working in LXC container (FatDog's default container) when using the eztables configured firewall.

Thanks for your guidance!

[user1111]

Yes my_script.sh 1 should use/set DISPLAY=:1
Or my_script.sh 3 should set DISPLAY=:3

For some fun in a terminal run Xephyr :3 &
and a Xephyr window should open.
Then run DISPLAY=:3 galculator
and galculator should appear in that window.
Or DISPLAY=:3 xterm
and a terminal should appear.
The Xephyr window title indicates using Ctrl-shift to toggle focus (lock the mouse/keys) to that window, which in my container is running full screen so you don't see that title.
Basically that's all we're doing but where instead of a window its set to full screen and instead of galculator or xterm we run pflask that sets up a chroot, unshares stuff, drops capabilities ...etc. to start a full session that's restricted. Whilst at the keyboard you can control that, from within the Xephyr/container the same keystrokes to control things don't have access to the main session X, so only the local keyboard can for instance flip between the containers X and the main sessions X, a hacked contained session doesn't have the access/permissions to do the same.

Try changing the -dpi from 144 to 96 (or whatever) in the Xephyr command line parameter set to reduce the font size inside the container. If you also remove the -fullscreen Xephyr parameter then it should start in a window that might help make things clearer.

Inside the container there is no authority to shutdown/reboot, so those menu items don't work. Nor with some other programs if the chroot/unshare/capabilities dropped prevent such actions.

I have my system set up to ctrl-alt-x to close a window (for openbox that's set in ~/.config/opebox/rc.xml) so by setting the focus off (ctrl-shift) keyboard control returns to the main session and ctrl-alt-x closes the window. I guess your setup has another keybinding, so maybe try using alt-tab to a window running in the main session and then closing the Xephyr window from there. If alt-tab doesn't work then try pressing ctrl-shift first. At least one window must be active in the main session for that alt-tab back to the main session to work, so leave a terminal or other window open before running the container.

I load whatever is in aufs as the loaded system, so if you boot from a modified fd64.sfs and have that loaded into ram at bootup then that is what the container also uses. With some modification you could instead load any other sfs as the system inside the container.

No the iptables command should be run in the main system, which turns router access off in the kernel. Inside the container root doesn't have permission to change that, so is restricted. eztables is just a front end for iptables. If the contained system could modify iptables then a hack of the container session could equally drop the iptables rule and gain access to the router admin page and launch a possible attack against that, so that action/permission is blocked within the contained session.

[Neo_78]

Thanks @rufwoof. Setting the screen resolution for the session lower makes things clearer and I am able to toggle the session window with Ctrl+Shift.

However, I am struggling with the correct way to terminate a session without keeping it running invisibly in the background. Ctrl+Alt+X won't work and I guess simply closing the window is not the correct way. Default FatDog uses Sven 0.6 for window keymaps, which assigns Win+K to execute "xkill" of a window, but I guess that's also not the correct way.

How do you completely delete a session so that this particular session cannot be restarted / reattached?

I am also unsure how to rejoin a session if it has been accidentally closed. For instance Xephyr :1 & or Xephyr :2 & will open a much smaller, black window.

I also noted the following warning when running the script:

Code: Select all

Warning: Unsupported high keycode 372 fro name <I372> ignored X11 cannot support keycodes above 255. This warning only shows for the first high keycode. 

Errors from xkbcomp are not fatal to the X server

The iptable drop rule works fine.

Appreciate your feedback!