Re: browser security in OpenBSD
On 2019-01-05, Mihai Popescu wrote: > Hello, > > I see there is some work in Chromium to implement secure browsing. I > was using both Chromium and Firefox over the past years. If I got it > right, here is a summary of implementations: > Chromium: W^X, pledge, unveil chromium doesn't have W^X but is more sandbox-friendly in the design upstream which means it has more meaningful pledge restrictions (5 or so process types with fairly small pledges, the majority of them having no network access), unveil is also used by default in -current which restricts access to files, for example with default settings it no longer has access to many files in your home directory (specific access is granted to some "dotfiles" and a smallish number of paths in .config/.cache/.local etc, and ~/Downloads, so things like ~/.ssh are blocked off). > Firefox: W^X firefox has W^X but only main + content process types, both of which have both network and disk access. (the most common setup in programs which are a good fit with pledge is to separate these; if you look in /usr/src you'll see that in the majority of cases a program will *either* have disk access *or* network access after pledging, but often not both together). so (*just* referring to the more openbsd-ish security features), there's more memory protection in firefox, more of other types of protection in chrome. > I don't want to start a brosers' war, but what is best to run strictly > from security point of view at this time? > > Thanks. > >
Re: browser security in OpenBSD
On Sat, Jan 05, 2019 at 03:38:16PM +0200, Mihai Popescu wrote: > Hello, > > I see there is some work in Chromium to implement secure browsing. I > was using both Chromium and Firefox over the past years. If I got it > right, here is a summary of implementations: > Chromium: W^X, pledge, unveil > Firefox: W^X > I'm going to throw in the question of how is upstream itself a question of security. These are very big moving targets. Are they proceeding cautiously forward or hell burnt for leather at any cost? I guess a good metaphor would be OpenBSD constantly breaking httpd and pf in order to make them more secure. And releasing broken versions. Is upstream doing this sort of thing as they develop? I also agree, no browser war. I have to use both. Each one fails at something important I do. Chris Bennett
Re: browser security - restricted user
On Wed, Dec 14, 2005 at 10:48:28AM -0800, Bob Smith wrote: Just a thought: sudo -u $some_restricted_user $your_preffered_browser ? good that you brought this up; i been wondering about this too. does it help? if so how come there isnt a default non-privileged user created for, say, firefox when the pkg is installed? like there is for bitlbee (_bitlbee) or tcpdump (_tcpdump)? ... yeah, and create separate user for every 3-rd party package, that had security holes in the past ;) Why people are so afraid of systrace, especially as creating policy for non-fork()`ing and non-set*id()`ing application is considerably safer for its usability? - Lukasz Sztachanski -- 0x058B7133 // 16AB 4EBC 29DA D92D 8DBE BC01 FC91 9EF7 058B 7133 http://szati.blogspot.com http://szati.entropy.pl
Re: browser security
On Wed, 14 Dec 2005 05:41:30 -0800, Bob Smith [EMAIL PROTECTED] wrote: vmware recently released a program which kind of chroot jails the browser. http://www.vmware.com/vmtn/vm/browserapp.html im not a programmer myself, but i was wondering if perhaps using a similar technique we could lock down the browsers in openbsd? seems to me that would increase security greatly for us who surf the web on openbsd boxes? or am i mistaking? You need to understand the tech being used a bit better. There's a big difference between a chroot/jail and a virtual machine. They both try to isolate an application from interacting with the rest of the system but the way the two go about it is vastly different. Obviously, isolation is a good thing but you need to understand that writing a complete virtual machine in C that works on all supported OpenBSD architectures is a *MASSIVE* amount of work. Even VMware supports only one architecture for their player (x86-32) and only two possible host operating systems on that architecture (linux and ms-windows). You may also want to realize that no attempted isolation is perfect. There are ways for attackers to break out of jails/chroots and similar is true for virtual machines. By using such methods you've only added a _layer_ of security which only stops _some_ (possibly many) attackers. It's not completely bullet proof (nothing is) but it does help. Kind Regards, JCR
Re: browser security
--On 14 December 2005 06:38 -0800, J.C. Roberts wrote: Even VMware supports only one architecture for their player (x86-32) They do actually support x86-64 on the player (I'm not sure if this changed recently - 'player' is out of beta as of a day or two ago). and only two possible host operating systems on that architecture (linux and ms-windows). Yes, this is a pity, but not entirely unexpected. You may also want to realize that no attempted isolation is perfect. There are ways for attackers to break out of jails/chroots and similar is true for virtual machines. By using such methods you've only added a _layer_ of security which only stops _some_ (possibly many) attackers. It's not completely bullet proof (nothing is) but it does help. You only need to break the 'browser appliance' OS to send traffic on the LAN/internet, and the regular environment provided by the standardized VM could make this easier. It does make it significantly harder to access personal data stored outside the VM though (compared with browsing directly on the same machine as the personal data).
Re: browser security
--On 14 December 2005 05:41 -0800, Bob Smith wrote: vmware recently released a program which kind of chroot jails the browser. Actually, they released a disk-image with an installation of Ubuntu Linux including Firefox, that runs in their free-of-charge 'player' for x86 Linux/Windows (basic virtual-machine monitor software: it doesn't have the tools of vmware workstation, but you can do a lot with it without paying for anything: given suitable config and disk-image files, you can boot from pxe, real CD or ISO, and install your choice of OS). The 'browser appliance' image is an easy way to get a 10GB scsi disk image (mpt emulation), though you can create your own images fairly easily too (with dd, or a tool from Qemu). Config files are plaintext, quite a lot of information is available about writing them now. VMware say they're happy enough with people doing this. Quite a smart move imho, piggybacking on publicity from the widely-reported recent Xen release and also I imagine helpful given the track record of business tactics of their major commercial competitor... Quite nice for test systems (more options for sharing virtual networks than e.g. qemu makes it handy for playing with dynamic routing protocols, for example..) I don't see how running a Win/Linux system to run a virtualised Linux system is likely to beat running OpenBSD (or even booting something like knoppix from read-only media) in terms of security, however it's better than running browsers straight on Windows.
Re: browser security
thanks for the explanation. so it would be less work to try to chroot a browser then to make a virtual machine? perhaps its even a better way of isolating? i googled around a bit and found some threads about people trying to chroot their browsers, but i couldnt find any successful story. is it practically doable? looking at other troublesome programs; they come chooted by default on openbsd. is there any effort being made by others than vmware to isolate browsers? seems to me like it would be a step in the right direction? On 12/14/05, J. C. Roberts [EMAIL PROTECTED] wrote: On Wed, 14 Dec 2005 05:41:30 -0800, Bob Smith [EMAIL PROTECTED] wrote: vmware recently released a program which kind of chroot jails the browser. http://www.vmware.com/vmtn/vm/browserapp.html im not a programmer myself, but i was wondering if perhaps using a similar technique we could lock down the browsers in openbsd? seems to me that would increase security greatly for us who surf the web on openbsd boxes? or am i mistaking? You need to understand the tech being used a bit better. There's a big difference between a chroot/jail and a virtual machine. They both try to isolate an application from interacting with the rest of the system but the way the two go about it is vastly different. Obviously, isolation is a good thing but you need to understand that writing a complete virtual machine in C that works on all supported OpenBSD architectures is a *MASSIVE* amount of work. Even VMware supports only one architecture for their player (x86-32) and only two possible host operating systems on that architecture (linux and ms-windows). You may also want to realize that no attempted isolation is perfect. There are ways for attackers to break out of jails/chroots and similar is true for virtual machines. By using such methods you've only added a _layer_ of security which only stops _some_ (possibly many) attackers. It's not completely bullet proof (nothing is) but it does help. Kind Regards, JCR
Re: browser security
On Wed, Dec 14, 2005 at 05:41:30AM -0800, Bob Smith wrote: vmware recently released a program which kind of chroot jails the browser. http://www.vmware.com/vmtn/vm/browserapp.html im not a programmer myself, but i was wondering if perhaps using a similar technique we could lock down the browsers in openbsd? I don't know much about vmware, but it sounds like overkill when you have systrace(1). seems to me that would increase security greatly for us who surf the web on openbsd boxes? or am i mistaking?
Re: browser security
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Smith Sent: Wednesday, December 14, 2005 11:37 AM To: J. C. Roberts Cc: misc@openbsd.org Subject: Re: browser security thanks for the explanation. so it would be less work to try to chroot a browser then to make a virtual machine? perhaps its even a better way of isolating? i googled around a bit and found some threads about people trying to chroot their browsers, but i couldnt find any successful story. is it practically doable? looking at other troublesome programs; they come chooted by default on openbsd. is there any effort being made by others than vmware to isolate browsers? seems to me like it would be a step in the right direction? Anyone dare try making a systrace policy for firefox?
Re: browser security
On Wednesday 14 December 2005 17:37, Bob Smith wrote: thanks for the explanation. so it would be less work to try to chroot a browser then to make a virtual machine? perhaps its even a better way of isolating? i googled around a bit and found some threads about people trying to chroot their browsers, but i couldnt find any successful story. is it practically doable? looking at other troublesome programs; they come chooted by default on openbsd. is there any effort being made by others than vmware to isolate browsers? seems to me like it would be a step in the right direction? Just a thought: sudo -u $some_restricted_user $your_preffered_browser ? -- viq -- Zobacz finalistki Miss World!!! http://link.interia.pl/f18e8
Re: browser security - restricted user
Just a thought: sudo -u $some_restricted_user $your_preffered_browser ? good that you brought this up; i been wondering about this too. does it help? if so how come there isnt a default non-privileged user created for, say, firefox when the pkg is installed? like there is for bitlbee (_bitlbee) or tcpdump (_tcpdump)?
Re: browser security
On Wed, 14 Dec 2005 08:37:16 -0800, Bob Smith [EMAIL PROTECTED] wrote: thanks for the explanation. so it would be less work to try to chroot a browser then to make a virtual machine? perhaps its even a better way of isolating? i googled around a bit and found some threads about people trying to chroot their browsers, but i couldnt find any successful story. is it practically doable? When you think about all the crap a graphical browser needs just to run (fonts, mime types, library dependencies, plugins, cache, user preferences, ...), it will probably be a major pain to chroot the beast because you'll be duplicating tons of stuff into your chroot. At that point, you have only gained a copy of your file system rather than any real security. Worse yet many browsers are actually dual purpose and function as the system file manager within the windowing environment (windows/MSIE, KDE/konqueror, gnome/?, and so on...). If you actually manage to successfully chroot all your browsers to prevent accidentally clicking on a bad link, you suddenly don't have a file manager and have lost a lot of usability. looking at other troublesome programs; they come chooted by default on openbsd. is there any effort being made by others than vmware to isolate browsers? seems to me like it would be a step in the right direction? Programs are not chrooted/isolated because they are troublesome (i.e. have bugs), instead they are chrooted/isolated because they pose significant risks. Since a program like the Apache webserver is always exposed to threats from the outside world, it poses a greater risk than a simple utility program like copy or move that require access to the system. In the crap-happy world of the web and W3C standards, refusing to support crap-de-joure like Java, JavaScript, plugins, cookies and all the rest of the garbage only means that the overwhelming majority of crappy websites will break. Since the overwhelming majority of all web sites are crap spewed by idiots, you can guess where this leaves you. You also need to think about all the file writing that goes on when you browse the web. You've got your cache, cookies, user preferences, javascript files, downloaded plugins and lots of stuff that can be tainted and can be used against you. The Google claim of Do No Evil is really bullshit when you realize they are tracking you via every page that loads their AdWords/AdSense stuff and trying to shove targeted adds down your throat. But turning off cookies breaks a lot of well intentioned and useful sites including stuff in the FOSS world like: http://archive.netbsd.se http://sourceforge.net and countless others. A virtual machine by itself is probably not enough because the required local READ/WRITE on files makes for real mess that will only get worse over time. Though the rather smart folks at VMware have thought of this issue (the image can be configured to reset itself after each use), I'm not sure exactly how well it is implemented... -and no one will know without doing a lot of disassembly and reverse engineering. To prevent the READ/WRITE issue with chrooting, you'll need to figure out not only how to chroot the damn browser and everything it needs but you'll also need to figure out how to do the chroot in some kind of a self creating/loading RAM disk to keep a consistent starting state. To put it bluntly, you are looking at a ton of work regardless of the route you decide to take and this list is probably the worst place to discuss work that will never be done. Kind Regards, JCR
Re: browser security
On 14/12/05, J.C. Roberts [EMAIL PROTECTED] wrote: When you think about all the crap a graphical browser needs just to run (fonts, mime types, library dependencies, plugins, cache, user preferences, ...), it will probably be a major pain to chroot the beast because you'll be duplicating tons of stuff into your chroot. At that point, you have only gained a copy of your file system rather than any real security. Worse yet many browsers are actually dual purpose and function as the system file manager within the windowing environment (windows/MSIE, KDE/konqueror, gnome/?, and so on...). If you actually manage to successfully chroot all your browsers to prevent accidentally clicking on a bad link, you suddenly don't have a file manager and have lost a lot of usability. I've just had the most awesome idea: chroot the entire operating system!
Re: browser security
On Wed, 14 Dec 2005 19:32:18 +, Simon Morgan [EMAIL PROTECTED] wrote: On 14/12/05, J.C. Roberts [EMAIL PROTECTED] wrote: When you think about all the crap a graphical browser needs just to run (fonts, mime types, library dependencies, plugins, cache, user preferences, ...), it will probably be a major pain to chroot the beast because you'll be duplicating tons of stuff into your chroot. At that point, you have only gained a copy of your file system rather than any real security. I've just had the most awesome idea: chroot the entire operating system! It seems your mother never warned you that such levels of sarcasm usually results in permanent scarring... Let me guess, you're British (or at least somewhere in the UK). ;-) JCR
Re: browser security
On 14/12/05, J. C. Roberts [EMAIL PROTECTED] wrote: On Wed, 14 Dec 2005 19:32:18 +, Simon Morgan [EMAIL PROTECTED] wrote: I've just had the most awesome idea: chroot the entire operating system! It seems your mother never warned you that such levels of sarcasm usually results in permanent scarring... Let me guess, you're British (or at least somewhere in the UK). ;-) I'm impressed.
Re: browser security
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Morgan Sent: Wednesday, December 14, 2005 2:32 PM To: J.C. Roberts Cc: misc@openbsd.org Subject: Re: browser security On 14/12/05, J.C. Roberts [EMAIL PROTECTED] wrote: When you think about all the crap a graphical browser needs just to run (fonts, mime types, library dependencies, plugins, cache, user preferences, ...), it will probably be a major pain to chroot the beast because you'll be duplicating tons of stuff into your chroot. At that point, you have only gained a copy of your file system rather than any real security. Worse yet many browsers are actually dual purpose and function as the system file manager within the windowing environment (windows/MSIE, KDE/konqueror, gnome/?, and so on...). If you actually manage to successfully chroot all your browsers to prevent accidentally clicking on a bad link, you suddenly don't have a file manager and have lost a lot of usability. I've just had the most awesome idea: chroot the entire operating system! Here you go: http://cisx1.uma.maine.edu/~wbackman/vmware-images/ OpenBSD 3.8 default install image for the free VMWare player. Of course, it only includes the lynx web browser, but it is hard to get more secure than that!
Re: browser security
On Wednesday 14 December 2005 19:48, Bob Smith wrote: Just a thought: sudo -u $some_restricted_user $your_preffered_browser ? good that you brought this up; i been wondering about this too. does it help? if so how come there isnt a default non-privileged user created for, say, firefox when the pkg is installed? like there is for bitlbee (_bitlbee) or tcpdump (_tcpdump)? Does it help? Well, a bit, I would guess. One thing, if you run it as another user, (depending on your home permissions) it shouldn't have access to your files. With restrictive enough permissions it won't be able to install anything - but then again, neither will you. Why having one separate user for that is a bad idea? Because usually each user has his/her own preferences, plugins, bookmarks. Now everyone runs browser as same user Oops. -- viq -- Zobacz finalistki Miss World!!! http://link.interia.pl/f18e8
Re: browser security
On Wed, 2005-12-14 at 21:58 +0100, viq wrote: On Wednesday 14 December 2005 19:48, Bob Smith wrote: Just a thought: sudo -u $some_restricted_user $your_preffered_browser ? good that you brought this up; i been wondering about this too. does it help? if so how come there isnt a default non-privileged user created for, say, firefox when the pkg is installed? like there is for bitlbee (_bitlbee) or tcpdump (_tcpdump)? Does it help? Well, a bit, I would guess. systrace could provide an effective jail for firefox. 'man systrace'.
Re: browser security
Bob Smith wrote: vmware recently released a program which kind of chroot jails the browser. http://www.vmware.com/vmtn/vm/browserapp.html im not a programmer myself, but i was wondering if perhaps using a similar technique we could lock down the browsers in openbsd? seems to me that would increase security greatly for us who surf the web on openbsd boxes? or am i mistaking? Isn't this a mute point. I mean, unless you are surfing the web as root, any remote browser exploit would only effect the user and a logoff and login again would sort out *most* problems associated with remote exploits. Bareing in mind, that most remote browser exploits require you to be running windows as it is the windows / browser intergration which contains bugs. I just figure that the same reason *nix is not plagued by virii is the same reason chroot/vitual machined browsers are unnessacary and wouldn't increase security, only complexity. And it is through complexity that flaws are created and exploited.
Re: browser security
On Wed, Dec 14, 2005 at 11:50:53AM -0500, Will H. Backman wrote:
Anyone dare try making a systrace policy for firefox?
and where's difficulty in writting such policy? It's 20'' of work: use
``wizard'' or automatic policy generation, and then clean up the ruleset
looking through syscalls and changing `eq' to `match'; for example
cleaning up fsread's on libs or font dirs and fs{read,write,rename} on
cache/download dir, and so on...
- Lukasz Sztachanski
--
0x058B7133 // 16AB 4EBC 29DA D92D 8DBE BC01 FC91 9EF7 058B 7133
http://szati.blogspot.com
http://szati.entropy.pl
Re: browser security
On 14/12/05, Fletch [EMAIL PROTECTED] wrote: Isn't this a mute point. I mean, unless you are surfing the web as root, any remote browser exploit would only effect the user and a logoff and login again would sort out *most* problems associated with remote exploits. Once a remote attacker has access to your machine just think of all those lovely local exploits he can now run to bump up his privileges. I could say that *all* remote exploits are root exploits, but that sounds very sensationalist so I won't. Bareing in mind, that most remote browser exploits require you to be running windows as it is the windows / browser intergration which contains bugs. Not AFAIK. Remove a piece of shit from a turd and you're still left with a heap of shit.
Re: browser security
On Wednesday 14 December 2005 23:15, James Strandboge wrote: systrace could provide an effective jail for firefox. 'man systrace'. Yes, it was mentioned, and it sounds like a good idea. While we're at systrace, I was wondering - could systrace reduce the risks associated with running apache with PHP? -- viq Szukasz pracy? Szukamy pracownikow: dziennikarzy, webmasterow, specjalisty ds. badan, promotion managera, administratorow baz danych, programistow Windows i wielu innych! http://link.interia.pl/f18e6
Re: browser security
On Wed, 2005-12-14 at 23:38 +0100, viq wrote: On Wednesday 14 December 2005 23:15, James Strandboge wrote: systrace could provide an effective jail for firefox. 'man systrace'. Yes, it was mentioned, and it sounds like a good idea. While we're at systrace, I was wondering - could systrace reduce the risks associated with running apache with PHP? Default apache is already chrooted, so systracing it won't be as much of a win as systracing processes not in a chroot. That said, you can definitely add another layer and protect your apache chroot area by systracing it, sure. chrooting and/or systracing every internet facing server is not a bad idea at all. Jamie
Re: browser security
On Thu, 2005-12-15 at 03:02 +0100, Andreas Bartelt wrote: Hi, James Strandboge wrote: ... While we're at systrace, I was wondering - could systrace reduce the risks associated with running apache with PHP? Default apache is already chrooted, so systracing it won't be as much of a win as systracing processes not in a chroot. That said, you can definitely add another layer and protect your apache chroot area by systracing it, sure. chrooting and/or systracing every internet facing server is not a bad idea at all. Apache forks children with reduced priviledges (user www) while, at the same time, there's always an Apache process running as root. Therefore, a useful systrace policy for Apache probably won't be easy to write. No, apache is not running as root, parent or children: $ ps auxww|grep [h]ttpd www 2651 0.0 0.3 1736 3368 ?? Ss 4Dec050:17.69 httpd: parent [chroot /var/www] (httpd) www 10443 0.0 0.3 1872 2612 ?? I 4Dec050:00.11 httpd: child (httpd) www 17711 0.0 0.3 1872 2564 ?? I 4Dec050:00.46 httpd: child (httpd) www 23046 0.0 0.3 1864 2644 ?? I 4Dec050:00.17 httpd: child (httpd) www 24669 0.0 0.3 1860 2564 ?? I 4Dec050:00.13 httpd: child (httpd) www641 0.0 0.3 1852 2604 ?? I 4Dec050:00.19 httpd: child (httpd) www 25713 0.0 0.2 1840 2432 ?? I 4Dec050:00.25 httpd: child (httpd) www 13373 0.0 0.3 1860 2608 ?? I 4Dec050:00.09 httpd: child (httpd) www 11325 0.0 0.3 1860 2616 ?? I 4Dec050:00.14 httpd: child (httpd) www 31995 0.0 0.2 1836 2416 ?? I 4Dec050:00.22 httpd: child (httpd) www 25412 0.0 0.3 1864 2604 ?? I 4Dec050:00.23 httpd: child (httpd) As for systracing a process running as root-- I do it all the time and the benefits are an effective jail for a root process. If you are concerned about a root process using setuid to a uid with lower privilege, systrace can do that with no problem. Jamie
Re: browser security
Hi, James Strandboge wrote: On Thu, 2005-12-15 at 03:02 +0100, Andreas Bartelt wrote: ... Apache forks children with reduced priviledges (user www) while, at the same time, there's always an Apache process running as root. Therefore, a useful systrace policy for Apache probably won't be easy to write. No, apache is not running as root, parent or children: You're right. Sorry for spreading wrong information... regards, Andreas
