Fatdog64-720 and 721 Final [11 Jan 2018]
Having used cwm, xlunch and skippy-xd for real activities quite intensively, whilst its nice/different there are some niggles i.e. its not as clean/pure as the standard Fatdog desktop. For instance when you reveal skippy-xd and middle mouse to close a window, it sometimes takes 2 clicks. In other cases the screen doesn't correctly repaint (or correctly show windows in skippy-xd i.e. not fully painted) ...etc. Nothing major, but clearly not clean and indicative of some bugs being present. Enough to make me revert back to the standard/default Fatdog desktop.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
Rather than having a Fatdog expanded to include rsshfs ...etc. perhaps it should be a separate version ... maybe just cli/tmux only that boots as a liveCD/mmc/sd-with-ro-toggled 'server' ... to act as a ssh proxy along with maybe http server, ftp server, web cam image server, puppy-phone ...etc type functions. Fundamentally not much more than busybox+ and in Fatdog just add the necessary parts to rsshfs to that.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
Changing rsshfs mounting to use data server user userid (on a box that is behind a firewall with no port forwarding/open ports), to my desktop Fatdog system - using spot userid ... i.e. mount data servers /DATA folder to /home/spot/data ... works fine (after ssh-keygen and creating a /home/spot/.ssh/authorized_keys with the data servers userid user public ssh key).
A usage problem however is that not even Fatdog root can see that /home/spot/data mounted folder content, you have to su spot and then run rox (or whatever) to view those files.
Noticed that spot can su (not particular good) into root so that's a present workaround, however more ideally spot should be more isolated, (no access to /dev/fb0, not able to su into root).
Local access however isn't that much of a issue i.e. Fatdog root rox not being able to view /home/spot/data (data servers content), as conceptually that would be for remote access to the data servers /DATA folder content. If Fatdog (desktop) has ssh port forwarded/open, then another remote Fatdog boot (laptop) could sshfs mount the home based desktop fatdogs /home/spot/data folder logging in as spot but using root ... which in turn is a mount point reflecting the data servers /DATA folder content.
i.e. assuming 'laptop' running fatdog is remote, 'desktop' running fatdog is at home, server (in my case running openbsd) is also at home, where 'desktop' has ssh port open, openbsd has ssh blocked - and where openbsd has reverse sshfs mounted its /DATA folder to 'desktop' /data folder, then the remote 'laptop' fatdog running as root can
and provided the ssh-keygen's are appropriately set that will have root on the 'laptop' seeing the openbsd's /DATA folder content. 'Desktop' fatdog has in effect become the ssh proxy server for (remote) 'laptop'. And in a manner where the userid's involved are less critical (restricted user on openbsd (data server), spot on 'desktop' (ssh proxy).
Desktop fatdog would need /etc/eztables.cfg settings of something likefor remote ssh access to the desktop (why eztables isn't set as auto started in fatdog ??? i.e. you need to enable it at startup in fatdog control panel).
Open ssh server ports do tend to rapidly be blitzed with attack attempts, adding rules to drop repeated attempts from single IP's helps.
Another consideration to keep in mind is that file transfers over ssh aren't quick. Which can be further hampered by dual speed ISP services. My download speeds for instance are around a factor of 20 times quicker than upload speeds, 100Mb download, 5Mb upload type values IIRC. Which would mean a remote laptop system transferring files to/from the data server could see seemingly slow speeds for such transfers. For general use however, opening/saving documents etc. the speeds are generally acceptable.
A usage problem however is that not even Fatdog root can see that /home/spot/data mounted folder content, you have to su spot and then run rox (or whatever) to view those files.
Noticed that spot can su (not particular good) into root so that's a present workaround, however more ideally spot should be more isolated, (no access to /dev/fb0, not able to su into root).
Local access however isn't that much of a issue i.e. Fatdog root rox not being able to view /home/spot/data (data servers content), as conceptually that would be for remote access to the data servers /DATA folder content. If Fatdog (desktop) has ssh port forwarded/open, then another remote Fatdog boot (laptop) could sshfs mount the home based desktop fatdogs /home/spot/data folder logging in as spot but using root ... which in turn is a mount point reflecting the data servers /DATA folder content.
i.e. assuming 'laptop' running fatdog is remote, 'desktop' running fatdog is at home, server (in my case running openbsd) is also at home, where 'desktop' has ssh port open, openbsd has ssh blocked - and where openbsd has reverse sshfs mounted its /DATA folder to 'desktop' /data folder, then the remote 'laptop' fatdog running as root can
Code: Select all
sshfs spot@IP-of-home-desktop-fatdog:/home/spot/data /DATA
Desktop fatdog would need /etc/eztables.cfg settings of something like
Code: Select all
# Chain for preventing SSH brute-force attacks.
# Permits 10 new connections within 5 minutes from a single host then drops
# incoming connections from that host. Beyond a burst of 100 connections we
# log at up 1 attempt per second to prevent filling of logs.
-N SSHBRUTE
-A SSHBRUTE -m recent --name SSH --set
-A SSHBRUTE -m recent --name SSH --update --seconds 300 --hitcount 10 -m limit --limit 1/second --limit-burst 100 -j LOG --log-prefix "iptables[SSH-brute]: "
-A SSHBRUTE -m recent --name SSH --update --seconds 300 --hitcount 10 -j DROP
-A SSHBRUTE -j ACCEPT
# Accept worldwide access to SSH and use SSHBRUTE chain for preventing
# brute-force attacks.
-A INPUT -p tcp --dport 22 --syn -m conntrack --ctstate NEW -j SSHBRUTE
Open ssh server ports do tend to rapidly be blitzed with attack attempts, adding rules to drop repeated attempts from single IP's helps.
Another consideration to keep in mind is that file transfers over ssh aren't quick. Which can be further hampered by dual speed ISP services. My download speeds for instance are around a factor of 20 times quicker than upload speeds, 100Mb download, 5Mb upload type values IIRC. Which would mean a remote laptop system transferring files to/from the data server could see seemingly slow speeds for such transfers. For general use however, opening/saving documents etc. the speeds are generally acceptable.
Last edited by rufwoof on Sun 09 Sep 2018, 11:41, edited 3 times in total.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
Hmm! In Fatdog, su is a busybox login link. How can you restrict access to that from spot? I suspect busybox login should be removed and replaced with a 'proper' version/binary. Denying spot su would seem a wise security precaution/change.
EDIT : Ahh! Just discovered you can chmod go-wrx /bin/su that blocks spot from su'ing (brute force dictionary attacks to identify the root password).
EDIT : Ahh! Just discovered you can chmod go-wrx /bin/su that blocks spot from su'ing (brute force dictionary attacks to identify the root password).
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
fuguita openbsd livecd as a data server for fatdog
Downloaded a OpenBSD Fuguita liveCD iso image from http://fuguita.org/index.php?FuguIta and burnt that to a DVD. As a alternative you could build your own.
The boot process is self explanatory, mostly requiring pressing Enter other than entering a domain name choice (I just used "cd"), localisation (I used "uk") and a root password (entered twice). Oh, and having to enter 0 to select the 'Normal boot' choice.
With Fatdog running on another PC (192.168.1.4 local LAN IP address), I adjusted that Fatdogs /etc/ssh/sshd_config to look like :(not sure about needing all of those I've just copied my current content as-is), and then use FatDog Control Panel, Manage Services to stop and restart sshd (so the changes come into effect).
I also made a folder /data to use as a mount point
Back on the Fuguita (OpenBSD) box, run ... (I put the code into a script with a #!/bin/sh first line, made the script executable and ran that)and that mounts /root on the Fuguita/OpenBSD box to /data on Fatdog (change the folders and root@root@192.168.1.4 as appropriate/needed). That will just sit there keeping the connection alive until you ctrl-c exit when the link will drop. If you put the script into the background then you can drop the link by running or suchlike from the OpenBSD box.
Mounting stuff in OpenBSD typically involves running sysctl hw.disknames to get a clue about what name a local HDD might have, usually indicates something like sd0 or wd0. Having identified the name you can inspect how that disk is sliced/partitioned using disklabel wd0 (or whatever disk name identified earlier). For my OpenBSD HDD installed system for instance slice/partition k is where my user userid files are so I mounted that using mkdir mp;mount /dev/wd0k mp
For sd/mmc cards (or USB's) you can usually get the name using dmesg | grep mmc or suchlike and disklabel ... mount etc in a similar manner.
With the above setup you might opt to only mount rw devices to the OpenBSD box, which by default is secure. But then share (reverse sshfs mount) any of those folders to a Fatdog mountpoint, but where Fatdog can't ssh into the OpenBSD box. i.e. selectively pick which folders/data you potentially put at risk that Fatdog can use, and if a hacker gains remote control over Fatdog they are limited to what data they can see/damage. I ran the above using a Fatdog liveCD boot also.
Running liveCD's (ro media) with your data isolated/more secure, the likes of ransomware attacks have finite potential, especially if you keep regular backups of your fatdog shared folder(s) as copies in other OpenBSD folders - that aren't accessible to Fatdog. Would also be wise however to also periodically make/keep disconnected/off-site copies of those backups.
PS : If you do open up your main firewall/router to allow ssh access from the WAN to your home fatdog system (perhaps to sshfs mount your home fatdogs /data folder i.e. openbsd folder content), then don't forget to enable eztables (firewall) and perhaps add rules such as outlined in http://murga-linux.com/puppy/viewtopic. ... 27#1004027
The boot process is self explanatory, mostly requiring pressing Enter other than entering a domain name choice (I just used "cd"), localisation (I used "uk") and a root password (entered twice). Oh, and having to enter 0 to select the 'Normal boot' choice.
With Fatdog running on another PC (192.168.1.4 local LAN IP address), I adjusted that Fatdogs /etc/ssh/sshd_config to look like :
Code: Select all
PermitRootLogin yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication yes
TCPKeepAlive yes
UsePrivilegeSeparation sandbox
ClientAliveInterval 60
ClientAliveCountMax 10000
Subsystem sftp /usr/libexec/sftp-server
I also made a folder /data to use as a mount point
Back on the Fuguita (OpenBSD) box, run ... (I put the code into a script with a #!/bin/sh first line, made the script executable and ran that)
Code: Select all
fifo=/tmp/rsshfs-$$
rm -f "$fifo"
mkfifo -m600 "$fifo" &&
< "$fifo" /usr/libexec/sftp-server |
ssh root@192.168.1.4 sshfs -o slave :/root /data '' > "$fifo"
rm "$fifo"
Code: Select all
ssh 192.168.1.4 fusermount -u /data
Mounting stuff in OpenBSD typically involves running sysctl hw.disknames to get a clue about what name a local HDD might have, usually indicates something like sd0 or wd0. Having identified the name you can inspect how that disk is sliced/partitioned using disklabel wd0 (or whatever disk name identified earlier). For my OpenBSD HDD installed system for instance slice/partition k is where my user userid files are so I mounted that using mkdir mp;mount /dev/wd0k mp
For sd/mmc cards (or USB's) you can usually get the name using dmesg | grep mmc or suchlike and disklabel ... mount etc in a similar manner.
With the above setup you might opt to only mount rw devices to the OpenBSD box, which by default is secure. But then share (reverse sshfs mount) any of those folders to a Fatdog mountpoint, but where Fatdog can't ssh into the OpenBSD box. i.e. selectively pick which folders/data you potentially put at risk that Fatdog can use, and if a hacker gains remote control over Fatdog they are limited to what data they can see/damage. I ran the above using a Fatdog liveCD boot also.
Running liveCD's (ro media) with your data isolated/more secure, the likes of ransomware attacks have finite potential, especially if you keep regular backups of your fatdog shared folder(s) as copies in other OpenBSD folders - that aren't accessible to Fatdog. Would also be wise however to also periodically make/keep disconnected/off-site copies of those backups.
PS : If you do open up your main firewall/router to allow ssh access from the WAN to your home fatdog system (perhaps to sshfs mount your home fatdogs /data folder i.e. openbsd folder content), then don't forget to enable eztables (firewall) and perhaps add rules such as outlined in http://murga-linux.com/puppy/viewtopic. ... 27#1004027
Last edited by rufwoof on Sun 09 Sep 2018, 11:41, edited 1 time in total.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
243MB FuguIta Live OpenBSD iso image (amd64) with rsshfs script added (into /sysmedia folder) (243MB)
Create a empty /data folder in Fatdog. Unzip the iso (gzip -d command) and burn the iso, boot it, make a note of your Fatdog IP and in Fuguita/OpenBSD run the rsshfs script passing it your Fatdog IP e.g.
That will just sit there, having (hopefully) mounted its /root/shared folder to Fatdog /data mountpoint.
On OpenBSD switch to another console (ctrl-alt-F2) and cd /root/shared and mount a HDD folder ...etc and that will be reflected through to Fatdogs /data folder (mount point).
sshd needs to be running in fatdog and if you've the firewall on (eztables) then you'll need to allow ssh through (see earlier postings).
Likely if unfamilar with OpenBSD you'll have to read up about how to identify and mount things under OpenBSD (also partially outlined in earlier posts). Here's a starter for mounting a USB https://www.cyberciti.biz/faq/openbsd-m ... -harddisk/
Fatdog /etc/ssh/sshd_config
Fatdog /etc/eztables/eztables.cfg
Fuguita /sysmedia/rsshfs
PS : there is a option to
Create a empty /data folder in Fatdog. Unzip the iso (gzip -d command) and burn the iso, boot it, make a note of your Fatdog IP and in Fuguita/OpenBSD run the rsshfs script passing it your Fatdog IP e.g.
Code: Select all
cd /sysmedia
./rsshfs 192.168.1.4
On OpenBSD switch to another console (ctrl-alt-F2) and cd /root/shared and mount a HDD folder ...etc and that will be reflected through to Fatdogs /data folder (mount point).
sshd needs to be running in fatdog and if you've the firewall on (eztables) then you'll need to allow ssh through (see earlier postings).
Likely if unfamilar with OpenBSD you'll have to read up about how to identify and mount things under OpenBSD (also partially outlined in earlier posts). Here's a starter for mounting a USB https://www.cyberciti.biz/faq/openbsd-m ... -harddisk/
Fatdog /etc/ssh/sshd_config
Code: Select all
PermitRootLogin yes
PasswordAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
TCPKeepAlive yes
ClientAliveInterval 60
ClientAliveCountMax 10000
Code: Select all
ENABLE_SYSLOG=1
DENY_SSH_BF=1
DENY_SSH_BF_IP="$DEFAULT_IF"
DENY_SSH_BF_PORT=22
GOOGLE_DNS1=8.8.8.8
GOOGLE_DNS2=8.8.4.4
DNS_SERVERS="
$GOOGLE_DNS1
$GOOGLE_DNS2
"
WEB="
80/tcp
443/tcp
"
DNS="
53/udp
53/tcp
"
NTP="
123/udp
"
SSH="
22/tcp
"
BASIC_SERVICES="
$WEB
$DNS
$NTP
$SSH
"
APPSERVER1=192.168.123.2
allow_in any $eth0 any "$SSH"
allow_out any any any "$BASIC_SERVICES"
allow_icmp any any
# Chain for preventing SSH brute-force attacks.
# Permits 10 new connections within 5 minutes from a single host then drops
# incoming connections from that host. Beyond a burst of 100 connections we
# log at up 1 attempt per second to prevent filling of logs.
-N SSHBRUTE
-A SSHBRUTE -m recent --name SSH --set
-A SSHBRUTE -m recent --name SSH --update --seconds 300 --hitcount 10 -m limit --limit 1/second --limit-burst 100 -j LOG --log-prefix "iptables[SSH-brute]: "
-A SSHBRUTE -m recent --name SSH --update --seconds 300 --hitcount 10 -j DROP
-A SSHBRUTE -j ACCEPT
# Accept worldwide access to SSH and use SSHBRUTE chain for preventing
# brute-force attacks.
-A INPUT -p tcp --dport 22 --syn -m conntrack --ctstate NEW -j SSHBRUTE
Code: Select all
#!/bin/sh
#
# Rufwoof September 2018
#
# OpenBSD LiveCD boot script to mount a local folder /root/shared to a remote /data mountpoint
# using reverse sshfs
# Once mounted you can mount HDD folder(s) to /root/shared on the OpenBSD box so that they
# are accessible from the remote machines /data folder
#
if [ -z $1 ]; then
echo "Usage rsshfs <IP>"
echo
echo " Reverse sshfs mounts local folder /root/shared as a mount point /data on <IP>"
echo " remote machines /data folder must already exist and be empty"
exit
fi
if [ ! -d /root/shared ]; then
mkdir /root/shared
fi
if [ ! -d /root/shared ]; then
echo "Unable to find/create /root/shared"
exit
fi
fifo=/tmp/rsshfs-$$
rm -f "$fifo"
mkfifo -m600 "$fifo" &&
< "$fifo" /usr/libexec/sftp-server |
ssh root@$1 sshfs -o slave :/root/shared /data '' > "$fifo"
rm "$fifo"
(see http://fuguita.org/index.php?FuguIta%2FBBS%2F7#h328b23e)5. optional: If you made a directory called "livecd-config" on any FFS partition, you can save all your files, installed packages, etc on Running FuguIta, then you can load them at next boot.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
mplayer complains of libbluray
Hello. Trying to get mplayer from Gslapt:
-- clicked update, mplayer appears on search;
-- libbluray was already installed; (perhaps it's a version thing?)
-- mplayer-static has the same problem (which is strange)
symptom:
Any help appreciated.
-- clicked update, mplayer appears on search;
-- libbluray was already installed; (perhaps it's a version thing?)
-- mplayer-static has the same problem (which is strange)
symptom:
Code: Select all
# mplayer
mplayer: error while loading shared libraries: libbluray.so.1: cannot open shared object file: No such file or directory
Open a terminal and enter the commands ...
Code: Select all
cd /usr/lib64
ln -s libbluray.so.2.0.1 libbluray.so.1
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
I have downloaded Thunderbird60.0 from mozilla and created a package for Fatdog64-721 which installed without problem
I used a thunderbird.desktop file from an earlier version, setup run-as-spot, created /usr/bin symlink, etc, and everything seems to be working OK when clicking on 'thunderbird.desktop"
The only problem is the desktop.thunderbird icon is a generic binary-looking icon. Where can I find a thunderbird '.png' file and where do I put it so that it shows up on the desktop associated with desktop.thunderbird?
I used a thunderbird.desktop file from an earlier version, setup run-as-spot, created /usr/bin symlink, etc, and everything seems to be working OK when clicking on 'thunderbird.desktop"
The only problem is the desktop.thunderbird icon is a generic binary-looking icon. Where can I find a thunderbird '.png' file and where do I put it so that it shows up on the desktop associated with desktop.thunderbird?
Just search for thunderbird.png in google. https://goo.gl/images/HDzPUheowens2 wrote:I have downloaded Thunderbird60.0 from mozilla and created a package for Fatdog64-721 which installed without problem
I used a thunderbird.desktop file from an earlier version, setup run-as-spot, created /usr/bin symlink, etc, and everything seems to be working OK when clicking on 'thunderbird.desktop"
The only problem is the desktop.thunderbird icon is a generic binary-looking icon. Where can I find a thunderbird '.png' file and where do I put it so that it shows up on the desktop associated with desktop.thunderbird?
Place it in /usr/share/pixmaps
Thanks
@rufwoof
Thanks! it works. As perhaps compensation, I'd suggest you check out the "video=" boot option, since it accept an interface parameter before the resolution, like DVI, HDMI and whatnot.. something that confused me, as it used to refer to drivers such as uvesafb and the like (as per the Kernel documentation, which u also linked to). You may need to see dmesg for auto-detecting that, for example, Fatdog docs (or was it vanilla puppy?) state a particular kind of DVI is more common and most likely what I needed but it turned out to be different here.
btw, really liked your experiments. Many of which I've been also doing for quite some time now, if not as elegantly , as necessity forced my time and effort to be redirected there. Another thing to keep in mind besides the compromised box stance, is that anything you set up to be able to do in software, an adversary would also be able to do, once compromised. You need a "Hardware Kill Switch" for that, eject in this case :-} but once one realize that fact, removing a usb stick would do just as well. (tho Eject is much easier to do remotely )
In other words, using a CD/DVD-R sounds great in principle, until you allow software to bypass its ROM nature. Tinycore for instance, allows a file/flag to be placed on the boot media to enable unmounting it after booting (maybe something to consider, if adding that to FD64)
Regarding X, if you look at the screenshot you took showing the CLI parameters for running processes, you see that, in FD, X is run with "-bs --nolisten", the latter for both tcp and local. Wouldn't that prevent most attacks, at least remotely? (disregarding gained access to spot, which would mean worse problems than that I guess)
Well, X is best avoided anyways.
@All
Really glad to hear about FatDog 800 at least being considered! \o/
If I may chip in, the only thing left for it to become my Ultimate Desktop Distro(tm) is to have Blender working with accelerated Rendering. AMD, perhaps surprisingly (hehe), done its part at least on the Blender Cycles* part. On the other hand AMDGPU seems to be having an uphill (upstream?:D) battle making its way into the Kernel, yet I know I can run OpenCL on this hardware, did back then with the fglrx driver. So I'm hopeful, but now people seem to be having lots of problems with the new stuff. openBSD btw likes AMD way more than it likes nVidia, so I'll probably be trying that soon.
Onwards!
* https://www.blendernation.com/2017/04/1 ... -par-cuda/
Thanks! it works. As perhaps compensation, I'd suggest you check out the "video=" boot option, since it accept an interface parameter before the resolution, like DVI, HDMI and whatnot.. something that confused me, as it used to refer to drivers such as uvesafb and the like (as per the Kernel documentation, which u also linked to). You may need to see dmesg for auto-detecting that, for example, Fatdog docs (or was it vanilla puppy?) state a particular kind of DVI is more common and most likely what I needed but it turned out to be different here.
btw, really liked your experiments. Many of which I've been also doing for quite some time now, if not as elegantly , as necessity forced my time and effort to be redirected there. Another thing to keep in mind besides the compromised box stance, is that anything you set up to be able to do in software, an adversary would also be able to do, once compromised. You need a "Hardware Kill Switch" for that, eject in this case :-} but once one realize that fact, removing a usb stick would do just as well. (tho Eject is much easier to do remotely )
In other words, using a CD/DVD-R sounds great in principle, until you allow software to bypass its ROM nature. Tinycore for instance, allows a file/flag to be placed on the boot media to enable unmounting it after booting (maybe something to consider, if adding that to FD64)
Regarding X, if you look at the screenshot you took showing the CLI parameters for running processes, you see that, in FD, X is run with "-bs --nolisten", the latter for both tcp and local. Wouldn't that prevent most attacks, at least remotely? (disregarding gained access to spot, which would mean worse problems than that I guess)
Well, X is best avoided anyways.
@All
Really glad to hear about FatDog 800 at least being considered! \o/
If I may chip in, the only thing left for it to become my Ultimate Desktop Distro(tm) is to have Blender working with accelerated Rendering. AMD, perhaps surprisingly (hehe), done its part at least on the Blender Cycles* part. On the other hand AMDGPU seems to be having an uphill (upstream?:D) battle making its way into the Kernel, yet I know I can run OpenCL on this hardware, did back then with the fglrx driver. So I'm hopeful, but now people seem to be having lots of problems with the new stuff. openBSD btw likes AMD way more than it likes nVidia, so I'll probably be trying that soon.
Onwards!
* https://www.blendernation.com/2017/04/1 ... -par-cuda/
Hello.
I'd like to point out that the nluug.nl mirror link on the web page doesn't work for me, here is the right one I believe :
http://ftp.nluug.nl/os/Linux/distr/fatdog/
I'd like to point out that the nluug.nl mirror link on the web page doesn't work for me, here is the right one I believe :
http://ftp.nluug.nl/os/Linux/distr/fatdog/
I just last night updated to the latest version of fatdog from either 710 or 720 beta (not sure). I think 710 beta. Anyway, I kept the same save file. To get firefox to work I had to change the home director of spot to the new location in /etc/passwd. The update the base sfs script didn't work so I replaced initrd with the orginal one I had from the 721 iso.
Anyway, One thing that I noticed is there is no menu option to exit the xserver into the shell. Being able to exit the xserver is helpful when running cpu intensive applications like freenet. So anyway, how do I exit the xserver to the shell in fatdog 721????
Anyway, One thing that I noticed is there is no menu option to exit the xserver into the shell. Being able to exit the xserver is helpful when running cpu intensive applications like freenet. So anyway, how do I exit the xserver to the shell in fatdog 721????
Last edited by s243a on Fri 28 Sep 2018, 17:11, edited 2 times in total.
lol, brainfart! The funny thing is I probably did exactly that yesterday but today I was too focused on finding it on the menus. Thankyouznekk wrote:On Fatdog64 721, you should be able to use the "ctrl+alt+backspace" shortcut, then startx to get back in.
Edit
cntrl-alt-backspace isn't working for me now. Maybe due to my system load being to high. Is there something I can type in the shell instead? Come to think of it It might have not worked yesterday either.
Yes:s243a wrote:Is there something I can type in the shell instead?
Code: Select all
wmexit terminal
Code: Select all
DONT_ASK=true wmexit terminal
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]