Re: improving browser security
On 03/01/2015 01:36 PM, Ted Unangst wrote: Nevertheless, the policy is only advisory. Writeable executable memory is only an mmap or mprotect away. Thanks for your work. Is there a simple way to turn on enforcement W^X on a system, to see what breaks?
Re: Almost offtopic question to the Improving Browser Security question
On 2015-03-03, someone thisistheone8...@gmail.com wrote: Wow, copying the .Xauthority to the separated user worked! But I'm still thinking that the separated user can give out the command: xinput test 6 and can see what anyone types in via X. See xauth(1) about generating an untrusted auth token. If you're feeling lazy, enabling ssh X forwarding and using ssh -X user@localhost might be easier, but will be slower.
Almost offtopic question to the Improving Browser Security question
Hello, If I: pkg_add firefox-esr then I cannot see any separated user for it: grep -i firefox /etc/passwd When will OpenBSD have a separated user for the webbrowser by default? If someone gets in via the webbrowser... it will have the id_rsa, the *.kdb, etc. If it will not be default what are the solutions for the people to run their webbrowser with another user? $ su - foo Password: $ /usr/local/bin/firefox-esr Error: no display specified $ exit echo $DISPLAY :0 $ su - foo Password: export DISPLAY=:0 $ /usr/local/bin/firefox-esr No protocol specified No protocol specified Error: cannot open display: :0 $ Or is X so bad that it's not worth it? Can I run _several X servers_ on my notebook (separated from each other)? Ex.: CTRL+ALT+F2 would bring up the logged in user with it's own X server, and CTRL+ALT+F3 another.. Many thanks,
Re: Almost offtopic question to the Improving Browser Security question
Wow, copying the .Xauthority to the separated user worked! But I'm still thinking that the separated user can give out the command: xinput test 6 and can see what anyone types in via X. On Tue, Mar 3, 2015 at 5:56 PM, Ryan Freeman r...@slipgate.org wrote: On Tue, Mar 03, 2015 at 05:51:27PM +0100, someone wrote: Hello, If I: pkg_add firefox-esr then I cannot see any separated user for it: grep -i firefox /etc/passwd When will OpenBSD have a separated user for the webbrowser by default? I think Ted specifically stated that jailing the browser under its own user was outside the scope of what he was intending to do.. If someone gets in via the webbrowser... it will have the id_rsa, the *.kdb, etc. If it will not be default what are the solutions for the people to run their webbrowser with another user? $ su - foo Password: $ /usr/local/bin/firefox-esr Error: no display specified $ exit echo $DISPLAY :0 $ su - foo Password: export DISPLAY=:0 $ /usr/local/bin/firefox-esr No protocol specified No protocol specified Error: cannot open display: :0 $ You'll need to copy the .Xauthority file from your main user (the one running X) to ~foo/.Xauthority From there, you can then run X apps as foo and they should work just fine. Or is X so bad that it's not worth it? Can I run _several X servers_ on my notebook (separated from each other)? Ex.: CTRL+ALT+F2 would bring up the logged in user with it's own X server, and CTRL+ALT+F3 another.. Many thanks,
Re: Almost offtopic question to the Improving Browser Security question
On Tue, Mar 03, 2015 at 05:51:27PM +0100, someone wrote: Hello, If I: pkg_add firefox-esr then I cannot see any separated user for it: grep -i firefox /etc/passwd When will OpenBSD have a separated user for the webbrowser by default? I think Ted specifically stated that jailing the browser under its own user was outside the scope of what he was intending to do.. If someone gets in via the webbrowser... it will have the id_rsa, the *.kdb, etc. If it will not be default what are the solutions for the people to run their webbrowser with another user? $ su - foo Password: $ /usr/local/bin/firefox-esr Error: no display specified $ exit echo $DISPLAY :0 $ su - foo Password: export DISPLAY=:0 $ /usr/local/bin/firefox-esr No protocol specified No protocol specified Error: cannot open display: :0 $ You'll need to copy the .Xauthority file from your main user (the one running X) to ~foo/.Xauthority From there, you can then run X apps as foo and they should work just fine. Or is X so bad that it's not worth it? Can I run _several X servers_ on my notebook (separated from each other)? Ex.: CTRL+ALT+F2 would bring up the logged in user with it's own X server, and CTRL+ALT+F3 another.. Many thanks,
Re: Almost offtopic question to the Improving Browser Security question
http://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxed-linux-desktop-app/ h, great, looks like X is not soo good regarding security.. maybe Wayland.. On Tue, Mar 3, 2015 at 6:09 PM, someone thisistheone8...@gmail.com wrote: Wow, copying the .Xauthority to the separated user worked! But I'm still thinking that the separated user can give out the command: xinput test 6 and can see what anyone types in via X. On Tue, Mar 3, 2015 at 5:56 PM, Ryan Freeman r...@slipgate.org wrote: On Tue, Mar 03, 2015 at 05:51:27PM +0100, someone wrote: Hello, If I: pkg_add firefox-esr then I cannot see any separated user for it: grep -i firefox /etc/passwd When will OpenBSD have a separated user for the webbrowser by default? I think Ted specifically stated that jailing the browser under its own user was outside the scope of what he was intending to do.. If someone gets in via the webbrowser... it will have the id_rsa, the *.kdb, etc. If it will not be default what are the solutions for the people to run their webbrowser with another user? $ su - foo Password: $ /usr/local/bin/firefox-esr Error: no display specified $ exit echo $DISPLAY :0 $ su - foo Password: export DISPLAY=:0 $ /usr/local/bin/firefox-esr No protocol specified No protocol specified Error: cannot open display: :0 $ You'll need to copy the .Xauthority file from your main user (the one running X) to ~foo/.Xauthority From there, you can then run X apps as foo and they should work just fine. Or is X so bad that it's not worth it? Can I run _several X servers_ on my notebook (separated from each other)? Ex.: CTRL+ALT+F2 would bring up the logged in user with it's own X server, and CTRL+ALT+F3 another.. Many thanks,
Re: improving browser security
On 03/01/2015 10:36 AM, Ted Unangst wrote: A few words about a project I've started working on today with support from the OpenBSD Foundation. This is a good idea. I just threw some more coin in the donations bin. At the risk of feature creep: There was a thread on this list about browser installation such that it would, for each user be sandboxed in a clean room, denying any scripts access to the users files. I don't know if this is at all appropriate for this project, and I just throw it out there for consideration. http://marc.info/?l=openbsd-miscm=141710381310891w=2 -- Those who do not understand Unix are condemned to reinvent it, poorly.
Re: improving browser security
At the risk of feature creep: There was a thread on this list about browser installation such that it would, for each user be sandboxed in a clean room, denying any scripts access to the users files. I don't know if this is at all appropriate for this project, and I just throw it out there for consideration. http://marc.info/?l=openbsd-miscm=141710381310891w=2 I think Ted is going to fix the so called we do 64 bit random and we are 64 bit lies that browser JITs say they do. I remember when Ariane applied the commits, browsers failed spectacularly. Please correct me if i am wrong. espie@ original email http://marc.info/?l=openbsd-miscm=130683944229077w=2 naddy@ detailed explanation http://marc.info/?l=openbsd-miscm=130687174807002w=2 otto@ http://marc.info/?l=openbsd-miscm=130687174807002w=2 deraadt@ http://marc.info/?l=openbsd-miscm=130687281908151w=2
improving browser security
A few words about a project I've started working on today with support from the OpenBSD Foundation. As you may know, OpenBSD has a W^X (write xor execute) policy for memory. This mitigates many forms of exploit, either by preventing the exploit from overwriting the program's executable code or preventing the exploit from directing control flow to memory it has modified. Many components of OpenBSD, from the kernel to the toolchain to runtime components like libc and ld.so, work together to maintain the W^X invariant. Nevertheless, the policy is only advisory. Writeable executable memory is only an mmap or mprotect away. The policy has remained advisory because many JIT engines use such memory and enforcing mandatory W^X would mean such programs no longer run on OpenBSD. At the time W^X was introduced, even just the simple change of marking memory non-executable by default required patches to many programs which assumed all memory (even including the stack) was exectuable by default. This is rather unfortunate because it undermines what we're trying to build. A system that is all W^X except where it's not is the same as a system that's not W^X. We've worked hard to provide a secure foundation for programs; we'd like to see them take advantage of it. Which brings me to my new project. The most egregious violator of the W^X policy on many users' systems will be their browser. We cannot enforce a stricter W^X policy until at least one browser is fixed. To that end, the Foundation has hired me to make the necessary changes. The project has only started today, so there's not much more to announce other than its start, but I wanted to let people know what's up. More updates to follow as things actually happen. The intitial focus is on browser JIT engines, because that's on the critical path to any policy change, although the end result should be improved security for everyone. One may reasonably ask, since the advent of ROP exploits, whether non-exec memory is still an effective exploit mitigation? I say surely yes. ROP was developed in part because non-exec memory made simpler exploit techniques obsolete. The development of more advanced exploits does not mean we need to tolerate simpler exploits as well. Instead, we should always work to make things as difficult to exploit as possible, even if we can't reach impossible. I'd like to thank the OpenBSD Foundation for supporting this effort, and the many donors who have supported the Foundation. The Foundation wouldn't be in a position to support projects like this if it weren't for you.
Re: improving browser security
On Sun, March 1, 2015 1:36 pm, Ted Unangst wrote: I'd like to thank the OpenBSD Foundation for supporting this effort, and the many donors who have supported the Foundation. The Foundation wouldn't be in a position to support projects like this if it weren't for you. My thanks, as well. I've always hoped for OBSD to help tackle the browser situation. On my way to the donation page in support of this effort. Tim.
