Question Need for 'module' installed in 3.6.0-rc2

Volker Lendecke Volker.Lendecke at SerNet.DE
Wed Jun 15 04:06:32 MDT 2011


On Tue, Jun 14, 2011 at 11:37:51PM -0700, Linda W wrote:
> Volker Lendecke wrote:
> >
> >I have definitely seen this in 2.6 kernels. You have to
> >exactly follow the steps described in the bug. If I remember
> >correctly it only happens if you create a directory using
> >your rights from a group acl entry (or something like that).
> >If you are doing it as the owner of the parent directory it
> >does not happen. It was something very specific, look at the
> >bug.
> -----
> 	I see now...  But this appears to be correct functioning.
> 
> 
> The user is using the command:
>    dir is owned by me and I'm NOT in the group it is setGID to, then I:
> chacl  -b u::rwx,g::rwx,g:lawgroup:rwx,o::---,m::rwx u::rwx,g::rwx,g:lawgroup:rwx,o::---,m::rwx  dirname
> 
> That breaks down to the object's perms and defaults for contained objects.
> 
> I.e, set basis umask to u+rwx,g+rws,o-rwx  for the object and its contained
> objects, + an extra entry for 'lawgroup'.
> 
> If I **wasn't** in the group that owned the file -- I've just changed the
> security about who can read, write or search in that dir.  Thus, I may have give
> read access (maybe it was write only so people could leave logs), or
> I've added write access -- it was set to read only because other
> children, had been created
> with writable access under the same GID, then the parent dir had been changed
> by someone in the group to no-write.
> 
> 
> Either way, _I_, who am not in the group, should not be able to 'set' the security
> on the group perms without clearing the SGID bit.
> 
> However, if I am IN the group, the bit doesn't get cleared, as being 'of' the group
> it wouldn't be a security leak.
> 
> 
> So...let me get this straight...
> 
> Are you saying samba has a module to override this functionality and thereby
> introduces the security leak I described?

Have you tried the exact steps in the bug report? This is
not about explicitly changing ACLs or SGID. This is about
implicit propagation of the SGID bit during a mkdir call.
This works with ext3, it does not with XFS in the exact case
of the bug report. If you say that the ext3 behaviour is a
security leak, then you should probably make a big fuss
about that in the various security forums. This Samba module
intends to make its behaviour match when run over XFS and
ext3.

Please be aware that this module is not enabled by default.
There are tons of other ways to configure Samba in
completely unsafe ways (see for example "admin users" or
"force user = root"), so this is a lesser worry for us.

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen


More information about the samba-technical mailing list