Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sun 18 Aug 2019, 06:45
All times are UTC - 4
 Forum index » Off-Topic Area » Security
FrankenEavesdropping
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [15 Posts]  
Author Message
s243a

Joined: 02 Sep 2014
Posts: 2027

PostPosted: Fri 28 Sep 2018, 12:54    Post subject:  FrankenEavesdropping  

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:

...
Exec=firefox-spot %U
...

we can locate this file by typing
Code:

# which firefox-spot
/usr/bin/firefox-spot

Opening the file:
Code:

#!/bin/dash
exec /usr/bin/run-as-spot /usr/bin/firefox "$@"

Now we see the workhorse here:
Code:

/usr/bin/run-as-spot


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

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.
Back to top
View user's profile Send private message Visit poster's website 
rufwoof


Joined: 24 Feb 2014
Posts: 3325

PostPosted: Fri 28 Sep 2018, 17:26    Post subject:  

...
_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh

Last edited by rufwoof on Sat 29 Sep 2018, 02:01; edited 1 time in total
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2027

PostPosted: Fri 28 Sep 2018, 18:00    Post subject:  

rufwoof wrote:

Quote:
"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!
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2027

PostPosted: Fri 28 Sep 2018, 18:10    Post subject:  

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.
Quote:
"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.
Back to top
View user's profile Send private message Visit poster's website 
fredx181


Joined: 11 Dec 2013
Posts: 4017
Location: holland

PostPosted: Sat 29 Sep 2018, 08:14    Post subject:  

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:
 ./run-as-puppy firefox "$@"

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


On Bionicdog there's menu entry that basically runs this:
Code:
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:
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
run-as-puppy.gz
Description  Remove fake .gz, make excutable and run e.g. ./run-as-puppy firefox "$@"
For e.g. Debiandog, Stretchdog, Bionicdog
gz

 Download 
Filename  run-as-puppy.gz 
Filesize  1.56 KB 
Downloaded  68 Time(s) 

_________________
Dog Linux website
Tinylinux blog by wiak
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1570
Location: not Bulgaria

PostPosted: Sat 29 Sep 2018, 10:57    Post subject: Re: FrankenEavesdropping  

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/Documentation/Security/

https://stackoverflow.com/questions/37157097/how-does-x11-authorization-works-mit-magic-cookie/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
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2027

PostPosted: Sat 29 Sep 2018, 13:26    Post subject:  

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:
 ./run-as-puppy firefox "$@"

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


On Bionicdog there's menu entry that basically runs this:
Code:
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:
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 Smile. I'll give this a try.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2027

PostPosted: Sat 29 Sep 2018, 13:29    Post subject: Re: FrankenEavesdropping  

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/Documentation/Security/

https://stackoverflow.com/questions/37157097/how-does-x11-authorization-works-mit-magic-cookie/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.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2027

PostPosted: Sat 29 Sep 2018, 18:14    Post subject:  

rufwoof wrote:
s243a wrote:
rufwoof wrote:
Quote:
"should we?".
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/2017/02/editing-files-as-root/ ... there are thousands of others.


Put we're talking about running aps as a less privlaged user like spot.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2027

PostPosted: Sat 29 Sep 2018, 18:46    Post subject:  

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.
Back to top
View user's profile Send private message Visit poster's website 
fredx181


Joined: 11 Dec 2013
Posts: 4017
Location: holland

PostPosted: Sun 30 Sep 2018, 04:29    Post subject:  

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

_________________
Dog Linux website
Tinylinux blog by wiak
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2027

PostPosted: Sun 30 Sep 2018, 12:25    Post subject:  

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.
Back to top
View user's profile Send private message Visit poster's website 
fredx181


Joined: 11 Dec 2013
Posts: 4017
Location: holland

PostPosted: Sun 30 Sep 2018, 13:27    Post subject:  

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

_________________
Dog Linux website
Tinylinux blog by wiak
Back to top
View user's profile Send private message 
Flash
Official Dog Handler


Joined: 04 May 2005
Posts: 13282
Location: Arizona USA

PostPosted: Sun 30 Sep 2018, 17:34    Post subject:  

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.
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3325

PostPosted: Sun 30 Sep 2018, 20:10    Post subject:  

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:
[ -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:
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:
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.

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [15 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Security
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1029s ][ Queries: 14 (0.0304s) ][ GZIP on ]