EasyOS version 2.3.2, June 22, 2020

[rufwoof]

Created a directory squashfsroot and within that created folders of /usr/lib and copied the /usr/lib/firefox folder into that. Made a sfs (mksquashfs squashfsroot firefox.sfs) and both root and rover outside of the containers can use that firefox.sfs OK (after having copied it to the relevant directory and set it to be mounted in bootloader).

If however I use container editor to add that as a SFS for the sakura container I created, it doesn't load the sfs within the container (I had removed /usr/lib/firefox from within the container and rebooted prior to trying to load the sfs).

[rufwoof]

Made a little progress with running rover userid in a container, notes so far being :

Create a container for sakura (i.e. terminal) making sure that the Namespace for "user" is unticked when creating the container.

Start/run the sakura container i.e. clicking its desktop icon.

As root create a /home/rover/.profile file, adding

HOME=/home/rover export HOME
DISPLAY=:0 export DISPLAY

(not sure if bourne export format should be being used as echo $0 shows sh however /bin/sh links to bash so maybe its export DISPLAY=:0 format ???).

values to that file, and save it.

Edit /usr/bin/seamonkey script to also test for rover in a similar manner
to how it tests for spot, so that it points that rovers /home/rover folder
rather than /root (another if ... else statement), that will ensure it creates
the seamonkey cache etc. in the correct folder for rover

Change /etc/profile.d/pup_gtk from hard coded /root/.gtk... to ~/.gtk..

Add rover to the audio group (adduser rover audio)

Exit the container and restart it again. Make sure you know the password for rover i.e. perhaps passwd rover ... and enter woofwoof twice as the password (or whatever)

Login to rover (login rover ... and enter woofwoof password).

Run seamonkey (or rox or whatever) ... and you're running as rover.

Logout back to root with exit.

Rover can't run ppm i.e. at the command line type ppm and it will prompt for the root password, but reject the request as not having permissions, however as root you can run ppm in the container and add programs ...etc. rover can also su and then run ppm ok, but of course it needs to know the root password and that could be disabled (removed from sudoers or whatever).

More ideally for better security once setup, login into rover should be automatic when you start the container, and the container should close when you 'exit' out of rover, and su should be disabled. That way the only way to change things (add programs or whatever) would be to use the normal (non container) access to add rover to sudoers and then login to the container, su and do whatever, and then remove rover from sudoers again.

[rufwoof]

Pyro 0.9 security audit

See https://docs.oracle.com/cd/E19683-01/81 ... index.html and https://docs.oracle.com/cd/E19683-01/81 ... index.html

Code: Select all

inside pyro 0.9 container ...
find / -type f \( -perm -4000 -o -perm -2000 \)
...

/usr/bin/Xorg
/usr/bin/chage
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/expiry
/usr/bin/fusermount
/usr/bin/gpasswd
/usr/bin/newgidmap
/usr/bin/newgrp
/usr/bin/newuidmap
/usr/bin/passwd
/usr/bin/sudo
/usr/bin/toppler
/usr/lib/pppd/2.4.7/pppoatm.so
/usr/lib/pppd/2.4.7/rp-pppoe.so
/usr/libexec/dbus-daemon-launch-helper
/usr/libexec/ssh-keysign
/usr/libexec/xf86-video-intel-backlight-helper
/usr/sbin/cgi-wrapper
/usr/sbin/hiawatha
/usr/sbin/mtr-packet
/usr/sbin/pppd
/usr/sbin/pppoe
/bin/mount-FULL
/bin/su
/bin/umount-FULL

[rufwoof]

In the desktop icon for my sakura container I right clicked and text edit the file and added a login parameter so it looks like

Code: Select all

#!/bin/sh
exec ec-chroot sakura -l

Opening the container and in /root creating a .bashrc containing

Code: Select all

#!/bin/bash

#Number	SIG	Meaning
#0	0	On exit from shell
#1	SIGHUP	Clean tidyup
#2	SIGINt	Interrupt
#3	SIGQUIT	Quit
#6	SIGABRT	Abort
#15	SIGTERM	Terminate

trap finish 0 1 2 3 6 15
finish() 
{
  exit
}
login
exit

results in a login prompt being provided when the sakura container is opened, and the container shuts down after you exit or ctrl-c or whatever from that session.

[rufwoof]

To help reduce confusion when running rover in a container, I've modified its .profile to

DISPLAY=:0 export DISPLAY
PATH=$PATH:/home/rover/bin export PATH
rox --pinboard=/home/rover/.pinboard

so that when I click on the sakura container and log in as rover instead of just a terminal window on the same (main) desktop, it switches the desktop pinboard - on which I can drop icons that are from within the container, whilst the tray menu etc are still the root level (non container). Which means you can also open a root level rox-filer window and drag/drop files between a rover level rox-filer

Its really neat having root and restricted user rover running layered like that. Seamonkey running as a restricted user (rover) in a container but where you can select text from within the browser window and paste that into a root level text editor ... or whatever.

Still a bit confusing at times however, for instance you can't drag/drop files from a rover rox-filer into a root rox-filer as it hasn't the permissions, you have to go the longer way around and open two root level rox-filers with one showing /mnt/wkg/containers/sakura/container/home/rover .. or wherever inside the container ... and that folder disappears once the session is disconnected (logout of rover). Neatly the rox pinboard also automatically disappears when you logout of rover to reveal the normal root pinboard as before.

Frankly I think Pyro is awesome, Barry's done a outstanding feat, Puppy programs/scripts, root and restricted users running on the same desktop, with version controls etc. I've now installed it frugally to HDD as the 2GB MMC card I was using was getting close to being full.

[rufwoof]

Inside a sakura container installed yad using PPM and works as expected

Trivia : what time do most pictures of clocks show ... 10 to 2 as it makes it look like the clock is smiling.

[rufwoof]

Whilst Spot and Fido were rather goofy, Rover is a real working dog - but one with a split personality that can bite you periodically.

Colour coding windows and/or different themes for root and rover can help make Rover a little more tame.

[rufwoof]

Barry, I'm seeing a issue with rolling back a container. Have a number of container snapshots and selecting one and clicking Rollback ...

Code: Select all

Code at very bottom of /usr/sbin/easy-version-control

Issue : not rolling back correctly

Debug (sh -x) run (extract of relevant part) :


++ gtkdialog --program=EVC_DIALOG
+ RETVARS='DEPTH_MAX="5"
EASYVC_0Z9="false"
EC_NAME="sakura"
EC_SNAP="201804240029.sfs"
RW_0Z9_201804230729="false"
RW_0Z9_201804231357="false"
RW_0Z9_201804231628="false"
RW_0Z9_201804232254="false"
RW_0Z9_201804240013="false"
EXIT="ec_rollback"'
+ eval 'DEPTH_MAX="5"
EASYVC_0Z9="false"
EC_NAME="sakura"
EC_SNAP="201804240029.sfs"
RW_0Z9_201804230729="false"
RW_0Z9_201804231357="false"
RW_0Z9_201804231628="false"
RW_0Z9_201804232254="false"
RW_0Z9_201804240013="false"
EXIT="ec_rollback"'
++ DEPTH_MAX=5
++ EASYVC_0Z9=false
++ EC_NAME=sakura
++ EC_SNAP=201804240029.sfs
++ RW_0Z9_201804230729=false
++ RW_0Z9_201804231357=false
++ RW_0Z9_201804231628=false
++ RW_0Z9_201804232254=false
++ RW_0Z9_201804240013=false
++ EXIT=ec_rollback
+ '[' 5 '!=' 5 ']'
+ '[' ec_rollback == erase ']'
+ '[' ec_rollback == snapshot ']'
+ '[' ec_rollback == rollback ']'
+ '[' ec_rollback == ec_erase ']'
+ '[' ec_rollback == ec_snapshot ']'
+ '[' ec_rollback == ec_rollback ']'
+ test_cont_mntd_func
++ mount
++ grep containers/sakura/container
+ MNTDFLAG=
+ '[' '' ']'
+ return 0
+ '[' 0 -ne 0 ']'
+ mkdir -p /tmp/easy_version_control/tmpmnt
+ busybox mount -t squashfs -o loop,noatime /mnt/sda2/easy/easy-0.9/containers/sakura/rw-201804240029.sfs.sfs /tmp/easy_version_control/tmpmnt
mount: mounting /mnt/sda2/easy/easy-0.9/containers/sakura/rw-201804240029.sfs.sfs on /tmp/easy_version_control/tmpmnt failed: No such file or directory
+ rm -rf /mnt/sda2/easy/easy-0.9/containers/sakura/.session/audit /mnt/sda2/easy/easy-0.9/containers/sakura/.session/dev /mnt/sda2/easy/easy-0.9/containers/sakura/.session/ec-run /mnt/sda2/easy/easy-0.9/containers/sakura/.session/etc /mnt/sda2/easy/easy-0.9/containers/sakura/.session/home /mnt/sda2/easy/easy-0.9/containers/sakura/.session/pkg.specs /mnt/sda2/easy/easy-0.9/containers/sakura/.session/root /mnt/sda2/easy/easy-0.9/containers/sakura/.session/usr /mnt/sda2/easy/easy-0.9/containers/sakura/.session/var
+ cp -a '/tmp/easy_version_control/tmpmnt/*' /mnt/sda2/easy/easy-0.9/containers/sakura/.session/
cp: cannot stat '/tmp/easy_version_control/tmpmnt/*': No such file or directory
+ '[' -f /mnt/sda2/easy/easy-0.9/containers/sakura/configuration-201804240029.sfs ']'
+ sync
+ busybox umount /tmp/easy_version_control/tmpmnt
umount: can't unmount /tmp/easy_version_control/tmpmnt: Invalid argument

Post run I looked at /tmp

Code: Select all

# ls -l /tmp/easy_version_control
total 40
-rw-r--r-- 1 root root 431 Apr 24 00:31 all-snapshots
-rw-r--r-- 1 root root   6 Apr 24 00:31 chkbx-EASYVC_0Z9
-rw-r--r-- 1 root root   6 Apr 24 00:31 chkbx-RW_0Z9_201804230729
-rw-r--r-- 1 root root   6 Apr 24 00:31 chkbx-RW_0Z9_201804231357
-rw-r--r-- 1 root root   6 Apr 24 00:31 chkbx-RW_0Z9_201804231628
-rw-r--r-- 1 root root   6 Apr 24 00:31 chkbx-RW_0Z9_201804232254
-rw-r--r-- 1 root root   6 Apr 24 00:31 chkbx-RW_0Z9_201804240013
-rw-r--r-- 1 root root   1 Apr 24 00:30 comment
-rwxr-xr-x 1 root root 331 Apr 24 00:31 ec-ver-snaps
-rw-r--r-- 1 root root  61 Apr 24 00:29 snapshot-exclusions1
drwxr-xr-x 2 root root  40 Apr 24 00:31 tmpmnt
# ls -l /tmp/easy_version_control/tmpmnt
total 0
# 

File date/times seem to coincide with the time I ran the test.

Looks like line 479 in /usr/sbin/easy-version-control

Code: Select all

busybox mount -t squashfs -o loop,noatime /mnt/${WKG_DEV}/${WKG_DIR}containers/${EC_NAME}/rw-${EC_SNAP}.sfs /tmp/easy_version_control/tmpmnt

should not include the .sfs after {EC_SNAP} ???

Removing that .sfs in my installation (frugal HDD) ... and it rolls back containers OK.

[rufwoof]

I've been messing around with initrd. Opened up the initrd using Easy and dropped the q.sfs into that. The following code aufs mounts that 'internal' q.sfs, formed as a aufs union of the q.sfs (ro) and a q_changes folder on my HDD (sda2, ext3 format). A earlier version had a folder in the initrd as being the changes folder.

Instead of switch root'ing it just uses chroot of that aufs merged q_top folder, so you can exit back out to the initrd level again.

A pre-cursor proof of concept for the idea of the initrd potentially wget'ing both the q.sfs and a sfs copy of the q_changes folder (save folder content) from a remote site, extract the changes sfs to a folder in the initrd and then aufs mount that with the q.sfs, i.e. set things up before chroot'ing into that. And then afterwards (when exit chroot), run mksquashfs of the initrd copy of the changes back to a remote site.

That could be a very small initrd, maybe a USB stick, that doesn't even touch the PC's HDD's but uses the ethernet and PC's CPU/ram to download both the main sfs and changes sfs, runs everything in memory and preserves changes back to the remote site (no need to re-upload the main q.sfs as that is static).

With more modern systems having more than enough ram to run puppy like OS's totally in ram, storing changes in ram alongside having q.sfs also in ram is increasingly becoming less of a issue as time passes. And slower usb read/write speeds/limitations are largely replaced by ethernet/internet download speeds/limitations.

Code: Select all

#!/bin/sh
#
# Rufwoof April 2018
#
# Very crude (no error checking etc.) messing around with initrd
# and aufs layering
#
# Notes :
#
# The q.sfs in the initrd could be a filesystem just sufficient enough
# to open up a network connection and wget or similiar to retreive
# files (a proper main q.sfs and q_changes.sfs) that we can then
# setup and chroot into. Could be a simple cli type 'system' so a
# script could automate the connection/download.

export OUTPUT_CHARSET=UTF-8
mount -t proc none /proc
mount -t sysfs none /sys
mount -t rootfs -o remount,rw rootfs /
ln -s /proc/mounts /etc/mtab 2> /dev/null
export PATH="/bin:/sbin"

# Mount q.sfs (that we have stored in initrd) to q_sfs
# Mount rw (record of changes) as q_changes
# q_top is the user view layer i.e. overlaid q.sfs and changes
mkdir q_sfs q_top q_changes
mount -t squashfs -o loop,noatime /q.sfs q_sfs
mount -t aufs -o br=/q_changes=rw:/q_sfs=ro aufs /q_top

# chroot into the q_top i.e. q.sfs overlaid with sda2:/q_changes 
# in combination visible as q_top
chroot /q_top /bin/sh
# so we can net connect and retreive a changes sfs file from a 
# remote location
#
# CURRENTLY NOT CODED NEEDS TO BE MANUALLY RUN TO 
# DOWNLOAD AND COPY THE q_changes.sfs FILE TO THE / 
# FOLDER LEVEL OF q_top BEFORE EXITING THE CHROOT
# as proof of concept I ran /etc/rc.d/rc_sysinit when in the
# session, which was enough to be able to run
# busybox wget wttr.in ... that retreived a index.html file


# back to initrd level shell
/bin/busybox sh
# where we might unmount the union ... extract the changes.sfs
# file to a folder and remount again with that folder content bofore
# chrooting back to that amended q_top that includes changes

# current q_changes should have been populated with the content
#of a sfs downloaded of changes

unsquashfs /q_changes/q_changes.sfs -d q_changes_actual

# Release the current arrangement
sync
umount /q_top
umount /q_sfs

# can drop the temp q_changes content
rm -rf q_changes
# and move in the actual changes
mv q_changes_actual q_changes

# before reforming the aufs
mount -t squashfs -o loop,noatime /q.sfs q_sfs
mount -t aufs -o br=/q_changes=rw:/q_sfs=ro aufs /q_top

# and chroot into that
chroot /q_top /bin/sh

# when exit the session, sfs the q_changes folder content
# and transfer that to a remote site
# MANUAL AT PRESENT ... NOT CODED YET


# When exits from the session
# put into a repeated cli loop so can't exit to nowhere
# and reboot using ctrl-alt-delete. Or even re-enter the q_top
# level again using a command of
# chroot /q_top /bin/sh
while [ 1 -lt 8 ];do 
   /bin/busybox sh
done

# No traps, so if does break out of the while loop ... tidy up
sync
umount /q_top
umount /q_sfs

###################################

[BarryK]

rufwoof,
You are doing some very interesting things!

I am keen to get back to it, but traveling right now -- posting this from Sydney, en-route to Brisbane.

Re the gotchas and other difficulties that you mentioned, yes, the "devil is in the details"!

I want it to end up very simple to use, and that problem with dragging files owned by root to a rover-container, was something that I wanted to avoid. But, it might be possible to hack Rox and have a popup, or even an automatic ownership conversion.

It would also be possible to use inotify to watch files in a container, or at least certain folders, and automatically fix any ownership/permission problem.

...Just thinking off the top of my head.

[BarryK]

Barry, I'm seeing a issue with rolling back a container. Have a number of container snapshots and selecting one and clicking Rollback ...

.....


Removing that .sfs in my installation (frugal HDD) ... and it rolls back containers OK.

I am not surprised that container rollback is broken, as i never actually tested the code!

I hope to be able to check it out soon, after arrival at Brisbane. Thanks for finding that problem and likely fix.

[rufwoof]

I've also frugal installed Xerus 0.6.8. Having trouble with the graphics. Since much of video management has been migrated into kernels so pretty graphics can be displayed during bootup or whatever, more usually that finishes early in the boot phase. Mostly on my boots I have large/normal sized boot text that usually quite quickly switches over to being small text ... way before X startup starts to run. So X-Org configuration in effect runs later and replaces the kernel X configuration. In EasyOS Xerus however there's such a lag between my boot text switching over to smaller text that X has already started. For a second or two I see a nice EasyOS desktop, and then zap its all corrupted/unusable as the kernel X overrides Xorg.

The only solution I seem to be able to use is to add q-fix=nox as a menu.lst kernel boot parameter, which gives enough time for the kernel X to have done its thing before I xwin and X-org kicks in.

EDIT :

I've added

Code: Select all

COLS=`tput cols`
STALLED=0
while [ $COLS -lt 100 ]; do
   sleep 0.1
   COLS=`tput cols`
   STALLED=1
done
if [ $STALLED = 1 ]; then
   sleep 1 # give extra time to settle
fi

near the top of /usr/bin/xwin
right after the

Code: Select all

export TEXTDOMAIN=xwin
export OUTPUT_CHARSET=UTF-8
. gettext.sh

part.

So I no longer have to boot with qfix=nox.

Fixes things in my case, but not generic i.e. my boot process transitions from 80 column console text initially over to 180 columns once the kernel graphics mode has kicked in. The above code just defers running the rest of xorg (xwin) until after that 180 column kernel graphics mode is at least up/running.

[rufwoof]

I quickly browsed back through past posts in this thread and noted that some were seeing a very long duration orange box message when loading seamonkey. The fix for me was to ensure /etc/profile.d/pup_gtk uses a ~/... rather than /root... path declaration as

Code: Select all

export GTK2_RC_FILES=~/.gtkrc-2.0

otherwise when running as spot it tries to create cache (or whatever) files in a folder it doesn't have permission to do so i.e. /root

[rufwoof]

I hope to be able to check it out soon, after arrival at Brisbane. Thanks for finding that problem and likely fix.

Dropping the .sfs also fixes it in Xerus as well Barry.

In my Xerus frugal I'm using spot to log in to the sakura container that I created and I then run seamonkey. Nice to be running a restricted userid running inside a chroot container and where you can just rollback that container to a pristine first installed type case assuming you had made a snapshot of the container shortly after having created it/set seamonkey up.

In Pyro I have different themes for normal and containers as a aid to distinguishing whether a window is running as root or as a container window. Generally however I'm just tending to use a container for seamonkey and stick with root for most other (non internet) things.

Have a safe trip. At least its not to Perth and back

[rufwoof]

If you are running, say, Firefox, in a container, I don't know how the existence of a utility such as exit-chroot can be used

Browsing through the code I see that a container is created by faking root and chroot i.e. using unshare ... Obvious now! I'd missed that before however, lack of understanding and was blindly assuming just chroot.

[BarryK]

If you are running, say, Firefox, in a container, I don't know how the existence of a utility such as exit-chroot can be used

Browsing through the code I see that a container is created by faking root and chroot i.e. using unshare ... Obvious now! I'd missed that before however, lack of understanding and was blindly assuming just chroot.

A note about that. Script 'ec-chroot' is where you will see the action, unshare etc.

It is also able to run 'env -i' to clear the environment variables.

It has been mentioned, the convenience of running as 'root' in a container. The user can drag files from the host system into the container, and not have to worry about file ownership and permissions.

This has been one of the big things about Puppy, running as root, and I want to keep that convenience in containers.

I had in the back of my mind that the next step would be to utilize "Linux capabilities" to keep root in a container, but restrict it.

I have done some tests, and it is looking good. Using the 'capsh' utility. Now running containers, and able to selectively dis-empower the 'root' in the container.

Just a quick heads-up post, will post more details soon.

On holiday right now, have my baby laptop with me, external 1TB drive. Running Easy, however, frustrating with the Cherry Trail CPU. Even the 4.14.32 kernel does not work properly.

If I plugin the 1TB drive after bootup, it isn't recognized. If I plug it in before bootup, half the time the kernel crashes at bootup.

I have to buy another laptop! The Asus baby does have one thing in its favour, only 960gm, good for traveling.

[BarryK]

For anyone who is interested, this is a simple introduction to "grass roots" containers, showing how 'capsh' can be used to reduce capabilities of root in a container:

https://ericchiang.github.io/post/conta ... m-scratch/

[rufwoof]

Edit : have subsequently extended the capsh for additional hardening i.e capsh command now looks like

capsh --drop=cap_chown,cap_sys_admin,cap_sys_chroot,
cap_net_admin,cap_net_bind_service,cap_sys_boot,
cap_sys_module,cap_sys_resource,cap_setpcap,cap_setgid,
cap_setuid,cap_sys_rawio,cap_mknod,cap_net_raw,
cap_audit_control,cap_mac_override,cap_mac_admin,
cap_syslog,cap_audit_read,cap_audit_write,cap_fsetid --keep=1 --user=rover --uid=1003 -- -c /bin/sh --


EasyOS Pyro 0.9

Create a sakura container (see attached images and note in particular you have to untick the USER option when creating the container).

Once created a desktop icon will be shown for that new sakura container, click on that to open it and then cd /root and replace the current .bashrc file content with the following

Code: Select all

###################################################
#
# Rufwoof April 2018
#
# /root/.bashrc file for EasyOS Pyro 0.9 container
# set so that it runs a /bin/sh as restricted userid 
# 'rover' under capsh that restricts root from 
# from chown sys_admin and chroot i.e. running exit-chroot
# as root just puts you back to the / folder of the container
#
# Goes some way to thwart hacks such as escaping the chroot
# container and/or elevating privileges 
# 
###################################################

. /etc/profile

#v1.0.5 need to override TERM setting in /etc/profile...
#export TERM=xterm
# ...v2.13 removed.

#export HISTFILESIZE=2000
#export HISTCONTROL=ignoredups
#...v2.13 removed.

#Number   SIG   Meaning
#0   0   On exit from shell
#1   SIGHUP   Clean tidyup
#2   SIGINt   Interrupt
#3   SIGQUIT   Quit
#6   SIGABRT   Abort
#15   SIGTERM   Terminate

trap finish 0 1 2 3 6 15
finish()
{
  exit
}

chmod 700 /root
chmod 000 /usr/sbin/gparted
chmod 000 /sbin/fdisk
# ... etc for any other individual file/folders you wish to restrict

HOME=/home/rover export HOME
DISPLAY=:0 export DISPLAY
XDG_DATA_HOME=/home/rover/.local/share
GTK2_RC_FILES=/home/rover/.gtkrc-2.0
USER=rover
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin
XFINANSDIR=/home/rover/.xfinans
XDG_CONFIG_HOME=/home/rover/.config
XDG_CACHE_HOME=/home/rover/.cache
LOGNAME=rover
cd /home/rover
capsh --drop=cap_chown,cap_sys_admin,cap_sys_chroot --user=rover --uid=1003 -- -c /bin/sh --

# For root level (testing) uncomment the following and comment out the above
#capsh --drop=cap_chown,cap_setuid,cap_sys_admin,cap_sys_chroot  -- -c /bin/sh --
exit

Add rover to the audio group so that you'll hear sounds when playing videos in your browser

Code: Select all

groupadd rover audio

Also navigate to /usr/bin and edit seamonkey to change the code that looks like

Code: Select all

if [ "$NAMEOFUSER" == "spot" ];then
 HOMEDIR="/root/spot/.mozilla/seamonkey"
 NAMEEXE='seamonkey.bin'
else #called as seamonkey or mozilla...
 HOMEDIR="/root/.mozilla/seamonkey"
 NAMEEXE='seamonkey'
fi

to look like

Code: Select all

if [ "$NAMEOFUSER" == "spot" ];then
 HOMEDIR="/root/spot/.mozilla/seamonkey"
 NAMEEXE='seamonkey.bin'
else
  if [ "$NAMEOFUSER" == "rover" ];then
     HOMEDIR="/home/spot/.mozilla/seamonkey"
     NAMEEXE='seamonkey.bin'
  else #called as seamonkey or mozilla...
    HOMEDIR="/root/.mozilla/seamonkey"
    NAMEEXE='seamonkey'
  fi
fi

EDIT : THERE IS A ISSUE WITH THE ORANGE SEAMONKEY SPLASH SCREEN SHOWING FOR A LONG TIME ... SEE NEXT POST

Also edit /etc/profile.d/pup_gtk and change the content from

Code: Select all

export GTK2_RC_FILES=/root/.gtkrc-2.0

to

Code: Select all

export GTK2_RC_FILES=~/.gtkrc-2.0

Exit the container ... and then open the container again by clicking the desktop icon. The first time you opened the container you were running as root, as you will be the second/subsequent times, however root .bashrc is now set to throw you into rover, along with having set up restrictions i.e. dropping root out of certain operations and commands etc.

At the command prompt type seamonkey and press enter. Seamonkey will open and you'll be running it inside a container, running as user 'rover' and having capsh and other file/executable permissions that would make it more difficult for hackers to penetrate your system via seamonkey. Note however that if you save/download files etc then they are saved inside the container (as per any other container).

Once initially set up, if you create a snapshot of that sakura container, you can simply roll back to that whenever you want a nice clean container again (see the 'containers' section in Menu, FileSystem, Easy Version Control).

So now you can run a shell prompt session inside a container... and start seamonkey and be running as rover that has limited permissions. If a known vulnerability in your browser is exploited when visiting a dubious web site then they'll drop to the userid that the browser was running under i.e. rover ... which is a restricted user. They might try and elevate their permissions by using weaknesses in the main filesystem ... and if they do find one and gain root access then they're still locked into the container and where root also has restrictions as what it can do - including being blocked from chroot'ing out of the chroot container.

[rufwoof]

I also commented out /usr/bin/seamonkey MAGICDIR section so it now looks like (you could just delete that code) as otherwise the orange splash screen just hung around for 80 seconds (2 second pauses, 40 iterations of sleep).

Code: Select all

#MAGICDIR="$(ls -1 ${HOMEDIR} | grep 'default$' | tail -n 1)"
#if [ ! -f ${HOMEDIR}/${MAGICDIR}/places.sqlite ];then
# SMSPLASH='yaf-splash -bg orange -fg black -close never -fontsize medium -text "SeaMonkey is starting for the very first time!
#This will take awhile, as SeaMonkey creates setup and cache files in folder ${HOMEDIR}.
#All future startups of SeaMonkey will be much faster.
#
#Technical note:
#SeaMonkey is not usable on PCs with less than 256MB RAM, minimum 512MB recommended.
#
#Please wait..." &'
# 
# echo "#!/bin/sh
#HOMEDIR=${HOMEDIR}
#${SMSPLASH}
# YAFPID=\$!
# CNT=0
# while [ ! -f ${HOMEDIR}/${MAGICDIR}/places.sqlite ];do
#  sleep 2
#  CNT=\`expr \$CNT + 2\`
#  [ \$CNT -gt 40 ] && break
# done
# sleep 2
# pupkill \$YAFPID
# if [ -f /usr/lib/seamonkey/seamonkey ];then
#  ln -snf ../lib/seamonkey/seamonkey /usr/bin/${NAMEEXE}
# else
#  ln -snf ../lib64/seamonkey/seamonkey /usr/bin/${NAMEEXE}
# fi
#" > /tmp/sm-startup-wait-script
# chmod 755 /tmp/sm-startup-wait-script
# /tmp/sm-startup-wait-script &
# 
#fi

[rufwoof]

Should say that the above wont fully mitigate Spectre and Meltdown type vulnerabilities (although it might go a long way as they do require access). Only full virtualisation can achieve that. Browser providers have coded to reduce the risk, however if you leave scripts open even that can be circumvented. Generally have scripts turned off and maybe only turn them on for sites you trust. In SeaMonkey ... Edit, Preferences, Advanced, Scripts and Plugins and untick the Enable Javascript for Browser option.

Personally I tend to leave scripts active as security and functionality are inverse correlated and the web is hard work without javascript being active. EasyOS being able to just rollback easily to a clean version is generally good enough for me as I also keep disconnected backups and generally couldn't care less if what was on my PC was seen by others. I could regret that if hardware had some kind of hack installed ... but only a isolated setup is truly safe. For more important stuff such as online banking I use alternatives.