Bug#310982: plan to include in sarge 2.4 update
On Thu, Nov 16, 2006 at 10:51:24AM +0100, Bill Allombert wrote: I am a bit concerned by the comment in the link you posted: To fully work, some modifications are needed to samba smbmount.c and smbmnt.c files. Those patches are available at Samba and Kernel Bug Tracker pages. After those patches, if the user do not supply any of the parameters a bove, the uid, gid, file_mode and dir_mode on the server will be used by the client. Did I understand correctly we would need to also patch samba ? (Haroldo: complete history of this discussion is available at http://bugs.debian.org/310982) hey Bill - sorry for the delay, I put this on the back burner while I tried to get my etch packages into a releaseable state. I didn't notcie the note about the userspace patches initially, thanks for pointing it out. Here's what I can decipher about their purpose, based upon code reading (I've cc'd the author so he can correct me if I've misunderstood): The kernel patch has changed the behavior to honor mount options if specified instead of always relying on the remote server. The issue with that is that smbmount always passes these options to the kernel, even if not specified by the user. The smbmount patch changees that by only passing these options if the user included them. With this change, the user can omit these options if they want to fallback to the values provided by the remote server. If this reading is correct, I don't think its necessary for us to perform an security update of samba - in fact, it maybe risky to do so. Though less flexible, it seems safer to default to the locally formulated values than to use what the remote server provides. Also note that the userspace patches have not gone upstream (google returns no record of them being submitted), but the kernel one did. So, a kernel-only update would make sarge's behavior consistent with etch. The downside is that any sarge users who might be relying on the use-the-server-provided-value behavior will no longer have that option. I don't understand this case enough to know if it has any practical implications. I would guess it means something like if user dannf had mounted vorlon's share w/o any mount options, current sarge would make those files owned by vorlon locally - but with just this kernel patch they'd now be owned by dannf? Unless someone can explain this authoritatively, I guess we'll just need to test it. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: plan to include in sarge 2.4 update
On Mon, Nov 27, 2006 at 07:27:39PM -0700, dann frazier wrote: The downside is that any sarge users who might be relying on the use-the-server-provided-value behavior will no longer have that option. I don't understand this case enough to know if it has any practical implications. I would guess it means something like if user dannf had mounted vorlon's share w/o any mount options, current sarge would make those files owned by vorlon locally - but with just this kernel patch they'd now be owned by dannf? Unless someone can explain this authoritatively, I guess we'll just need to test it. Yes, with the patch, all the files under the mount will be owned either by root or by a different user specified as a client option when mounting; without the patch, they'll be owned by whatever uid the server says they are. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: plan to include in sarge 2.4 update
Dear sirs, It's been a long time since I've made those patches but I have never known why the user level patches were not applied. I still think they are necessary. Haroldo On Mon, 2006-11-27 at 19:27 -0700, dann frazier wrote: On Thu, Nov 16, 2006 at 10:51:24AM +0100, Bill Allombert wrote: I am a bit concerned by the comment in the link you posted: To fully work, some modifications are needed to samba smbmount.c and smbmnt.c files. Those patches are available at Samba and Kernel Bug Tracker pages. After those patches, if the user do not supply any of the parameters a bove, the uid, gid, file_mode and dir_mode on the server will be used by the client. Did I understand correctly we would need to also patch samba ? (Haroldo: complete history of this discussion is available at http://bugs.debian.org/310982) hey Bill - sorry for the delay, I put this on the back burner while I tried to get my etch packages into a releaseable state. I didn't notcie the note about the userspace patches initially, thanks for pointing it out. Here's what I can decipher about their purpose, based upon code reading (I've cc'd the author so he can correct me if I've misunderstood): The kernel patch has changed the behavior to honor mount options if specified instead of always relying on the remote server. The issue with that is that smbmount always passes these options to the kernel, even if not specified by the user. The smbmount patch changees that by only passing these options if the user included them. With this change, the user can omit these options if they want to fallback to the values provided by the remote server. If this reading is correct, I don't think its necessary for us to perform an security update of samba - in fact, it maybe risky to do so. Though less flexible, it seems safer to default to the locally formulated values than to use what the remote server provides. Also note that the userspace patches have not gone upstream (google returns no record of them being submitted), but the kernel one did. So, a kernel-only update would make sarge's behavior consistent with etch. The downside is that any sarge users who might be relying on the use-the-server-provided-value behavior will no longer have that option. I don't understand this case enough to know if it has any practical implications. I would guess it means something like if user dannf had mounted vorlon's share w/o any mount options, current sarge would make those files owned by vorlon locally - but with just this kernel patch they'd now be owned by dannf? Unless someone can explain this authoritatively, I guess we'll just need to test it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: plan to include in sarge 2.4 update
dann frazier wrote: On Mon, Nov 13, 2006 at 12:22:59PM -0800, Steve Langasek wrote: Yes, because this is a kernel security bug. The smbmount patch was entertained pre-sarge only as a stopgap due to the proximity to release; the right place to fix this is still in the kernel (upstream as appropriate). I've done some testing and verified that 2.6.18 honors uid= and 2.6.8 does not. It looks like this was fixed upstream: http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED]|src/|src/fs|src/fs/smbfs|related/fs/smbfs/inode.c So, I plan to use this patch for 2.6.8, and attempt to backport it to 2.4.27. If backporting becomes overly complicated/risky, I'll revert to using something like Horms' patch. I'll also see about getting a CVE assigned. Everyone cool with this plan? Ok. Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: plan to include in sarge 2.4 update
On Wed, Nov 15, 2006 at 05:54:52PM -0700, dann frazier wrote: On Mon, Nov 13, 2006 at 12:22:59PM -0800, Steve Langasek wrote: Yes, because this is a kernel security bug. The smbmount patch was entertained pre-sarge only as a stopgap due to the proximity to release; the right place to fix this is still in the kernel (upstream as appropriate). I've done some testing and verified that 2.6.18 honors uid= and 2.6.8 does not. It looks like this was fixed upstream: http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED]|src/|src/fs|src/fs/smbfs|related/fs/smbfs/inode.c So, I plan to use this patch for 2.6.8, and attempt to backport it to 2.4.27. If backporting becomes overly complicated/risky, I'll revert to using something like Horms' patch. I'll also see about getting a CVE assigned. Everyone cool with this plan? I am a bit concerned by the comment in the link you posted: To fully work, some modifications are needed to samba smbmount.c and smbmnt.c files. Those patches are available at Samba and Kernel Bug Tracker pages. After those patches, if the user do not supply any of the parameters a bove, the uid, gid, file_mode and dir_mode on the server will be used by the client. Did I understand correctly we would need to also patch samba ? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large blue swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: plan to include in sarge 2.4 update
On Mon, Nov 13, 2006 at 12:22:59PM -0800, Steve Langasek wrote: Yes, because this is a kernel security bug. The smbmount patch was entertained pre-sarge only as a stopgap due to the proximity to release; the right place to fix this is still in the kernel (upstream as appropriate). I've done some testing and verified that 2.6.18 honors uid= and 2.6.8 does not. It looks like this was fixed upstream: http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED]|src/|src/fs|src/fs/smbfs|related/fs/smbfs/inode.c So, I plan to use this patch for 2.6.8, and attempt to backport it to 2.4.27. If backporting becomes overly complicated/risky, I'll revert to using something like Horms' patch. I'll also see about getting a CVE assigned. Everyone cool with this plan? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: plan to include in sarge 2.4 update
On Wed, Nov 15, 2006 at 05:54:52PM -0700, dann frazier wrote: On Mon, Nov 13, 2006 at 12:22:59PM -0800, Steve Langasek wrote: Yes, because this is a kernel security bug. The smbmount patch was entertained pre-sarge only as a stopgap due to the proximity to release; the right place to fix this is still in the kernel (upstream as appropriate). I've done some testing and verified that 2.6.18 honors uid= and 2.6.8 does not. It looks like this was fixed upstream: http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED]|src/|src/fs|src/fs/smbfs|related/fs/smbfs/inode.c So, I plan to use this patch for 2.6.8, and attempt to backport it to 2.4.27. If backporting becomes overly complicated/risky, I'll revert to using something like Horms' patch. I'll also see about getting a CVE assigned. Everyone cool with this plan? Ack -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: plan to include in sarge 2.4 update
On Sun, Nov 12, 2006 at 10:28:10PM -0700, dann frazier wrote: On Mon, Nov 13, 2006 at 01:30:19PM +0900, Horms wrote: If you point me at the patch I'll be happy to rack my brains and tell you want I was thinking at the time. Thanks Horms, here's the link: http://bugs.debian.org/cgi-bin/bugreport.cgi/smbfs.no_cap_unix.patch?bug=310982;msg=101;att=1 Ahh yes, I do recall that one. I've just read through all the messages associated with the bug and my position can be best described by the text at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310982;msg=101 That is, the patch should make the kernel ignore CAP_UNIX if options which make it dangerous in Sarge are specified from user-space. At the time this seemed to Steve Langasek and myself to be the best of a poor set of available solutions. And I think that is still the case. I have not verified that the patch is correct. Although I do remember being quite confident about it at the time. If someone could test it, that would be most excellent :) -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: plan to include in sarge 2.4 update
On Sun, Nov 12, 2006 at 09:28:14PM -0700, dann frazier wrote: Moritz pointed out that this issue has been overlooked for sarge updates so far. From my reading of this report, it sounds like our best option for sarge is to incorporate Horms' patch for 2.4.27. Thanks for looking at this. I initially reported this issue to samba and then I provided a patch for smbmout. Now if the issue is fixed in the kernel instead, then all kernel providing smbfs need to be fixed, not only sarge-2.4.27. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large blue swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: plan to include in sarge 2.4 update
On Mon, Nov 13, 2006 at 10:09:52AM +0100, Bill Allombert wrote: Thanks for looking at this. I initially reported this issue to samba and then I provided a patch for smbmout. Now if the issue is fixed in the kernel instead, then all kernel providing smbfs need to be fixed, not only sarge-2.4.27. I was wondering about that - so if we apply this in 2.4.27, we should probably also apply it in 2.6.8. Is the smbmount patch still present in etch/sid? I'm ok with doing this as a workaround for sarge, but not with forward porting the patch indefinitely to future kernel releases. Another option we could consider is to do a security release of samba with either the !CAP_UNIX patch, or a NEWS.Debian that warns users of this change in behavior. cc'ing the security team for their input. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: plan to include in sarge 2.4 update
On Mon, Nov 13, 2006 at 09:26:10AM -0700, dann frazier wrote: On Mon, Nov 13, 2006 at 10:09:52AM +0100, Bill Allombert wrote: Thanks for looking at this. I initially reported this issue to samba and then I provided a patch for smbmout. Now if the issue is fixed in the kernel instead, then all kernel providing smbfs need to be fixed, not only sarge-2.4.27. I was wondering about that - so if we apply this in 2.4.27, we should probably also apply it in 2.6.8. Is the smbmount patch still present in etch/sid? I'm ok with doing this as a workaround for sarge, but not with forward porting the patch indefinitely to future kernel releases. As far as I know the smbmount patch has never been applied to any release. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large blue swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: plan to include in sarge 2.4 update
On Mon, Nov 13, 2006 at 05:49:56PM +0100, Bill Allombert wrote: On Mon, Nov 13, 2006 at 09:26:10AM -0700, dann frazier wrote: On Mon, Nov 13, 2006 at 10:09:52AM +0100, Bill Allombert wrote: Thanks for looking at this. I initially reported this issue to samba and then I provided a patch for smbmout. Now if the issue is fixed in the kernel instead, then all kernel providing smbfs need to be fixed, not only sarge-2.4.27. I was wondering about that - so if we apply this in 2.4.27, we should probably also apply it in 2.6.8. Is the smbmount patch still present in etch/sid? I'm ok with doing this as a workaround for sarge, but not with forward porting the patch indefinitely to future kernel releases. As far as I know the smbmount patch has never been applied to any release. Yes, because this is a kernel security bug. The smbmount patch was entertained pre-sarge only as a stopgap due to the proximity to release; the right place to fix this is still in the kernel (upstream as appropriate). Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: plan to include in sarge 2.4 update
Moritz pointed out that this issue has been overlooked for sarge updates so far. From my reading of this report, it sounds like our best option for sarge is to incorporate Horms' patch for 2.4.27. Does anyone object to this? I'll make builds available for testing prior to uploading, in case anyone is interested in verifying this solution. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: plan to include in sarge 2.4 update
On Sun, Nov 12, 2006 at 09:28:14PM -0700, dann frazier wrote: Moritz pointed out that this issue has been overlooked for sarge updates so far. From my reading of this report, it sounds like our best option for sarge is to incorporate Horms' patch for 2.4.27. Does anyone object to this? I'll make builds available for testing prior to uploading, in case anyone is interested in verifying this solution. If you point me at the patch I'll be happy to rack my brains and tell you want I was thinking at the time. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: plan to include in sarge 2.4 update
On Mon, Nov 13, 2006 at 01:30:19PM +0900, Horms wrote: If you point me at the patch I'll be happy to rack my brains and tell you want I was thinking at the time. Thanks Horms, here's the link: http://bugs.debian.org/cgi-bin/bugreport.cgi/smbfs.no_cap_unix.patch?bug=310982;msg=101;att=1 -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
