Fatdog64-720 and 721 Final [11 Jan 2018]

[rufwoof]

Nice to see sshfs-fuse installed by default . Connecting to my local file server (OpenBSD based running on a old single core Celeron PC) and opening a rox window in FD etc. and all looks good/works well.

[rufwoof]

tmux from 700 (here http://distro.ibiblio.org/fatdog/contrib/packages/700/) seems to work OK in 721 - best as I can tell (multiple windows, multiple panes, switching between them ...etc.).

Personally I like a ~/.tmux.conf of ...

Code: Select all

bind-key -n F12 next-window
bind-key -n F11 new-window
set-window-option -g window-status-current-bg red
set-window-option -g window-status-current-fg yellow

unbind C-b
set -g prefix `
bind-key ` send-prefix

That sets a nicer colour for the current window (tab), has F11 add a new window, F12 step between windows, and resets the ctrl-b command key to instead be the backtick (execute) key. You can still type a execute/backtick in say a script, but you just have to press the key twice.

I normally create a launch script something like

Code: Select all

#!/bin/sh
#
# My tmux initialisation script to initialise tmux windows
# 

# start a tmux session, detach
# then send commands to that before reattaching to it
# Note that C-m is carriage return (enter)

# create a tmux session called work, and deattach so we can send keys to it
# Create the first window and load htop into that ...
tmux new -s work -d
tmux rename-window -t work htop
tmux send-keys -t work 'htop' C-m

# Add another tmux window
tmux new-window -t work

# and finally select which window to show first and attach to the tmux work session
tmux select-window -t work:0
tmux attach -t work

Personally I prefer one window per program (and step between them using F12). Others like to have multiple panes in a single window and zoom/unzoom toggle those panes to maximised/restore.

A great thing about tmux is you can start a session - such as a long compile, detatch and then later reattach again - even from another device (anything that can ssh into the server/box). Two or more of you can also ssh into the same box using the same userid and attach to the same tmux session ... so for instance as a form of collaboration setup (all see the same screens and can type into the windows etc.). Yeah I know you can do the same using nohup, &, jobs. fg ... etc. but tmux is lightweight, quick and looks nice.

I like xterm for its ctrl left/middle/right mouse button options, you can for instance full screen the xterm using one of the ctrl-left mouse press actions. mc with the left pane set to tree, right pane set to lynx style (so left/right arrows takes you up/down directories, up/down arrow steps through a directories entries) works well IMO. I like the gotar theme personally.

[rufwoof]

First link on file:///usr/share/doc/faqs/huge-initrd.html points to http://barryk.org/puppylinux/download/release-2.16.htm - but that's a dead link.

I've split out fd64.sfs from initrd and my BIOS based multi-session LiveCD boot time has halved - down from around 5 minutes (power-on to gui desktop), down to around 150 seconds (which includes loading the basesfs into ram)

isolinux.cfg modified to include the basesfs parameter

Code: Select all

label fatdog-multi
linux vmlinuz
initrd initrd
append rootfstype=ramfs basesfs=ram:local savefile=direct:multi:sr0 

[step]

@rufwoof, thanks for sharing your tmux experience. I can't begin to count the times I've started to teach my fingers tmux, and then given up. My main motivation would be to use vim and shells all together in the same terminal window, something tmux is very good at. But I'm so well adjusted to using gvim and tabbed urxvt instead, that my motivation for tmux falters. Eventually, I'll get there.

I built a recent tmux git commit. Attached. I think it's quite different from the 1.9 version that was built for Fatdog 700.

[rufwoof]

Thanks Step. Seems to work great.

Another nice change in .tmux.conf is to remap the pane keys to | for a vertical split and - for a horizontal split. Far better than the " and % defaults IMO.

Code: Select all

# split panes using | and -
bind | split-window -h
bind - split-window -v
unbind '"'
unbind %

Along with the control key mapped to the backtick/execute key its a relatively easy to remember set of backtick - to split horizontally, backtick arrow keys to switch between them, backtick z to zoom/unzoom a pane. At least that comes a lot easier to me to remember/use than the standard default set. A little awkward having to hit backtick twice when you want to add a execute quote in a script, but that soon becomes 'natural'. If you instead map the | to \ then that saves having to hit shift also. Or - and = is also nice for being close to each other (left pinky hitting backtick, right hand used for - = vertical/horizontal splits and arrow keys to flip between panes).

I quite like mc and its internal text editor, easier for editing IMO and works well over ssh links IME. But as ever whatever you're most familiar with is the easier choice.

The PS1 prompt I use is to edit /etc/shinit as per the following snippet

Code: Select all

case $- in                                                                                                    
        *i*)                                                                                                  
                # interactive configurations - prompt, history, etc                                           
                # TERM, USER and LOGNAME is already set by login/su                                           
                PS1="$USER$ "; [ $USER = root ] && PS1="\[\e[34;1m\]Pwd: \[\e[36m\]\w\n\[\e[31;1m\]\u@\h> \[\e
                HISTFILE="$HOME/.history"       # ensure all shells use the same history  

That shows pwd and the current folder (in blue), with the userid and machine as the main prompt below that (red).

Thanks again.

[rufwoof]

The FatDog help for file sharing file:///usr/share/doc/faqs/sharing.html outlines FTP, HTTP and Samba methods. Personally I use yet another alternative i.e. sshfs (or just straight ssh/scp ...etc., which includes the ssh -X ability to run X gui programs/windows (i.e. run a program such as galculator on the remote, see the galculator window on your local desktop)).

For that I have a OpenBSD base system only box, running on a old single core Celeron box, that I can sshfs mount as a local folder (so files can be viewed using rox or whatever). OpenBSD takes just minutes to install (cli based installation process) and its base system is very secure - and also includes X, http, mailserver ....etc. as part of the base system).

In effect I'm (trial) running fatdog (linux) and openbsd as a combined 'system' where fd is the desktop and openbsd stores my most invaluable stuff (data/docs etc.) and where that data is only accessible if you know both the userid and password (making brute force attacks that more difficult). Not even root on the desktop system can access/mount that data without knowing both the appropriate userid and password, and it can be mounted/unmounted on a as needed basis (such as not being mounted whilst also browsing the internet).

I know little about Samba but believe that is better if you desire to share with Windows based systems. FD seems to have Samba shares all ready to go out of the box so conceptually other Window PC's on our local LAN could be linked in (FatDog be used as a form of bridge - have both Samba and sshfs running).

Note how in the following image the desktop system is just a DVD only (FatDog 721 Liveboot multisession DVD). via sshfs however and used disk space on the OpenBSD box shows around 33GB of disk used, leaving around 300GB remaining on that particular OpenBSD box. When not mounted that data can't be seen via port scans, and not even FatDog root can mount it without also knowing the particular link (IP), userid and password, so even if the browser running as spot was hacked ... and the hacker managed to elevate to root via a bug in one of the programs/services being run as root, then if the data wasn't mounted that remains pretty safe from such a compromised session. Running from a read only (write once) LiveCD (DVD) and mostly just shutting down without saving further inhibits a hacker achieving persistence of their breach across reboots. Yet there's considerable flexibility, for instance open up (port forward) the ssh port on the OpenBSD box and it can be accessed from anywhere in the world from most devices (small ssh client programs for smartphones ...etc.). I use a (free) dynamic domain name for that purpose (associates a fixed domain name to a variable IP address).

[rufwoof]

Not being familiar with FD I struggled some to figure out how to change the panel theme. The first was figuring out that the panel is a lxqt panel - which led to the discovery that under /usr/share/lxqt/themes there are two choices. Modifying /root/.config/lxqt/lxqt.conf theme entry to

Code: Select all

theme=23Smokey

from the default ambiance theme did the trick.

To better align the openbox menu theme right click the desktop to show the openbox menu and select the OPENBOX, OPENBOX CONFIGURATION MANAGER choice and on the THEME tag selecting the Onyx-Blue theme is a close match.

[step]

if you're happy with modifying the lxqt theme system-wide, that's the way. Fatdog64 being a multi-user system also let's a single user change his/her theme. This is what I have in my (root's) ~/.config/lxqt/lxqt.conf

Code: Select all

[General]
__userfile__=true
theme=light
icon_theme=Clarity

which shows how to change the theme icons as well.
light is a folder under /usr/share/lxqt/themes
Clarity is a folder under /usr/share/icons, structured similarly to hicolor

[step]

Opera-developer is one of the browsers I use. Occasionally I run into pages that just don't render. I have finally found a work-around. Possibly it could apply to other chromium-based browsers. Simply start opera or chromium from the shell prompt with the prefix TZ=Europe/London. Replace Europe/London with the IANA abbreviation for your timezone. Example:

Code: Select all

# TZ=Europe/London opera-developer

Explanation

By default Fatdog64 sets the system TZ=:/etc/localtime, which works just fine for glibc, but isn't supported by the javascript Intl API TimeZone spec, which wants explicit IANA codes.

A small launcher script that automates the process for Fatdog could be

Code: Select all

#!/bin/dash
tz=`readlink /etc/localtime`
tz=${tz#/usr/share/zoneinfo/}
TZ=$tz exec defaultterm  "$@"

Of course, this work-around applies just to the pages that don't render due to timezone issues. You can check if that's your case by opening the javascript developer console in your browser, reloading the page and checking for javascript error messages about undefined timezone objects.

[rufwoof]

Switched over from using a DVD-R disc to a DVD-RW disc and burnt using pburn. Afterwards it was showing as being a DVD-R and pburn accordingly refused to over-write it. Using PeasyDisc I was able to blank/format the DVD and running pburn to burn the iso again had it showing correctly as a DVD-RW thereafter.

pburn in FatDog 721 is 4.3.6 whereas the latest version of pburn looks to be 4.3.17. There's a whole lot of interrelationships involved with pburn however so given that Fatdog and pburn works well as-is (excepting the above niggle), perhaps best to leave things as they are and just make a mental note of that single issue/workaround.

[rufwoof]

Found the equivalent of Puppy pfix=n ... to skip the last n sessions of liveDVD multisession booting.

Had a problem however. Two prior saves and attempting to ignore the last (setting n to 1) with boot parameters ...

Code: Select all

append rootfstype=ramfs basesfs=ram:device:sr0:/fd64.sfs savefile=direct:multi:sr0:1

i.e. savefile=direct:multi:sr0:1 <<< where that last "1" should indicate the number of prior saves to ignore ... resulted in no save sessions being loaded (screwed up my DVD disc when I rebooted as being a 'new install' it ended up saving that session, fortunately I had a second backup DVD to fall back upon).

[rufwoof]

Edited previous post in a manner that invalidated the former content of this post.

[rufwoof]

Doh! Figured it. I was misinterpreting the parameters. Needs to be

savefile=direct:multi:sr0::1

in order to skip the last save.



I used isomaster (after installing it from gslapt) to edit the isolinux.cfg (open the iso using isomaster and in the bottom panel right mouse click that isolinux.cfg file and select edit), make the edits then File, Save As ... to save to a new iso image file) so that the multisession choice now looks like ...

Code: Select all

label fatdog-multi
linux vmlinuz
initrd initrd
append rootfstype=ramfs basesfs=ram:device:sr0:/fd64.sfs savefile=direct:multi:sr0::0
menu label Fatdog64 with multisession support
text help
Start Fatdog with multisession support for the first optical disc drive.
Upon startup, previous sessions (if any) will be loaded from the disc.
After shutdown, changes will be saved as a new session to the disc.
You need to use DVD+RW drive as the disc media 
(you can use DVD-R or DVD-RW disc's).
Change the zero at the end of savefile=direct:multi:sr0::0 to another
number in order to skip loading that many last saves from being loaded
endtext

The version of PBurn in FD721 does seem to have issues with burning DVD-RW disc's instead burning them as DVD-R. PeasyDisc by comparison seems to work fine (I run fast blank DVD and then DVD format, before burning the iso to the DVD-RW disc setting multi-session DVD options). Good practice IMO to also copy the iso file as a file to the DVD after having burnt the iso image, along with the devX sfs (so you can open the dvd drive in rox and right click, load sfs the devX if/when needed). Finally, tidy your system up and click the desktop save-session icon so all your configuration etc. changes are stored (in event manager I have set the save session interval to 0 (zero), so that it only ever saves whenever the desktop save session icon is clicked).

Also good practice to keep two copies of DVD+RW (repeat of the above) - as a backup.

So far, my trial of running FD on no HDD desktop (DVD only, running FD multisession) is going great. Once booted I sshfs (or ssh/scp ..etc.) a local file server as and when needed (mine's running OpenBSD) to/from which personal data/docs can be stored. That sshfs mount point can be unmounted whenever browsing or doing other internet things so data is isolated, and even if the DVD system is hacked/breached to root level, with the data drive disconnected your data remains safe.

[rufwoof]

video kernel boot parameter ... the faq indicates using video=VGA:800x600 ... format however that doesn't work for me. However using just video=800x600 does. i.e. isolinux.cfg value of

Code: Select all

append video=800x600 rootfstype=ramfs basesfs=ram:device:sr0:/fd64.sfs savefile=direct:multi:sr0::0 

So when I Ctrl-Alt-F3 to a login prompt, login as root (I've previously changed the default woofwoof passwd to something else) ... then the console is much more readable (larger size characters) than the default (small characters).

With control panel, System, Manage Services and gpm enabled/started, then the mouse also works on the console, so you can run mc and use the mouse to navigate around. I also like to run tmux in the console, so as to have multiple windows/tabs and panes (split a screen into separate terminals), and is more colourful than the standard console (I personally prefer the gotar mc theme).

[rufwoof]

Added a user userid using the control panel, set it to autologin, saved session (multisession livecd) and the dvd was no longer bootable (only the last save was on the DVD, everything else was wiped).

Multi-user is 'experimental' in this case the experiment failed. I guess because the new user has limited groups/permissions, missing specific permissions with regard to multisession livecd saving.

[rufwoof]

Booted a liveCD, created a user userid and set autologin to that. Created a fresh DVD and saved to that ... and its now booting directly into X running under user and saving multi-session's OK.

Nice to reduce down all those potential priv-elevation holes that otherwise many programs/services running as root presents (single exploitable bug in any one of them).

I opine differently to the running as root faq comments

http://distro.ibiblio.org/fatdog/web/faqs/login.html

Consider this - lets say you login as your regular non-privileged user ("regular" means the user id you use for day-to-day work, so this is the user id that owns your home directory, owns your data, etc) and run network programs as that user too. This is how typical Linux distros do it. Now lets assume that there is a security hole in the network program that enables a remote attacker to gain access to your system. When a remote attacker manages to do this, he/she will gain access as your regular user id (because this is the user id used to run the network program, remember?).

What can the remote attacker not do? Among other things:

he/she cannot delete operating system files.
he/she cannot read certain operating system passwords.
he/she cannot modify operating system files (e.g. to implant a system-wide keylogger to monitor every user in the system).

Big deal. Lets see what the remote attacker can do (among other things):

he/she can delete your data
he/she can read all of your data, including your passwords, your credit card numbers, your tax returns, etc
he/she can modify and install programs executed by you at every startup - such as installing keylogger to monitor everything you type.

Thus - what exactly does logging in as non-privileged user protect? What is more important and irreplaceable - your data, or the operating system files?

If you generally run as user, but store your important data/docs under root, then its trivial for you to access that data, but a remote attacker in securing user access is, via the root permissions, obstructed from accessing that data. It's then a issue of whether they can secure privilege elevation (to root). Any bug in a program is a potential security bug if it can be exploited, the more code and programs the greater the chance of bugs. Reducing down the number of programs/services running as root reduces down the potential for privilege elevation to root. It's a relatively small price to better protect that data in having to enter the root password in order to do certain things, even more so if you run a console root session from which you perform root type actions and have the user gui/X session running in another console (ctrl-alt-fn flip between them).

The comments in the faq are just negatives - "both user and root can delete data then pointless running as user as your data is insecure either way" type negatives. When however data is root owned and root is better protected then there are differences - proportional to how easy/difficult it is to achieve root permissions.

Personally I'm quite content to ctrl-alt-fn between root and user in order to run/do things, each to their own. I'm not saying the conventional 'puppy as root' way is bad, rather just attempting to highlight one alternative. In practice its generally not cost effective for a dark-hat to target a single user, high risks for often very low if any reward. Excepting of course high profile/net-worth individuals. Better (for them) alternative targets being the more preferred (potential high rewards for relatively low risk).

[dr. Dan]

@ step

if you're happy with modifying the lxqt theme system-wide, that's the way. Fatdog64 being a multi-user system also let's a single user change his/her theme. This is what I have in my (root's) ~/.config/lxqt/lxqt.conf

Code: Select all

[General]
__userfile__=true
theme=light
icon_theme=Clarity

which shows how to change the theme icons as well.
light is a folder under /usr/share/lxqt/themes
Clarity is a folder under /usr/share/icons, structured similarly to hicolor

With so much else handled within the control panel, I wonder why panel theming is not?
Not knowing any better, I just modified the ambiance theme to my liking, winding up rather like the 23Smokey theme - a nice unintended learning experience.
Dan

[dr. Dan]

Considering rufwoof's most recent post, would using a non-root account and using spot for all online activities be even more secure? I'm asking out of curiosity.
Dan

[Anniekin]

I opine differently to the running as root faq comments

One of the advantages in fatdog is the running of only internet apps as non privileged users, because that is where attackers come from, seems like the best of both worlds this way

What do you think?

[rufwoof]

would using a non-root account and using spot for all online activities be even more secure?

What OpenBSD do is use root for the bare necessities, starting other programs/services using dedicated userid's for each, where the permissions for each program/service are refined so as to be able to do/use what they need, nothing more. So conceptually yes. In addition to that they have what they call Pledge - where each program has its boundaries set as to what it is expected to do/use, nothing more. The next release also includes something called unveil, which extends that to memory permissions. There's also a plethora of other security measures - they randomise the kernel, libs, pid's ...etc., encrypt and randomise swap, and W^X (write XOR execute (memory separation)) etc. There are also penetration detection measures (daily checks of the system, that you can relatively easily extended to use something like mtree - that checksums all bins/sbins/libs ...etc. files, so any installed trojan's likely get flagged. For all of the recent predictive bugs (security risks) OBSD are simply turning off hyperthreading, apparently with negligible differences in speeds for the average user. Primarily for servers the security of OBSD is good, for a average single user desktop perhaps way overkill - but nice. The downside is that it is slower (but not uncomfortably so) and limiting (they don't include the likes of BLOBS - other peoples code without visibility of the source - so the likes of nvidia tends not to work well under OBSD etc.). They focus on cutting down/securing code as less code tends to mean fewer bugs (potential security holes) and ensuring things are coded 'properly' (base system as a whole is quite broad, and security audited as a collective whole). But that means older software, less choice (ffs (fast file system (now very old) instead of zfs of whatever.

No system is truly secure. Its more a question of how high/low you set your bar. The height is inversely proportional to flexibility/usage. For the average single desktop user primarily personal data is the most invaluable. As noted in the FatDog FAQ you might have things set up such that both user and root has access to that data, in which case it doesn't really matter if you run as user or root. If you separate it however, set your important data to be owned by root, and predominately run things as user, then the security bar is raised higher.

Fundamentally one method a dark-hat might employ to try to hack a system is to get a root level next instruction pointer to point to something (memory/file) that the dark-hat had permission to write. With all the programs/libs typically involved, a hacker doing X and Y to make any one root owned process do something it wasn't intended to do (bug) in a manner such that its subsequent execution becomes under their control (pretty much game over) is difficult to fight. The less that runs as root, the lower their chances. But as I said before, the desire for a dark hat to expend time and effort (along with risk exposure) targeting a single user desktop system is very low, Bigger fish swim elsewhere. An exception are the script kiddies, who might take delight in penetrating a system and perhaps wiping everything - just for 'fun'. Much of security, which is big business, is about potentials, if X and Y then potentially cache could be opened up to a dark hat where that cache could potentially contain sensitive data such as a password. Only where those potentials are relatively easily and consistently exploitable across a wide base of systems might those actually be employed in practice, and often those holes tend to be filled quickly (a primary reason why many suggest updating your programs/system often). A downside of Open is that known bugs, the code and risks - are openly published, making it relatively trivial for script kiddies (detect a browser visiting their web site or one of their adverts inserted into someone else's web site, where that browser version has a known security bug that if you do x, y and z opens up remote access to the local system). Typically disabling the likes of java, spoofing your browser useragent ...etc. are methods to reduce such risk. NoScript and a useragent spoofer add-ons go a long way to reduce risk, as does having a PuppyAd-Block or Ublock-Origin - that redirects dubious IP's references to nowhere. As does not running a browser as root (whch FatDog does by default).