Re: users, private groups, and The Unix Way (was, Re: Is it me or is it sudo?)
On Tue, Apr 3, 2012 at 5:47 PM, Bryn M. Reeves b...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 08:10 AM, Joel Rees wrote: On Tue, Apr 3, 2012 at 3:27 PM, Tim ignored_mail...@yahoo.com.au wrote: s/some/a lot of/ if you set it up right. It can still do a fair amount of nasty stuff. xhost local:subuser-id; sudo -u subuser-id does pretty well with current applications. You're allowing the local sandbox user to connect to the local X server so any process running in one of your sandboxes can start a connection to X and start looking for vulnerabilities to exploit. Of which X11 still has its share, we are told. Humor me. Does running firefox this way, as a different user on the same machine, increase risks, as compared to running firefox as the user you are logged in as? If so, how? Due to the elevated privilege with which X runs this could include privilege escalations. Okay, so why doesn't Fedora drop privileges on Xorg like a certain BSD does? There have been vulnerabilities of this kind in the past that allowed an attacker to quickly gain a root shell given the ability to connect to the X server. Well, sure. That's going to happen when you run a server as root. But does it open holes to run the application accessing X as a different user? ergo, holes that wouldn't be open when running the same application as the user you logged in as? Now, if I'm going to my bank site, I do log out and log in as a different user, just to be extra safe. Now, I want to make it clear that I recognize that, if the bad guys have succeeded in taking over the bank site, restricting my internet banking access to an account that I do nothing else with doesn't protect me, relative to that bank. It may keep up some speed bumps and low walls relative to attacks on my machine, of course. I think you'd be better off taking a look at Daniel Walsh's blog posts on confining X applications with the SELinux sandbox. The first post introduces and explains the general sandbox concept: I am familiar with the sandbox principle, in several versions, thank you. Not that one more point of view or version ever hurt. http://danwalsh.livejournal.com/28545.html This blog could help me figure out SELinux's ACL tools, which, if I continue to use Fedora, it looks like I'll have to learn to use. In self-defense, if for no other reason. And the follow up looks at extending this to untrusted X applications using a temporary xguest account (with dynamic $HOME and $TMP) and the Xephyr X-on-X server to provide much stronger separation between the sandbox and the rest of the system: http://danwalsh.livejournal.com/31146.html I notice that he is using mount-over tricks to augment the protections. Fancy or funky? I'll have to re-read that when I have time. Fedora already provides contexts to use with the sandbox such as sandbox_x_t, sandbox_web_t, sandbox_net_t etc. depending on the particular resources you want to allow the sandbox to access. You know, one of the problems with ACLs (and capabilities) is getting them set up right. And you know how it ends up? Well, as you say, and as Walsh acknowledges, The post discusses future improvements to simplify retrieving files from the sandbox when the application exits but I'm not sure of the current status of that work. I've been trying to avoid what I'm sure amounts to blasphemy in the eyes of some on these lists, but I am not particularly fond of SELinux. Way too many convolutions to hide bugs in. If X11 must be assumed to have bugs, so much more, the more recent and more complicated SELinux, especially in the patterns by which the tools to set policy are run. I'm going to prefer to trust tools I can understand. -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: users, private groups, and The Unix Way (was, Re: Is it me or is it sudo?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 01:15 PM, Joel Rees wrote: On Tue, Apr 3, 2012 at 5:47 PM, Bryn M. Reeves b...@redhat.com wrote: You're allowing the local sandbox user to connect to the local X server so any process running in one of your sandboxes can start a connection to X and start looking for vulnerabilities to exploit. Of which X11 still has its share, we are told. Humor me. Does running firefox this way, as a different user on the same machine, increase risks, as compared to running firefox as the user you are logged in as? If so, how? If the reason you are running the separate browser is to visit sites that you do not trust sufficiently to visit from your main user session then yes because the browser (and in turn X) is now exposed to those sites. If your choice is or do nothing and run them in the normal session then of course there is no difference. Due to the elevated privilege with which X runs this could include privilege escalations. Okay, so why doesn't Fedora drop privileges on Xorg like a certain BSD does? I'm no X expert but historically the X server needed root privileges to use vm86 mode to interact with the video BIOS and to access the IO ports for the card so KMS for all drivers at least is required to be able to support this. OpenBSD modifies the Xorg source to allow privilege separation and this work has not made its way upstream (which is a problem for Fedora to include it). There are also legitimate questions about how useful all of this is; although OpenBSD provides their aperture driver to minimize the address space the X server can access Theo de Raadt has said this is just the best we can do. OpenBSD also provides a vesafb driver that permits an unprivileged X server with no aperture driver but acceleration is not supported and performance suffers as a consequence. Well, sure. That's going to happen when you run a server as root. But does it open holes to run the application accessing X as a different user? ergo, holes that wouldn't be open when running the same application as the user you logged in as? Yes; if you don't trust those applications or the data (sites) they operate on then you have a possible avenue for attacks. This is the point of sandbox -X. This blog could help me figure out SELinux's ACL tools, which, if I continue to use Fedora, it looks like I'll have to learn to use. In self-defense, if for no other reason. SELinux doesn't provide ACLs (Linux ACLs are primarily a file system feature that's independent of other security frameworks in use). I notice that he is using mount-over tricks to augment the protections. Fancy or funky? I'll have to re-read that when I have time. Just sane. Linux has supported per-process mount namespaces for a very long time. They provide far stronger isolation than other methods. They're also worth getting to know as they are useful for many other tasks too. You know, one of the problems with ACLs (and capabilities) is getting them set up right. And you know how it ends up? Well, as you say, and as Walsh acknowledges, Use it/don't use it - it's up to you. I've used SELinux sandboxes and I find them very easy to use and considerably less maintenance effort than roll-your-own. YMMV of course but I prefer not to invent my own solutions to security problems when there are off the shelf answers that were developed by people who work on this stuff every day. There's also a tonne of good documentation for SELinux these days from basic administration to troubleshooting and advanced policy development: http://fedoraproject.org/wiki/SELinux I've been trying to avoid what I'm sure amounts to blasphemy in the eyes of some on these lists, but I am not particularly fond of SELinux. Way too many convolutions to hide bugs in. If X11 must be assumed to have bugs, so much more, the more recent and It's been around for well over a decade now and is pretty mature. Bugs still happen but I think they're no more troublesome than bugs in any other complex subsystem these days. The SELinux folks I know are also very responsive and helpful when dealing with user problems. more complicated SELinux, especially in the patterns by which the tools to set policy are run. Not sure which X sources you've looked at but this certainly isn't my impression of the two projects. The xorg-x11 sources weigh in at over 500,000 loc just for the server. Adding libX11 and a few other libraries quickly takes you over 750k. Adding up security/selinux from the kernel sources along with policycoreutils and libselinux you come to about 68,000 (and that's including all the pcu python stuff - without that you can take another 20,000 off). Even if you include the reference policy specs it's less than a quarter million lines. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Re: users, private groups, and The Unix Way (was, Re: Is it me or is it sudo?)
On Tue, Apr 3, 2012 at 10:24 PM, Bryn M. Reeves b...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 01:15 PM, Joel Rees wrote: On Tue, Apr 3, 2012 at 5:47 PM, Bryn M. Reeves b...@redhat.com wrote: You're allowing the local sandbox user to connect to the local X server so any process running in one of your sandboxes can start a connection to X and start looking for vulnerabilities to exploit. Of which X11 still has its share, we are told. Humor me. Does running firefox this way, as a different user on the same machine, increase risks, as compared to running firefox as the user you are logged in as? If so, how? If the reason you are running the separate browser is to visit sites that you do not trust sufficiently to visit from your main user session then yes because the browser (and in turn X) is now exposed to those sites. Good point. I don't visit those sites, and it's important for me to mention that. No p0rn, period, and many of the moral reasons are in fact parallels of the technical reasons. Well, sometimes I have to go to some sites that I don't really trust that much, and I have a user I have dedicated to such uses. For example, Kickstarter. When I'm logged in there, I'll be on one of my work users. (Stupid Flash.) But when I'm browsing other projects, many of the links are offsite, so I shift to the subuser to browse projects, and if I need to link off-site, I'll log out and log in to the dedicated play user. Still not as good as having a separate machine, but better than nothing. If your choice is or do nothing and run them in the normal session then of course there is no difference. I think there is some difference. If I hit a drive-by when I'm browsing via a sub-user, for instance, the malicious payload will be in the subuser's directory tree. Again not perfect, but a bit of a higher wall than a speed bump. Due to the elevated privilege with which X runs this could include privilege escalations. Okay, so why doesn't Fedora drop privileges on Xorg like a certain BSD does? I'm no X expert but historically the X server needed root privileges to use vm86 mode to interact with the video BIOS and to access the IO ports for the card so KMS for all drivers at least is required to be able to support this. Yeah. OpenBSD modifies the Xorg source to allow privilege separation and this work has not made its way upstream (which is a problem for Fedora to include it). License issues? Getting the source should be now problem. There are also legitimate questions about how useful all of this is; although OpenBSD provides their aperture driver to minimize the address space the X server can access Theo de Raadt has said this is just the best we can do. What he means by that is a bit different from what you would mean by that. True, there are ways through that aperture, or around, but it's a bit of a higher wall than a speedbump. Would take some serious programming to defeat, enough so that social engineering or bruteforcing tend to be preferred. Unless you have someone specifically targeting your network, in which case, you really have to restrict what you do on your workstations. OpenBSD also provides a vesafb driver that permits an unprivileged X server with no aperture driver but acceleration is not supported and performance suffers as a consequence. Yeah, it's going to be relatively slow. But it would be nice to have that as an option. (Most of what I do would not suffer significantly.) Well, sure. That's going to happen when you run a server as root. But does it open holes to run the application accessing X as a different user? ergo, holes that wouldn't be open when running the same application as the user you logged in as? Yes; if you don't trust those applications or the data (sites) they operate on then you have a possible avenue for attacks. Kind of like seatbelts. You have to regularly ask yourself if they encourage dangerous driving, and check your habits if you're getting sloppy. This is the point of sandbox -X. Which would be nice if I trusted ACLs. This blog could help me figure out SELinux's ACL tools, which, if I continue to use Fedora, it looks like I'll have to learn to use. In self-defense, if for no other reason. SELinux doesn't provide ACLs (Linux ACLs are primarily a file system feature that's independent of other security frameworks in use). Wait. Doesn't provide or doesn't use? If neither, how does it implement those policies that I never can get right? I thought those policies were just a way to compile those lousy ACLs so you wouldn't be spending more time setting the ACLs than doing actual work. I notice that he is using mount-over tricks to augment the protections. Fancy or funky? I'll have to re-read that when I have time. Just sane. Linux has supported per-process mount namespaces for a very long time. They provide far stronger isolation than other methods. They're
Re: users, private groups, and The Unix Way (was, Re: Is it me or is it sudo?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 04:56 PM, Joel Rees wrote: Good point. I don't visit those sites, and it's important for me to mention that. No p0rn, period, and many of the moral reasons are in There are a lot of perfectly family-friendly websites whose administrators I do not trust as far as I could throw them (even if I knew where they were). in the subuser's directory tree. Again not perfect, but a bit of a higher wall than a speed bump. If the payload targets an X vulnerability there is no difference. License issues? Getting the source should be now problem. Upstream first - Fedora goes out of its way to get new features into the distribution by getting them into the projects it packages upstream (often by doing the work upstream). There are occasional exceptions but it's very unusual for Fedora to take a large set of changes from another downstream packager before they get merged. address space the X server can access Theo de Raadt has said this is just the best we can do. What he means by that is a bit different from what you would mean by that. Thank you for enlightening as to what I meant (although what you assume I mean by that may not be the same as what I actually meant when I wrote it). to defeat, enough so that social engineering or bruteforcing tend to be preferred. Unless you have someone specifically targeting your network, in which case, you really have to restrict what you do on That's not the case at all. It's just a more constrained interface to the same thing (and Linux is fairly restrictive about that these days too). A smaller attack surface doesn't mean that you need targeted attacks; almost certainly if someone discovered an exploitable flaw in this it could be developed into an easily deployed local exploit just like any other. What I understood from Theo's statement is that while it tightens some avenues for exploit development the basic model of exposing hardware to a userspace process (privileged or not) is broken. Not everybody agrees but there is a lack of a usable alternative right now. He also goes on to state that X: violates all the security models you will hear of in a university class. due to the exposure of the device registers, memory space and I/O ports to userspace (drivers in userspace model) and that the X developers are a bunch of shameless vendor-loving lapdogs who sure are taking their time at solving this 10 year old problem. I am sure such words would motivate me to help him if I worked on X. Yeah, it's going to be relatively slow. But it would be nice to have that as an option. (Most of what I do would not suffer significantly.) There are vesa drivers in Fedora. I have no idea how difficult it would be to coax them into running unprivileged but if it interests you you might want to look into it. Kind of like seatbelts. You have to regularly ask yourself if they encourage dangerous driving, and check your habits if you're getting sloppy. The evidence base disagrees here. Multiple studies find large declines in casualty figures following introduction of mandatory seatbelt laws: http://jech.highwire.org/content/43/3/218.full.pdf http://tinyurl.com/bu6ymdn [jstor] Which would be nice if I trusted ACLs. But you trust the kernel, Xorg and Firefox which are considerably larger and more complex beasts? Ok... I thought those policies were just a way to compile those lousy ACLs so you wouldn't be spending more time setting the ACLs than doing actual work. Not quite: SELinux provides a framework for defining access control policies based on users, roles and types (aka domains). The policy defines what actions a given user/role/type combination is permitted to carry out. Daemons and other confined processes are placed in a specific domain to limit their access to system resources according to the policy: http://en.wikipedia.org/wiki/Security-Enhanced_Linux You can use this to implement RBAC, MCS, MLS etc. SELinux contexts are stored along side files in the file system as extended attributes (xattrs) - i.e. it's label-based rather than path-based security. Xattrs are also used for ACLs in many file systems so that may be where the confusion arises. ACLs usually refer to access control lists - most often file system ACLs although there are many other uses of the term e.g. BIND DNS ACLs or Microsoft Windows fs ACLs mapped through Samba/CIFS. An ACL is just a list of identities and the level of access they are permitted. Fs ACLs are available with any modern Linux file system and operate independently from any LSM security framework in use. Per-process could be an interesting, might be able to combine that with other things I do. Check out pam_namespace which does per-session namespaces (and probably more now, it's been a while). There's a post from Russell Coker discussing it here: http://etbe.coker.com.au/2008/12/13/per-process-namespaces-pam-namespace/ Well, if I were inventing,
Re: users, private groups, and The Unix Way (was, Re: Is it me or is it sudo?)
On Wed, Apr 4, 2012 at 2:05 AM, Bryn M. Reeves b...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 04:56 PM, Joel Rees wrote: Good point. I don't visit those sites, and it's important for me to mention that. No p0rn, period, and many of the moral reasons are in There are a lot of perfectly family-friendly websites whose administrators I do not trust as far as I could throw them (even if I knew where they were). Exactly. I guess, though, that I am willing to use a separate login on those sites, rather than separate hardware on a separate segment of the internal network at home. At work, it would depend on what I'm working on. in the subuser's directory tree. Again not perfect, but a bit of a higher wall than a speed bump. If the payload targets an X vulnerability there is no difference. I assume that payloads that target the X vulnerability are significantly fewer. Not perfect, but you match the measures with the threat and your budget. License issues? Getting the source should be now problem. Upstream first - Fedora goes out of its way to get new features into the distribution by getting them into the projects it packages upstream (often by doing the work upstream). There are occasional exceptions but it's very unusual for Fedora to take a large set of changes from another downstream packager before they get merged. Woops. Guess I was forgetting that Fedora is not maintaining its own X11. address space the X server can access Theo de Raadt has said this is just the best we can do. What he means by that is a bit different from what you would mean by that. Thank you for enlightening as to what I meant (although what you assume I mean by that may not be the same as what I actually meant when I wrote it). Well, from where I sit, I have to guess that the openbsd engineers doing the aperture work are a bit more on top of the technical details than you. And I think you admit that. That's the gap I'm talking about. It is a relatively high wall, compared to some walls. to defeat, enough so that social engineering or bruteforcing tend to be preferred. Unless you have someone specifically targeting your network, in which case, you really have to restrict what you do on That's not the case at all. It's just a more constrained interface to the same thing (and Linux is fairly restrictive about that these days too). A smaller attack surface doesn't mean that you need targeted attacks; almost certainly if someone discovered an exploitable flaw in this it could be developed into an easily deployed local exploit just like any other. But tell me about real exploits. What I understood from Theo's statement is that while it tightens some avenues for exploit development the basic model of exposing hardware to a userspace process (privileged or not) is broken. Not everybody agrees but there is a lack of a usable alternative right now. Theo is dead right on that. Intel failed us on the processor design and only recently accepted the responsibility of providing MMU functions to enable making executable store non-writeable. There's a long way to go there, and, while the old 68K had the MMU capability in the architecture, competing with INTEL pushed the industry to fail to support it in the circuitry external to the CPU. And then, when the graphics processor manufacturers started up, there was no pressure to get it right, and a lot of pressure to not bother. Excessive competition is as much a sin as deliberate fraud. As is complacency (and collaboration) on the part of the OS vendors. (I say plural because there were alternatives to Microsoft in the mid-80s.) He also goes on to state that X: violates all the security models you will hear of in a university class. due to the exposure of the device registers, memory space and I/O ports to userspace (drivers in userspace model) and that the X developers are a bunch of shameless vendor-loving lapdogs who sure are taking their time at solving this 10 year old problem. I am sure such words would motivate me to help him if I worked on X. Since soft words have failed to motivate the vendors, hard words are necessary. Yeah, it's going to be relatively slow. But it would be nice to have that as an option. (Most of what I do would not suffer significantly.) There are vesa drivers in Fedora. I have no idea how difficult it would be to coax them into running unprivileged but if it interests you you might want to look into it. Wish I had time. I don't really have time to be writing this. Kind of like seatbelts. You have to regularly ask yourself if they encourage dangerous driving, and check your habits if you're getting sloppy. The evidence base disagrees here. Multiple studies find large declines in casualty figures following introduction of mandatory seatbelt laws: http://jech.highwire.org/content/43/3/218.full.pdf http://tinyurl.com/bu6ymdn [jstor] I'm not going to log
users, private groups, and The Unix Way (was, Re: Is it me or is it sudo?)
On Sat, Mar 31, 2012 at 7:04 PM, Tim ignored_mail...@yahoo.com.au wrote: On Fri, 2012-03-30 at 20:39 +0100, James Wilkinson wrote: From there, it follows that the easiest way to do this is to make 002 the default umask, which means that all new files and directories created by normal users have these permissions. That means that if you want files that only their owner can write to, you need a per-user group. It always struck me that personal files ought to have no group or world permissions set by default. If you wanted your files to have those extra permission set, then it ought to be done as a deliberate choice. Maybe user-id is mis-named. There are sure a lot of people who tend to see user-id and expect the one-to-one correspondence. I know the conflation caused me some frustration back in college, and I'm not sure I got it properly worked out until I put together a few openbsd systems. Anyway, it should be clear that a system administrator should not be logged in as a system administrator when he or she is just writing an e-mail scheduling meetings or something. But even ordinary (human) users should not be surfing the web as the user they logged in as, and I'm not talking about keeping my boss from checking my cache for visits to slashdot or whatever. As the system administrator for my home box, I want to be able to log in as a normal user that is not tainted by my the web sites I visited last time I logged in. That means I have a separate administrator user. I want one user-id/group-id pair for each bank I have to visit, so that, even if we can't get the banks to use special-purpose browsers for the money transactions, I can protect the bank data from the guys that want to mine my data for their gain, including the other banks. (Special purpose browsers are preferred, of course.) And when I need to go surfing through blogs for news, I don't want to do that with the user I logged in as. Even if/when we can get rid of the sloppy programming practices Microsoft and their ilk promote, we can't be sure we have every hole plugged, so it's just going to be safer to do that as a user that isn't allowed to log in. That means that, even though I log out of my worker user and log back in as my play user, I still want to spawn a nologin user from there to surf. (This is not pure paranoia. I checked out a company for a job and discovered that Google had flagged their site as containing malware, and the guy who ran the company did not have the financial means or motivation to hire someone to clean the server up. Scared of having to move off the vulnerable tools he was using, trying to meet a market window that was fast disappearing, all the excuses.) Incidentally, I'm doing this much now, using xhost local and sudo. (If you're curious, http://reiisi.blogspot.jp/2011/08/simple-sandbox-for-firefox.html is my blog from when I first got it running. I need to re-write that explanation, which is part of the reason I'm writing this long-winded post now. But I still have issues with the input method that I need to solve. And I need to write some scripts so I don't have to all the tweaks by hand every time.) And I glue it together with per-user groups. Without per-user groups, I would have to go through serious admin-level contortions to grab a download. Does that make sense? -- Joel Rees -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
