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 Sat 20 Jul 2019, 01:16
All times are UTC - 4
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Browsers and Internet
Google Chrome 64-bit PET & SFS packages
Post new topic   Reply to topic View previous topic :: View next topic
Page 18 of 19 [282 Posts]   Goto page: Previous 1, 2, 3, ..., 16, 17, 18, 19 Next
Author Message
Mike Walsh


Joined: 28 Jun 2014
Posts: 5154
Location: King's Lynn, UK.

PostPosted: Thu 14 Mar 2019, 17:28    Post subject:  

@ mjmikulcik:-

I didn't rush an updated package of that 'point' release out, because I knew the new version (73) would be out any day now. Thanks for the 'heads-up', all the same. Appreciated. Smile

The new version will be available for download later this evening. The mitigations for the referenced weakness should, of course, be in this new release.


Mike. Wink

_________________
MY 'PUPPY' PACKAGES


Last edited by Mike Walsh on Thu 14 Mar 2019, 18:17; edited 1 time in total
Back to top
View user's profile Send private message 
Mike Walsh


Joined: 28 Jun 2014
Posts: 5154
Location: King's Lynn, UK.

PostPosted: Thu 14 Mar 2019, 18:10    Post subject:  

Evening, all.

The current stable version of Chrome - Google_Chrome-73.0.3683.75-amd64 - is now available for download, from the location referenced in post #1.

------------------------------------------------

Changes and updates in this release are as explained here, on the regular Chrome blog page.

60 security issues, including the recently-discovered 'critical' one (mentioned by mjmikulcik above) have been addressed since the previous release.

----------------------------------------------------

A small script, which has been placed in /usr/sbin & sym-linked into /root/Startup, now automatically runs the glib-compile-schemas compile command at boot time. Downloads/uploads, therefore, work as they should.

The 'Spot2Root' file permissions changer has also been updated. It now works with uploads as well as downloads.....as explained in an earlier post. Following an exchange of ideas & points raised via PM with mikeslr, I've added an extra line to the 'spot-to-root' module of the Permissions Changer which sits in the task-bar; when you select 'Spot-to-Root (for downloads)' in the GUI, ROX (or whatever your default file-manager happens to be) will now open on your 'Downloads' directory, ready to retrieve the newly-downloaded item.

------------------------------------------------------------------

Credits (as usual) :-

Battleshooter - for help with the self-contained NSS libs'n'stuff several releases back.
belham2 - for cobbling together the 'launch' script that is now employed.
And further back, 01Micko (the 'head honcho'), and iguleder - both of whom have indirectly helped keep this thread going for as long as it has, with references & links.

Thanks must also go to OscarTalks and peebee, for suggestions and assistance over the last couple of years.

---------------------------------

Any problems, boys & girls, you know where to find me.

Enjoy.


Mike. Wink

_________________
MY 'PUPPY' PACKAGES

Back to top
View user's profile Send private message 
MrDuckGuy


Joined: 31 Jan 2019
Posts: 106
Location: Hermosa Beach, CA, USA

PostPosted: Thu 14 Mar 2019, 19:34    Post subject: Re: Google Chrome 64-bit PET & SFS packages
Subject description: Chrome 73.0.3683.75 : more new 'mods' - now running under /home/spot
 

Mike Walsh wrote:
Evening, ... stable version of Chrome
... available for download ... location
referenced in post #1 ... problems, boys
& girls, you know where ...
I would like a question if possible to be
addressed, and here's the peshat of it:
can this application be run in a
"portable" folder as I am doing with the
FireFox program even now as I post this?

Thanks in advance, Kelikaku. B'H.
monkeyeatingalemon-2.jpg
 Description   This is an image of a monkey
eating a lemon, for
no particular reason. B'H.
 Filesize   28.25 KB
 Viewed   387 Time(s)

monkeyeatingalemon-2.jpg

Back to top
View user's profile Send private message 
Mike Walsh


Joined: 28 Jun 2014
Posts: 5154
Location: King's Lynn, UK.

PostPosted: Thu 14 Mar 2019, 21:27    Post subject:  

@ MrDuckGuy:-

Mm. Never really thought about it, TBH. In its current format, no (there's too many extra additions & bits'n'bobs in other directories to permit that). I could look into it, though it would be a perhaps 'stripped-down' version - some of the additional functionality (like the permissions changer for uploads/downloads, and the 'glib-schemas' compiler script) might have to be installed as separate .pets before you started using it.

When I started doing this a few years back I never envisaged running it that way. Consequently, it wasn't built with portability in mind.

I'll look into it, OK? Just don't expect to see it any time soon.....I have a lot on my plate most days (I'm a full-time carer, y'see). I'll put my considering cap on, and have a think about the best way to do this....


Mike. Wink

_________________
MY 'PUPPY' PACKAGES

Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3252

PostPosted: Sat 20 Apr 2019, 23:54    Post subject:  

Mike, as our resident Chrome expert, what are the limitations, if any, imposed by running google chrome with the --no-sandbox switch?

I'm not concerned about running as root with no sandboxing as I'm already containing chrome within a restricted environment anyway i.e. FatDog 8 with a Barry like containment (Xephyr, unshare, chroot with capsh (capabilities for sys_admin and chroot dropped)), so pretty much a heavily restricted 'root' - comparable to a low privilege/restricted userid that's isolated from the main FatDog X system. Providing you don't keep sensitive data/stuff within that container then that's impervious to even a zero day vulnerability. But I was wondering what limitations running with --no-sandbox might impose.

TIA.

_________________
( ͡° ͜ʖ ͡°) :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 
s243a

Joined: 02 Sep 2014
Posts: 1945

PostPosted: Sun 21 Apr 2019, 00:10    Post subject:  

rufwoof wrote:
Mike, as our resident Chrome expert, what are the limitations, if any, imposed by running google chrome with the --no-sandbox switch?

I'm not concerned about running as root with no sandboxing as I'm already containing chrome within a restricted environment anyway i.e. FatDog 8 with a Barry like containment (Xephyr, unshare, chroot with capsh (capabilities for sys_admin and chroot dropped)), so pretty much a heavily restricted 'root' - comparable to a low privilege/restricted userid that's isolated from the main FatDog X system. Providing you don't keep sensitive data/stuff within that container then that's impervious to even a zero day vulnerability. But I was wondering what limitations running with --no-sandbox might impose.

TIA.


On could always do a "run as spot", script but it's still worth discussing. On my TazPup64, I'm thinking of adding an environmental variable that determines whether the --no-sandbox is used vs "run as some restricted user".

P.S. on another thread, I mentioned your restricted containers to someone.
Back to top
View user's profile Send private message Visit poster's website 
Mike Walsh


Joined: 28 Jun 2014
Posts: 5154
Location: King's Lynn, UK.

PostPosted: Sun 21 Apr 2019, 07:27    Post subject:  

Morning, ruffers.

Hoo... Y'know, to be perfectly honest, I've never really looked into the security aspects of it. Not in anywhere near the same way that I know you yourself do, quite regularly. (And I definitely dispute the 'expert' tag. I'm a bumbler, really, although I managed to assemble all the various bits that many other folks helped with over the last few years.....without making too many mistakes. I mean, it runs..... Laughing)

I digress.

Y'see, this is where the differences between the various Chromium 'clones' begins to show through. Chromium itself, as released, will run without the sandbox, although it doesn't like it.

-----------------------------------------------

SRWare's Iron, although using the 'chrome' shared library/binary thingy (it's not a binary executable in the true sense of the word, though it's where the bulk of the program lies), will also run without the sandbox.

-----------------------------------------------

FlashPeak, with recent releases of SlimJet, have coded things so that you've got to run it as a restricted user. No arguments. Try using the --no-sandbox switch, it just won't run.

-----------------------------------------------

Google, with Chrome, have done much the same. In true Google style, though, they've enhanced the standard sandbox set-up even further so that the browser uses around 5 different sandboxes, all interacting with each other. Which in part accounts for the huge size these browsers are now ballooning into. It decidedly will not run without the sandboxing enabled, and, moreover, that sandboxing is linked into the use as a restricted user. If you don't get all the conditions just right, it simply doesn't want to know.

I don't think, for your purposes, it would make any difference that you're already running it inside a container. The 'sandboxing' is fully internal to the browser process, and if you enable the switch, it wouldn't start.

Hope that throws some light on things.....though it's far from a complete answer.


Mike.

_________________
MY 'PUPPY' PACKAGES

Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3252

PostPosted: Sun 21 Apr 2019, 08:30    Post subject:  

Oooerrr! Confused now!

I'm running google chrome as root inside that container with the --no-sandbox and it runs seemingly OK. Just has a bar come up initially saying that sandbox is disabled and security/functionality is compromised.
s.png
 Description   
 Filesize   38.51 KB
 Viewed   220 Time(s)

s.png


_________________
( ͡° ͜ʖ ͡°) :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 
rufwoof


Joined: 24 Feb 2014
Posts: 3252

PostPosted: Sun 21 Apr 2019, 08:42    Post subject:  

s243a wrote:
P.S. on another thread, I mentioned your restricted containers to someone.

I have much the same set up in FatDog 8 now. What I've done for that is to have the main systems tray at the top of screen, and the containers tray at the default bottom of screen location. I set the Xephyr window to be undecorated (no title bar) and size it to 32 less height and Y offset by 32 ... so it doesn't overlay the main systems tray. That way you can activate menu's or the tray items in either the main or container quickly/easily.

The main quirks are that sometimes the mouse gets locked inside the container and you have to ctrl-shift to release it again. And you have to be aware of which windows are in which environment as you can't for instance cut from a container window and paste into a main system window.

Not so confident about spot myself. I have found it easy to elevate to root from spot in a number of Puppy's to the extent I considered it pointless in most cases. Fatdog 8 is one of the exceptions.
s.png
 Description   
 Filesize   89.08 KB
 Viewed   223 Time(s)

s.png


_________________
( ͡° ͜ʖ ͡°) :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 
Mike Walsh


Joined: 28 Jun 2014
Posts: 5154
Location: King's Lynn, UK.

PostPosted: Sun 21 Apr 2019, 10:37    Post subject:  

rufwoof wrote:
Oooerrr! Confused now!

I'm running google chrome as root inside that container with the --no-sandbox and it runs seemingly OK. Just has a bar come up initially saying that sandbox is disabled and security/functionality is compromised.


Hm. Well, that's news to me.....and something I've learnt. Under normal circumstances, it won't work for me; perhaps running inside the container has changed its ability to run without the sandbox enabled.

Can't say, mate.


Mike. Wink

_________________
MY 'PUPPY' PACKAGES

Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3252

PostPosted: Sun 21 Apr 2019, 10:49    Post subject:  

Whatever its going, with chrome just showing the puppy forum web page, all child processes spawned by chrome also have the --no-sandbox parameter. So yes does work.

Maybe because that container has cap_sys_admin and cap_sys_chroot capabilities dropped - chrome might perhaps be able to detect its not a full blown root. Running without the --no-sandbox however and it does complain/not run.
s.png
 Description   
 Filesize   74.11 KB
 Viewed   207 Time(s)

s.png


_________________
( ͡° ͜ʖ ͡°) :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 
rufwoof


Joined: 24 Feb 2014
Posts: 3252

PostPosted: Sun 21 Apr 2019, 11:39    Post subject:  

It would seem that running chrome with its sandbox requires root level chroot capabilities. Drop chroot capability and you have to use the --no-sandbox command line parameter. In a chroot container however you don't want chroot capabilities, otherwise you (or potential cracker) can just chroot out of the container.

So the choices would seem to be to either run as spot inside a container with chroot capabilities, but perhaps where spot doesn't have chroot potential, or run as root with no chroot capabilities at all.

Weighing things up, fundamentally do you put total faith in chrome's containment, and hope that spot can't elevate to root, or run chrome as root inside the Xephyr/unshare/chroot/capsh environment, with no-sandbox. Of the two the latter seems the better choice IMO, more so given recent chrome zero day bugs that potentially opened up the system. Also I have little faith in spot not being able to potentially elevate to root - potentially relatively easily, which further adds to the appeal of not permitting chroot capabilities.

In short I think Xephyr/unshare/chroot/capsh with chrome running as root with --no-sandbox is the better choice compared to trying to run chrome as spot within a container.

cd /pub
more beer

_________________
( ͡° ͜ʖ ͡°) :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 
s243a

Joined: 02 Sep 2014
Posts: 1945

PostPosted: Tue 23 Apr 2019, 20:08    Post subject:  

rufwoof wrote:
Mike, as our resident Chrome expert, what are the limitations, if any, imposed by running google chrome with the --no-sandbox switch?

I'm not concerned about running as root with no sandboxing as I'm already containing chrome within a restricted environment anyway i.e. FatDog 8 with a Barry like containment (Xephyr, unshare, chroot with capsh (capabilities for sys_admin and chroot dropped)), so pretty much a heavily restricted 'root' - comparable to a low privilege/restricted userid that's isolated from the main FatDog X system. Providing you don't keep sensitive data/stuff within that container then that's impervious to even a zero day vulnerability. But I was wondering what limitations running with --no-sandbox might impose.

TIA.


I noticed something weird about Opera (and possibly other chrome clones), when running with the --no-sandbox tag. On my TazPup64 I'm working on I had opera running under jwm. I exited Xorg and started LXDE. I noticed Opera was running like it had never shut down when I exited XOrg. To me this behavior is undesirable because then cntrl-alt-backspace is less likely to unfreeze the system if for some reason the system freezes.

Perhaps I can add a command to specifically kill chrome (and it's clones) in whatever script ("presumably wmexit") is called when I press cntrl-alt-backspace.

Note that, I didn't yet check to see what Opera related process might continue to run when the Xserver shuts down.
Back to top
View user's profile Send private message Visit poster's website 
Mike Walsh


Joined: 28 Jun 2014
Posts: 5154
Location: King's Lynn, UK.

PostPosted: Sat 27 Apr 2019, 07:33    Post subject:  

Evening, all.

The current stable version of Chrome - Google_Chrome-74.0.3729.108-amd64 - is now available for download, from the location referenced in post #1.

------------------------------------------------

Changes and updates in this release are as explained here, on the regular Chrome blog page.

39 security issues have been addressed since the previous release.

----------------------------------------------------

A small script, which has been placed in /usr/sbin & sym-linked into /root/Startup, now automatically runs the glib-compile-schemas compile command at boot time. Downloads/uploads, therefore, work as they should.

The 'Spot2Root' file permissions changer has also been updated. It now works with uploads as well as downloads.....as explained in an earlier post. Following an exchange of ideas & points raised via PM with mikeslr, I've added an extra line to the 'spot-to-root' module of the Permissions Changer which sits in the task-bar; when you select 'Spot-to-Root (for downloads)' in the GUI, ROX (or whatever your default file-manager happens to be) will now open on your 'Downloads' directory, ready to retrieve the newly-downloaded item.

It's also been re-written to remove the need for the intermediate 'Spot2Root' directory in /usr/share. Following some research using the Linux man pages, I've finally discovered how to move stuff from one directory to another and change permissions in the process, all in the one single line of code....

I'm steadily learning. Very Happy

------------------------------------------------------------------

Credits (as usual) :-

Battleshooter - for help with the self-contained NSS libs'n'stuff several releases back.
belham2 - for cobbling together the 'launch' script that is now employed.
And further back, 01Micko (the 'head honcho'), and iguleder - both of whom have indirectly helped keep this thread going for as long as it has, with references & links.

Thanks must also go to OscarTalks and peebee, for suggestions and assistance over the last couple of years.

---------------------------------

Any issues, I'm usually kicking around somewhere on the Forums. You know how to get in touch.

Have fun!


Mike. Wink

_________________
MY 'PUPPY' PACKAGES


Last edited by Mike Walsh on Thu 02 May 2019, 10:50; edited 2 times in total
Back to top
View user's profile Send private message 
albertox

Joined: 03 Apr 2019
Posts: 6
Location: Planet Earth , for now :)

PostPosted: Wed 01 May 2019, 18:57    Post subject: Downloads Location  

@Mike Walsh

Thank you so much Mike for keeping Chrome up to date, it's my favorite browser too. We are very lucky to have great people like you and the others in the forum who devote their free time to provide us with various software.

I don't know if this has been answered already, but I couldn't find it in search. I'm running TahrPup64 and SFS version. Chrome crashes if I try to change the downloads location. It also crashes if I set Downloads to "ask where to save", when trying to download before the choose location menu comes up.

I'm not sure if I'm doing something wrong, as I'm a newcomer to GNU/Linux, and still struggling with the technical stuff.
.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 18 of 19 [282 Posts]   Goto page: Previous 1, 2, 3, ..., 16, 17, 18, 19 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Browsers and Internet
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.1126s ][ Queries: 12 (0.0483s) ][ GZIP on ]