FrankenEavesdropping

For discussions about security.
Post Reply
Message
Author
s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

FrankenEavesdropping

#1 Post by s243a »

Apparently the last Franken thread was disassembled into the lifeless ones and zeros from which it was created. It was an abomination of saucy spice which peered into the naked pup and asked, "How can we make puppy more secure and should we?".

The monster flailed and growled and the people declared it's dire rants as baseless rantings, an abomination speaking in tounges. The pitchforks came out and destroyed the creation but what did we learn from this monster?

Let's recap.

roofwoof, suggested that there isn't sufficient separation of privileges between spot and root on both puppies and dogs and even going as far as to suggest that it might not be that hard to break out of Barryk's easy containers. The claim was that spot could Eavesdrop on both the root terminal and the xserver. He also claimed that fatdog64 best handled this privilege separation.

To better understand this, "s243a" noted that on stretchdog, user "puppy" couldn't run GUI aps without disabling x security via "xhost +" or via some more complicated procedure that would make it difficult for new users to run GUI aps without root permissions.

Wiak responded to s243a by saying that "xhost +" was a quick and dirty way to achieve this but the proper way to achieve it was either via xdm or ssh forwarding. He also noted that in general puppy connects to the xserver insecurely.

Anyway, no info was given about the attacks that would escalate privileges suggested by roofwoof but lets follow roofwoofs critiques further (baseless or not) and look at how fatdog64 handles running a browser as spot and then we can look at how a typical puppy does it and compare the strengths and weaknesses of each approach.

If you look at the desktop file for firefox in fatdog64 you see the following lines of code to start the application:
/usr/share/firefox/firefox.desktop

Code: Select all

...
Exec=firefox-spot %U
...
we can locate this file by typing

Code: Select all

# which firefox-spot
/usr/bin/firefox-spot
Opening the file:

Code: Select all

#!/bin/dash
exec /usr/bin/run-as-spot /usr/bin/firefox "$@"
Now we see the workhorse here:

Code: Select all

/usr/bin/run-as-spot
Here is some of this script:

Code: Select all

    [ -z "$XAUTHORITY" ] && XAUTHORITY=/root/.Xauthority
    [ -e "$XAUTHORITY" ] && cp $XAUTHORITY $SPOT_HOME/.Xauthority &&
    chown spot:spot $SPOT_HOME/.Xauthority &&
    export XAUTHORITY=$SPOT_HOME/.Xauthority  
   
    export XDG_CONFIG_HOME=$SPOT_HOME/.config
    export XDG_CACHE_HOME=$SPOT_HOME/.cache
    export XDG_DATA_HOME=$SPOT_HOME/.local/share
    mkdir -p $XDG_DATA_HOME; chown spot:spot $XDG_DATA_HOME
    export FATDOG_STATE_DIR=$SPOT_HOME/.fatdog
 
    set -- "$(eval_safe_quote "$@")"
 
    exec su spot -s /bin/dash -c '
https://pastebin.com/sxLd1tgg

The full script I copied to the above link. Note, that I'm not sure this is the latest since I kept the same save file when I upgraded. It isn't obvious to me from the above that xdm is being used as wiak suggested and not knowing enough about xsecuirty I won't say whether or not the above way is a good way to run applications as spot. Rather I'll leave it to other users to comment.

As a side note the above approach requires that the user have a home directory, so if I created a system user called tor-browser the above approach wouldn't work. One might want to create a system user called tor-browser if they wanted to use iptables to restrict the network traffic of said browser to only connect through either tor or a proxy. A proxy may be used instead of tor if they wanted to prevent the tor browser from connecting to clearnet sites.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#2 Post by rufwoof »

...
Last edited by rufwoof on Sat 29 Sep 2018, 06:01, 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]

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#3 Post by s243a »

rufwoof wrote:
"should we?".
IMO - No.
That's a very ironic position from you.

BTW please try to avoid the diggs against Fred or this thread will likely also go poof!

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#4 Post by s243a »

rufwoof wrote:...Fatdog install permits spot wr access to /dev/fb0 such that spot could see whatever root might be doing on the framebuffer console. Best stance is to assume that elevation to root is trivial. And that's before the likes of individuals such as Fred having root access via his personal repo that is active by default in all (bar Fatdog) Dogs; Or you run the likes of vlc as root when vlc intentionally strive to prevent that security hole.
"should we?".
IMO - No.
BTW if you think the permissions of spot are wrong then perhaps you could provide a script that will create a more secure user than spot and/or a script that fixes any permission issues that you have with spot.

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#5 Post by fredx181 »

s243a wrote:Here is some of this script:
Code:

[ -z "$XAUTHORITY" ] && XAUTHORITY=/root/.Xauthority
[ -e "$XAUTHORITY" ] && cp $XAUTHORITY $SPOT_HOME/.Xauthority &&
chown spot:spot $SPOT_HOME/.Xauthority &&
export XAUTHORITY=$SPOT_HOME/.Xauthority

export XDG_CONFIG_HOME=$SPOT_HOME/.config
export XDG_CACHE_HOME=$SPOT_HOME/.cache
export XDG_DATA_HOME=$SPOT_HOME/.local/share
mkdir -p $XDG_DATA_HOME; chown spot:spot $XDG_DATA_HOME
export FATDOG_STATE_DIR=$SPOT_HOME/.fatdog

set -- "$(eval_safe_quote "$@")"

exec su spot -s /bin/dash -c '

https://pastebin.com/sxLd1tgg
Tried that script, edited it to work with user "puppy" (attached below) on Stretchdog, works well except some warnings about "dconf"
I ran:

Code: Select all

 ./run-as-puppy firefox "$@"
EDIT: Can also be used to run vlc as puppy:

Code: Select all

 ./run-as-puppy vlc "$@"
On Bionicdog there's menu entry that basically runs this:

Code: Select all

xhost +local:puppy

su puppy -c firefox
So, I understand this is less secure ? (using xhost)

There's also the solution that dancytron came with some time ago, using gksu (this is for chrome)

Code: Select all

gksu -u puppy "/usr/bin/google-chrome-stable --user-data-dir=/home/puppy/chrome/user --disk-cache-dir=/home/puppy/chrome/cache --disk-cache-size=10000000 --media-cache-size=10000000"
Fred
Attachments
run-as-puppy.gz
Remove fake .gz, make excutable and run e.g. ./run-as-puppy firefox "$@"
For e.g. Debiandog, Stretchdog, Bionicdog
(1.56 KiB) Downloaded 109 times

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

Re: FrankenEavesdropping

#6 Post by wiak »

s243a wrote:It isn't obvious to me from the above that xdm is being used as wiak suggested
No, that's not using XDM-AUTHORIZATION-1. It's using MIT-MAGIC-COOKIE-1

https://www.x.org/wiki/Development/Docu ... /Security/

https://stackoverflow.com/questions/371 ... e/37367518

As you can google, find, and read, MIT-MAGIC-COOKIE-1 is a bit less secure, but more common on desktops, than using XDM-AUTHORIZATION-1. The two mechanisms are similar in that they both use .Xauthority cookie file, but XDM-AUTHORIZATION-1 uses DES encryption as part of the process in a way that helps prevent network snoopers reading the cookie. XDM-AUTHORIZATION-1 is apparently not used often because DES isn't exportable from US.

wiak

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#7 Post by s243a »

fredx181 wrote:
s243a wrote:Here is some of this script:
Code:

[ -z "$XAUTHORITY" ] && XAUTHORITY=/root/.Xauthority
[ -e "$XAUTHORITY" ] && cp $XAUTHORITY $SPOT_HOME/.Xauthority &&
chown spot:spot $SPOT_HOME/.Xauthority &&
export XAUTHORITY=$SPOT_HOME/.Xauthority

export XDG_CONFIG_HOME=$SPOT_HOME/.config
export XDG_CACHE_HOME=$SPOT_HOME/.cache
export XDG_DATA_HOME=$SPOT_HOME/.local/share
mkdir -p $XDG_DATA_HOME; chown spot:spot $XDG_DATA_HOME
export FATDOG_STATE_DIR=$SPOT_HOME/.fatdog

set -- "$(eval_safe_quote "$@")"

exec su spot -s /bin/dash -c '

https://pastebin.com/sxLd1tgg
Tried that script, edited it to work with user "puppy" (attached below) on Stretchdog, works well except some warnings about "dconf"
I ran:

Code: Select all

 ./run-as-puppy firefox "$@"
EDIT: Can also be used to run vlc as puppy:

Code: Select all

 ./run-as-puppy vlc "$@"
On Bionicdog there's menu entry that basically runs this:

Code: Select all

xhost +local:puppy

su puppy -c firefox
So, I understand this is less secure ? (using xhost)

There's also the solution that dancytron came with some time ago, using gksu (this is for chrome)

Code: Select all

gksu -u puppy "/usr/bin/google-chrome-stable --user-data-dir=/home/puppy/chrome/user --disk-cache-dir=/home/puppy/chrome/cache --disk-cache-size=10000000 --media-cache-size=10000000"
Fred
Thankyou fred :). I'll give this a try.

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

Re: FrankenEavesdropping

#8 Post by s243a »

wiak wrote:
s243a wrote:It isn't obvious to me from the above that xdm is being used as wiak suggested
No, that's not using XDM-AUTHORIZATION-1. It's using MIT-MAGIC-COOKIE-1

https://www.x.org/wiki/Development/Docu ... /Security/

https://stackoverflow.com/questions/371 ... e/37367518

As you can google, find, and read, MIT-MAGIC-COOKIE-1 is a bit less secure, but more common on desktops, than using XDM-AUTHORIZATION-1. The two mechanisms are similar in that they both use .Xauthority cookie file, but XDM-AUTHORIZATION-1 uses DES encryption as part of the process in a way that helps prevent network snoopers reading the cookie. XDM-AUTHORIZATION-1 is apparently not used often because DES isn't exportable from US.

wiak
I wonder if I can get DES encryption in Canada. I must read up on this.

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#9 Post by s243a »

rufwoof wrote:
s243a wrote:
rufwoof wrote:IMO - No.
That's a very ironic position from you.
No irony. Don't run any apps as root under X. X is dated and vulnerable. Quick search ... https://blog.martin-graesslin.com/blog/ ... s-as-root/ ... there are thousands of others.
Put we're talking about running aps as a less privlaged user like spot.

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#10 Post by s243a »

rufwoof wrote:The flawed Puppy philosophy is that your data is just as vulnerable if a hacker breaks in as user or root - which assumes you store data under user. You could however store data under root, and if user was hacked they also have to privilege elevate before they can also get to data. Why run everything as root - even running under a userid that was nearly the same as root, but just with some limitations, such as no access to roots private keys, or certain limited data etc. would be a vast improvement. Puppy however is not true multi-user (in contrast the Dogs are - but they're not Puppy Linux).
Nothing is stopping one from creating other users in puppy if one doesn't like the permissions of spot. Also it sounds like you're giving the Dogs props here which is ironic.

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#11 Post by fredx181 »

Just for info: Note that the 'Dogs' are NOT true multi-user out of the box.
This is because of the auto-login as root by default.
You can create new user and login, but you can always easily get back to root by exiting X and type "logout" or "exit" followed by startx.

However, disabling auto-login will "fix" that, and even better, also install a login manager, like slim or lightdm.

Fred

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#12 Post by s243a »

rufwoof wrote:...is that you could run with a root equivalent setup - a userid that was as good as root. With that you could remove/prevent even just one element however ... i.e. its not totally authoritative - and which would be a start on the right road. Since 2015 Debian have by default (assuming DRM/KMS) set X to run as non-root. If the userid you do use to run X is all-powerful - as good as root - other than for certain select functions that are restricted to be run/accessed solely by root (and not using X but the console for those few limited things), then potential security and design are significantly improved. Yet again however I've posted with good intent, but anticipate the usual abuse in return.
That's interesting and probably good practice but maybe more difficult for beginners. On puppy there is the first time setup window, and this could be incorporated as one of the options in said window.

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#13 Post by fredx181 »

Ough... confusing, looks like this thread has been censured in some way, I see quotes from posts that are not earlier visible (EDIT: and modified posts, e. g the last from s243a, not sure if done by the poster himself, censored also ?).
Please, Mr. moderator (Flash, I assume ?), don't do that, small chance IMO that it will escalate the way it did earlier (and respect the OP intention, please).

Fred

User avatar
Flash
Official Dog Handler
Posts: 13071
Joined: Wed 04 May 2005, 16:04
Location: Arizona USA

#14 Post by Flash »

Rufwoof removed the contents of the posts he made to this thread, so I removed the posts. I should have left them so everyone could see what he did. I also edited s243a's post to remove references to rufwoof's posts that had nothing useful to add to this discussion.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#15 Post by rufwoof »

s243a wrote:
rufwoof wrote:...is that you could run with a root equivalent setup - a userid that was as good as root. With that you could remove/prevent even just one element however ... i.e. its not totally authoritative - and which would be a start on the right road. Since 2015 Debian have by default (assuming DRM/KMS) set X to run as non-root. If the userid you do use to run X is all-powerful - as good as root - other than for certain select functions that are restricted to be run/accessed solely by root (and not using X but the console for those few limited things), then potential security and design are significantly improved.
That's interesting and probably good practice but maybe more difficult for beginners. On puppy there is the first time setup window, and this could be incorporated as one of the options in said window.
gksu is being pulled from Debian (as of Buster I believe) a good choice to not let you login as root in gui (many say you shouldn't login as root on a virtual console either - some even disable root login altogether (Ubuntu)). sudo isn't installed in Debian by default IIRC, but easily added - and added to (what 'user' might do ... such as run synaptic/whatever). That enhanced-user could appear as good as root in nearly all things, other than perhaps having access to /root. For that I'd set it up something like ...

For standard Debian (SystemD/grub) you can get it to boot to cli by adjusting /etc/default/grub to
# GRUB_CMDLINE_LINUX_DEFAULT # comment out so textual boot messages
GRUB_CMDLINE_LINUX="text"
GRUB_TERMINAL="console"
.. and run update-grub && systemctl set-default multi-user.target

Set the system to auto login 'user' by creating /etc/systemd/system/getty@tty1.service.d/override.conf containing ...
[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin user --noclear %I 38400 linux
... and enable that by running systemctl enable getty@tty1.service

Set the system so you need to be a member of wheel group to su ... but don't add 'user' to the wheel group i.e.
edit /etc/pam.d/su and uncomment the line auth required pam_wheel.so


Appending

Code: Select all

[ -z $DISPLAY ] && [ "$(tty)" = "/dev/tty" ] && startx
to user's ~/.profile will automatically startx when user is (automatically) logged in i.e. boots straight to desktop.

That sort of setup could be appear to be almost identical in operation to the current look/feel when running X as root, other than running as a enhanced user instead of root - and with the additional twist/benefit that with some experience new users could learn how to use /root to better secure personal docs/data.

The above is all pure Debian stuff (SystemD etc.), not sure how that might be mapped to Pup's/Porteus/Devuan etc. I suspect it would be more difficult for Pup's than Dog's to implement due to Pup's not being real multi-user.

==================================================================

If you install Debian to HDD, perhaps just adding contrib and non-free to the repo's just to install required firmware (graphics) and reverting back to just Main repo again afterwards (/etc/apt/sources.list) then for live-boot (sfs style)

Code: Select all

apt-get update
apt-get install live-boot
apt-get install squashfs-tools
mkdir /live
cd /live
mkdir etc
mksquashfs etc filesystem.squashfs
rmdir etc
cd /
echo / union >persistence.conf
echo >>persistence.conf
e2label /dev/sda1 persistence
and edit etc/grub.d/40-custom to include a entry of

Code: Select all

menuentry 'live-boot' {
set root=(hd0,1)
linux /vmlinuz boot=live persistence persistence-read-only
initrd /initrd.img
}
run the command update-grub (you might like to edit /etc/default/grub entries for
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
and set GRUB_DEFAULT=2 ... so it by default boots the live boot choice (and again run update-grub afterwards))

That way you'll boot a read only overlay fs style (sfs), but where in effect the main sfs is empty and you're using a partition based save area (instead of a file or folder) ... and where the full Debian install is in that save area. You can load sfs's, reboot without any change being preserved etc. using that boot method, and simply reboot the real/main Debian boot and run apt-get update;apt-get upgrade ... to update the system/programs to the latest versions/security patched version.

You could even mksquashfs the whole Debian partition into /live/filesystem.squashfs and just boot that (just have boot=live kernel parameter, drop the persistence persistence-read-only kernel boot parameters) and run that. Comes in at around a 1.5GB sfs filesize IIRC, which nowadays isn't that much bigger than the 1GB of sfs's you'd typically accumulate to relatively quickly using DebDog - and you get all of the man pages etc. included (which at times can be really helpful as the installed man pages match the installed version of system/programs).

Once you have user auto logging in and running X, create another userid (perhaps admin) and allocate that to be in the sudo group (addgroup admin sudo), and disable root (passwd -d root;password -l root) and use that userid to do root like actions. Any brute force attempts at attacking the root password will fail, hackers have to crack both the admin userid and password. Y could add admin to group wheel so it can sudo su - ... into root, but securer if you just stick with using sudo.
[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]

Post Reply