X11 in a jail (was: Re: NFS mount inside jail fails)
Quoting Doug Ambrisko (from Wed, 25 May 2011 09:42:20 -0700 (PDT)): CCing jails@ Alexander Leidinger writes: | Quoting Doug Ambrisko (from Thu, 19 May 2011 | 14:38:40 -0700 (PDT)): | | > Alexander Leidinger writes: | > | On Thu, 19 May 2011 10:24:59 -0700 (PDT) Doug Ambrisko | > | wrote: | > | | > | > doesn't have access to it anymore either. Running an X server in a | > | > vimage has some issues. Most are pretty easy to over-come. | > | | > | Are you using my patch | > | (http://www.leidinger.net/FreeBSD/current-patches/0_jail.diff) + a | > | custom devfs.rules to get the 2D part (the last time I tried the DRI | > | part of my patch, it paniced the machine) of the X server working in a | > | jail, or did you come up with something yourself? If it is the later, I | > | would be interested how you did it. | > | > Nope, didn't know about it when I played with it. I should try it. | > I added | > case PRIV_IO: | > return (0); | > | > to kern_jail.c to get X to work. This was with the Intel graphics. | > The main problem I have now is on resume the X server dies and restarts. | > I use xdm. Without jail with vimage then it works okay. | | I use it without vimage in a jail. This is with a radeon card | (corresponding kernel module loaded at boot to get 2D acceleration, as | the X server obviously can not load modules in a jail). | | > My laptop can use either Intel or ATI graphics. I just switched it to | > ATI to see what happens. I should try some more tests. It seems | > my BIOS likes to reset this setting and enable both :-( | > | > I don't seem to have panics. This is with a month or so old -current. | | You do not allow access to the dri device, so I do not expect a panic. | If you give access to the dri device (which can be enabled separately | in my patch), I would not be surprised to see a panic (the last time I | tried it is a year or two ago, I didn't take the time to investigate | why it panics). Okay, I have an update. With Intel graphics and using dri things work better and I don't get panics. I load drm.ko & i915.ko before Just to make sure we talk about the same things: Did you configure the X server to use 3D (dri and glx in the modules section, dri section in the X11 config, dri device visible in devfs)? xdriinfo shows some valid hardware acceleration? If yes, I definitively have to test the 3D part again with my radeon (with a normal jail and with a vimage jail in case the normal jail fails). starting the vimage jail. X sees it and uses it. This solves the suspend/resume issue I had. The dri issue also prevented suspend and resume fail to work in a chroot. I have not tried switching to using the ATI option. On a plus side my laptop is running cooler and faster now. If you didn't had loaded i915.ko before, you have at least 2D accel now, and probably the power management of the chip got activated too. Bye, Alexander. -- Hope that the day after you die is a nice day. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: NFS mount inside jail fails
Alexander Leidinger writes: | Quoting Doug Ambrisko (from Thu, 19 May 2011 | 14:38:40 -0700 (PDT)): | | > Alexander Leidinger writes: | > | On Thu, 19 May 2011 10:24:59 -0700 (PDT) Doug Ambrisko | > | wrote: | > | | > | > doesn't have access to it anymore either. Running an X server in a | > | > vimage has some issues. Most are pretty easy to over-come. | > | | > | Are you using my patch | > | (http://www.leidinger.net/FreeBSD/current-patches/0_jail.diff) + a | > | custom devfs.rules to get the 2D part (the last time I tried the DRI | > | part of my patch, it paniced the machine) of the X server working in a | > | jail, or did you come up with something yourself? If it is the later, I | > | would be interested how you did it. | > | > Nope, didn't know about it when I played with it. I should try it. | > I added | > case PRIV_IO: | > return (0); | > | > to kern_jail.c to get X to work. This was with the Intel graphics. | > The main problem I have now is on resume the X server dies and restarts. | > I use xdm. Without jail with vimage then it works okay. | | I use it without vimage in a jail. This is with a radeon card | (corresponding kernel module loaded at boot to get 2D acceleration, as | the X server obviously can not load modules in a jail). | | > My laptop can use either Intel or ATI graphics. I just switched it to | > ATI to see what happens. I should try some more tests. It seems | > my BIOS likes to reset this setting and enable both :-( | > | > I don't seem to have panics. This is with a month or so old -current. | | You do not allow access to the dri device, so I do not expect a panic. | If you give access to the dri device (which can be enabled separately | in my patch), I would not be surprised to see a panic (the last time I | tried it is a year or two ago, I didn't take the time to investigate | why it panics). Okay, I have an update. With Intel graphics and using dri things work better and I don't get panics. I load drm.ko & i915.ko before starting the vimage jail. X sees it and uses it. This solves the suspend/resume issue I had. The dri issue also prevented suspend and resume fail to work in a chroot. I have not tried switching to using the ATI option. On a plus side my laptop is running cooler and faster now. Doug A. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: NFS mount inside jail fails
Quoting Doug Ambrisko (from Thu, 19 May 2011 14:38:40 -0700 (PDT)): Alexander Leidinger writes: | On Thu, 19 May 2011 10:24:59 -0700 (PDT) Doug Ambrisko | wrote: | | > doesn't have access to it anymore either. Running an X server in a | > vimage has some issues. Most are pretty easy to over-come. | | Are you using my patch | (http://www.leidinger.net/FreeBSD/current-patches/0_jail.diff) + a | custom devfs.rules to get the 2D part (the last time I tried the DRI | part of my patch, it paniced the machine) of the X server working in a | jail, or did you come up with something yourself? If it is the later, I | would be interested how you did it. Nope, didn't know about it when I played with it. I should try it. I added case PRIV_IO: return (0); to kern_jail.c to get X to work. This was with the Intel graphics. The main problem I have now is on resume the X server dies and restarts. I use xdm. Without jail with vimage then it works okay. I use it without vimage in a jail. This is with a radeon card (corresponding kernel module loaded at boot to get 2D acceleration, as the X server obviously can not load modules in a jail). My laptop can use either Intel or ATI graphics. I just switched it to ATI to see what happens. I should try some more tests. It seems my BIOS likes to reset this setting and enable both :-( I don't seem to have panics. This is with a month or so old -current. You do not allow access to the dri device, so I do not expect a panic. If you give access to the dri device (which can be enabled separately in my patch), I would not be surprised to see a panic (the last time I tried it is a year or two ago, I didn't take the time to investigate why it panics). Bye, Alexander. -- FORTUNE'S RULES TO LIVE BY: #2 Never goose a wolverine. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: NFS mount inside jail fails
On Thu, 19 May 2011 10:24:59 -0700 (PDT) Doug Ambrisko wrote: > doesn't have access to it anymore either. Running an X server in a > vimage has some issues. Most are pretty easy to over-come. Are you using my patch (http://www.leidinger.net/FreeBSD/current-patches/0_jail.diff) + a custom devfs.rules to get the 2D part (the last time I tried the DRI part of my patch, it paniced the machine) of the X server working in a jail, or did you come up with something yourself? If it is the later, I would be interested how you did it. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: NFS mount inside jail fails
Alexander Leidinger writes: | On Thu, 19 May 2011 10:24:59 -0700 (PDT) Doug Ambrisko | wrote: | | > doesn't have access to it anymore either. Running an X server in a | > vimage has some issues. Most are pretty easy to over-come. | | Are you using my patch | (http://www.leidinger.net/FreeBSD/current-patches/0_jail.diff) + a | custom devfs.rules to get the 2D part (the last time I tried the DRI | part of my patch, it paniced the machine) of the X server working in a | jail, or did you come up with something yourself? If it is the later, I | would be interested how you did it. Nope, didn't know about it when I played with it. I should try it. I added case PRIV_IO: return (0); to kern_jail.c to get X to work. This was with the Intel graphics. The main problem I have now is on resume the X server dies and restarts. I use xdm. Without jail with vimage then it works okay. My laptop can use either Intel or ATI graphics. I just switched it to ATI to see what happens. I should try some more tests. It seems my BIOS likes to reset this setting and enable both :-( I don't seem to have panics. This is with a month or so old -current. Doug A. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: NFS mount inside jail fails
Arnaud Lacombe writes: | Hi, | | On Wed, May 18, 2011 at 10:03 AM, Pawel Jakub Dawidek wrote: | > On Tue, May 17, 2011 at 10:17:12PM +0200, Alexander Leidinger wrote: | >> On Tue, 17 May 2011 12:56:40 -0700 Sean Bruno | >> wrote: | >> | >> > Silly thing I ran into today. ?User wanted to NFS mount a dir inside a | >> > jail. ?After I groaned about the security implication of this, I noted | >> > that there is a sysctl that looks like it should allow this. ?Namely, | >> > security.jail.mount_allowed. ?I noted that setting this follows a path | >> > that *should* have allowed this silly thing to happen, except that the | >> > credentials in the nfsclient were not setup correctly. | >> | >> As you noticed, this is supposed to allow to mount inside a jail, IF | >> the FS you want to mount is marked as secure/safe to do so. Nearly no | >> FS is marked as such, as nobody wants to guarantee that it is safe | >> (root in a jail should not be able to panic a system by trying to | >> mount a corrupt/malicious FS-image) and secure (not possible to get | >> elevated access/privileges). | >> | >> For NFS there is theoretically the problem that the outgoing address on | >> requests could be the one of the physical host instead of the IP of the | >> jail. If this is true in practice, I do not know. This could be | >> the reason why NFS is not marked with VFCF_JAIL. | > | > It is not marked with VFCF_JAIL, because I just had no time to audit | > that it is safe. It might be safe in theory. | > | > There are some file systems types that can't be securely mounted within | > a jail no matter what, like UFS, MSDOFS, EXTFS, XFS, REISERFS, NTFS, | > etc. ?because the user mounting it has access to raw storage and can | > corrupt it in a way that it will panic entire system. | | This should at least be configurable somehow for people who are using | jails for separation and do not care about security. I'd expect that | security decision whether or not to allow something is user relevant, | not developer relevant. Yes, we need to look at having sysctl's to enable more permissive options when jails/vimage are not used to isolate users from systems but other uses. I'm now starting to use vimage in 8.2 and -current to make my "host" trivial but do all of the "smarts" in a vimage. This lets me spin up a new image quickly and migrate. One challenge is wireless. You can't run wpa_supplicant in a vimage. I can understand whey the ioctls are blocked since you could have a wireless instance in one jail and another instance in another jail. However, to manage that instance can require the ioctls and the host doesn't have access to it anymore either. Running an X server in a vimage has some issues. Most are pretty easy to over-come. Maybe it might be good to have a sysctl to not do any checks at all so it acts like a chroot like security.jail.param.allow.all? Doug A. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: NFS mount inside jail fails
Quoting Arnaud Lacombe (from Wed, 18 May 2011 22:37:24 -0400): Hi, On Wed, May 18, 2011 at 10:03 AM, Pawel Jakub Dawidek wrote: There are some file systems types that can't be securely mounted within a jail no matter what, like UFS, MSDOFS, EXTFS, XFS, REISERFS, NTFS, etc. because the user mounting it has access to raw storage and can corrupt it in a way that it will panic entire system. This should at least be configurable somehow for people who are using jails for separation and do not care about security. I'd expect that security decision whether or not to allow something is user relevant, not developer relevant. The hardcoded version of this which I use exacly for the purpose you told here is at http://www.leidinger.net/FreeBSD/current-patches/sys:fs.diff Bye, Alexander. -- I think my career is ruined! http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: NFS mount inside jail fails
Hi, On Wed, May 18, 2011 at 10:03 AM, Pawel Jakub Dawidek wrote: > On Tue, May 17, 2011 at 10:17:12PM +0200, Alexander Leidinger wrote: >> On Tue, 17 May 2011 12:56:40 -0700 Sean Bruno >> wrote: >> >> > Silly thing I ran into today. User wanted to NFS mount a dir inside a >> > jail. After I groaned about the security implication of this, I noted >> > that there is a sysctl that looks like it should allow this. Namely, >> > security.jail.mount_allowed. I noted that setting this follows a path >> > that *should* have allowed this silly thing to happen, except that the >> > credentials in the nfsclient were not setup correctly. >> >> As you noticed, this is supposed to allow to mount inside a jail, IF >> the FS you want to mount is marked as secure/safe to do so. Nearly no >> FS is marked as such, as nobody wants to guarantee that it is safe >> (root in a jail should not be able to panic a system by trying to >> mount a corrupt/malicious FS-image) and secure (not possible to get >> elevated access/privileges). >> >> For NFS there is theoretically the problem that the outgoing address on >> requests could be the one of the physical host instead of the IP of the >> jail. If this is true in practice, I do not know. This could be >> the reason why NFS is not marked with VFCF_JAIL. > > It is not marked with VFCF_JAIL, because I just had no time to audit > that it is safe. It might be safe in theory. > > There are some file systems types that can't be securely mounted within > a jail no matter what, like UFS, MSDOFS, EXTFS, XFS, REISERFS, NTFS, > etc. because the user mounting it has access to raw storage and can > corrupt it in a way that it will panic entire system. > This should at least be configurable somehow for people who are using jails for separation and do not care about security. I'd expect that security decision whether or not to allow something is user relevant, not developer relevant. - Arnaud > There are other file systems that don't require access to raw storage > for the user doing the mount and chances are they are safe to mount from > within a jail, like ZFS (user can have access to ZFS datasets, but don't > need access to ZFS pool), NFS, SMBFS, NULLFS, UNIONFS, PROCFS, FDESCFS, > etc. I added VFCF_JAIL flag, so there is general mechanism to mark file > systems as jail-friendly, but back then I only needed it for ZFS. > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: NFS mount inside jail fails
On Wed, May 18, 2011 at 04:03:26PM +0200, Pawel Jakub Dawidek wrote: > On Tue, May 17, 2011 at 10:17:12PM +0200, Alexander Leidinger wrote: > > On Tue, 17 May 2011 12:56:40 -0700 Sean Bruno > > wrote: > > > > > Silly thing I ran into today. User wanted to NFS mount a dir inside a > > > jail. After I groaned about the security implication of this, I noted > > > that there is a sysctl that looks like it should allow this. Namely, > > > security.jail.mount_allowed. I noted that setting this follows a path > > > that *should* have allowed this silly thing to happen, except that the > > > credentials in the nfsclient were not setup correctly. > > > > As you noticed, this is supposed to allow to mount inside a jail, IF > > the FS you want to mount is marked as secure/safe to do so. Nearly no > > FS is marked as such, as nobody wants to guarantee that it is safe > > (root in a jail should not be able to panic a system by trying to > > mount a corrupt/malicious FS-image) and secure (not possible to get > > elevated access/privileges). > > > > For NFS there is theoretically the problem that the outgoing address on > > requests could be the one of the physical host instead of the IP of the > > jail. If this is true in practice, I do not know. This could be > > the reason why NFS is not marked with VFCF_JAIL. > > It is not marked with VFCF_JAIL, because I just had no time to audit > that it is safe. It might be safe in theory. > > There are some file systems types that can't be securely mounted within > a jail no matter what, like UFS, MSDOFS, EXTFS, XFS, REISERFS, NTFS, > etc. because the user mounting it has access to raw storage and can > corrupt it in a way that it will panic entire system. > > There are other file systems that don't require access to raw storage > for the user doing the mount and chances are they are safe to mount from > within a jail, like ZFS (user can have access to ZFS datasets, but don't > need access to ZFS pool), NFS, SMBFS, NULLFS, UNIONFS, PROCFS, FDESCFS, > etc. I added VFCF_JAIL flag, so there is general mechanism to mark file > systems as jail-friendly, but back then I only needed it for ZFS. If user does nfs or smbfs mount to the local (or any other controllable) server, then he definitely can plant the DoS or resource starvation attacks. pgpZlPZ4SSgcE.pgp Description: PGP signature
Re: NFS mount inside jail fails
On Tue, May 17, 2011 at 10:17:12PM +0200, Alexander Leidinger wrote: > On Tue, 17 May 2011 12:56:40 -0700 Sean Bruno > wrote: > > > Silly thing I ran into today. User wanted to NFS mount a dir inside a > > jail. After I groaned about the security implication of this, I noted > > that there is a sysctl that looks like it should allow this. Namely, > > security.jail.mount_allowed. I noted that setting this follows a path > > that *should* have allowed this silly thing to happen, except that the > > credentials in the nfsclient were not setup correctly. > > As you noticed, this is supposed to allow to mount inside a jail, IF > the FS you want to mount is marked as secure/safe to do so. Nearly no > FS is marked as such, as nobody wants to guarantee that it is safe > (root in a jail should not be able to panic a system by trying to > mount a corrupt/malicious FS-image) and secure (not possible to get > elevated access/privileges). > > For NFS there is theoretically the problem that the outgoing address on > requests could be the one of the physical host instead of the IP of the > jail. If this is true in practice, I do not know. This could be > the reason why NFS is not marked with VFCF_JAIL. It is not marked with VFCF_JAIL, because I just had no time to audit that it is safe. It might be safe in theory. There are some file systems types that can't be securely mounted within a jail no matter what, like UFS, MSDOFS, EXTFS, XFS, REISERFS, NTFS, etc. because the user mounting it has access to raw storage and can corrupt it in a way that it will panic entire system. There are other file systems that don't require access to raw storage for the user doing the mount and chances are they are safe to mount from within a jail, like ZFS (user can have access to ZFS datasets, but don't need access to ZFS pool), NFS, SMBFS, NULLFS, UNIONFS, PROCFS, FDESCFS, etc. I added VFCF_JAIL flag, so there is general mechanism to mark file systems as jail-friendly, but back then I only needed it for ZFS. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpsb21WHbLTg.pgp Description: PGP signature
Re: NFS mount inside jail fails
On 5/17/11 1:17 PM, Alexander Leidinger wrote: On Tue, 17 May 2011 12:56:40 -0700 Sean Bruno wrote: Silly thing I ran into today. User wanted to NFS mount a dir inside a jail. After I groaned about the security implication of this, I noted that there is a sysctl that looks like it should allow this. Namely, security.jail.mount_allowed. I noted that setting this follows a path that *should* have allowed this silly thing to happen, except that the credentials in the nfsclient were not setup correctly. As you noticed, this is supposed to allow to mount inside a jail, IF the FS you want to mount is marked as secure/safe to do so. Nearly no FS is marked as such, as nobody wants to guarantee that it is safe (root in a jail should not be able to panic a system by trying to mount a corrupt/malicious FS-image) and secure (not possible to get elevated access/privileges). For NFS there is theoretically the problem that the outgoing address on requests could be the one of the physical host instead of the IP of the jail. If this is true in practice, I do not know. This could be the reason why NFS is not marked with VFCF_JAIL. a vimage jail would not have that problem if we've done it right. Bye, Alexander. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: NFS mount inside jail fails
On Tue, 17 May 2011 12:56:40 -0700 Sean Bruno wrote: > Silly thing I ran into today. User wanted to NFS mount a dir inside a > jail. After I groaned about the security implication of this, I noted > that there is a sysctl that looks like it should allow this. Namely, > security.jail.mount_allowed. I noted that setting this follows a path > that *should* have allowed this silly thing to happen, except that the > credentials in the nfsclient were not setup correctly. As you noticed, this is supposed to allow to mount inside a jail, IF the FS you want to mount is marked as secure/safe to do so. Nearly no FS is marked as such, as nobody wants to guarantee that it is safe (root in a jail should not be able to panic a system by trying to mount a corrupt/malicious FS-image) and secure (not possible to get elevated access/privileges). For NFS there is theoretically the problem that the outgoing address on requests could be the one of the physical host instead of the IP of the jail. If this is true in practice, I do not know. This could be the reason why NFS is not marked with VFCF_JAIL. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
NFS mount inside jail fails
Silly thing I ran into today. User wanted to NFS mount a dir inside a jail. After I groaned about the security implication of this, I noted that there is a sysctl that looks like it should allow this. Namely, security.jail.mount_allowed. I noted that setting this follows a path that *should* have allowed this silly thing to happen, except that the credentials in the nfsclient were not setup correctly. e.g. VFS_SET(nfs_vfsops, oldnfs, VFCF_NETWORK); -- I changed this to: VFS_SET(nfs_vfsops, oldnfs, VFCF_NETWORK|VFCF_JAIL); This seems to allow the user's desired effect after setting security.jail.mount_allowed=1 I *think* this is the correct behavior, if a bit silly when taking into account the purpose of a jail. Thoughts? Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
