samba - Jan 2016 - Security permissions issues after changing idmap backend from RID to AUTORID

On 2016-01-10 at 17:58 +0000, Rowland penny wrote:
> On 10/01/16 17:05, Partha Sarathi wrote:
> >
> > > This could have a lot to do with the fact that idmap_rid &
> > > idmap_autorid calculate the uids differently i.e if you have RID
> > > '2025000', autorid would calculate this as
'1102500000' , rid
> > > would calculate this as '12025000'
> >
> >Thanks for the reply. Now we end-up with mix uid/gid from both ranges
in
> >cache TDBs. Few user logins are denied with below error in smbd.log,
> >
> >Is there way to cleanup these mismatch uid/gid information in TDBs(like
> >winbind_cache.tdb or gencahe.tdb) or remove all TDBs start afresh.
>
> You could try running 'net cache flush', but that isn't your
only problem,
> files saved before you changed will belong to the ID created by the rid
> backend and files created after the change will belong to the ID created by
> autorid,
Indeed. Rowland is completely right. This is the your major problem.
And it is really, really severe. The IDs from the old mappings are
everywhere in the share file systems: Ownership and ACLs.

Changing the mapping to a different mapping, this is what happens:

- People lose access to their files since the permissions are
  for different IDs (that previously belonged to their name/sid).
  ==> Thie is the ACCESS DENIED you saw.

- People may be granted access to files they should not have
  access to (files created by previous holders of their new ID).

- If people create new files, they will be created by the new
  IDs, so a mix-up will start. You need to prevent that, so
  cut the network cable asap...

So what can you do about it?

- If you have not done it, take the server offline immediately,
  so that no further mix-up can happen.

- Ideally, change your config back to the original "rid" config.
  As Rowland asked: Why was it changed in the first place?...

- If that is not possible for some reason, you _might_ get away with
  cleaning your autorid database and pre-creating an appropriate range
  allocation for your main domain with the command 'net idmap set
range'.
  (Provided the range size is the same and the autorid range
   includes the previous rid range as a fully aligned sub-range.)
  But beware that this is a very low-level tool and you should
  only run it while winbindd is not running. See the net(8) manpage.

Cheers - Michael

PS: Everybody: NEVER change the idmap configuration just like that on
a production system! EVER!
(Unless you want to lose (access to) your data.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.samba.org/pipermail/samba/attachments/20160111/73f8661e/signature.sig>

Thanks Michael,

Please see the inline answers.
> On Jan 10, 2016, at 5:16 PM, Michael Adam <obnox at samba.org> wrote:
> 
> On 2016-01-10 at 17:58 +0000, Rowland penny wrote:
>> On 10/01/16 17:05, Partha Sarathi wrote:
>>> 
>>>> This could have a lot to do with the fact that idmap_rid &
>>>> idmap_autorid calculate the uids differently i.e if you have
RID
>>>> '2025000', autorid would calculate this as
'1102500000' , rid
>>>> would calculate this as '12025000'
>>> 
>>> Thanks for the reply. Now we end-up with mix uid/gid from both
ranges in
>>> cache TDBs. Few user logins are denied with below error in
smbd.log,
>>> 
>>> Is there way to cleanup these mismatch uid/gid information in
TDBs(like
>>> winbind_cache.tdb or gencahe.tdb) or remove all TDBs start afresh.
>> 
>> You could try running 'net cache flush', but that isn't
your only problem,
>> files saved before you changed will belong to the ID created by the rid
>> backend and files created after the change will belong to the ID
created by
>> autorid,
> 
> Indeed. Rowland is completely right. This is the your major problem.
> And it is really, really severe. The IDs from the old mappings are
> everywhere in the share file systems: Ownership and ACLs.
> 
> Changing the mapping to a different mapping, this is what happens:
The Change was required to support the "Trusted Domain” where RID backend 
can not support it.
> 
> - People lose access to their files since the permissions are
>  for different IDs (that previously belonged to their name/sid).
>  ==> Thie is the ACCESS DENIED you saw.
> 
Yeah this is true  when we by mistake modifies POSIX acls directly then
get_nt_acl_internal try to construct the SD by deriving SIDs for every UID on
the POSIX list. other wise it will never get into to that path.
> - People may be granted access to files they should not have
>  access to (files created by previous holders of their new ID).
> 
> - If people create new files, they will be created by the new
>  IDs, so a mix-up will start. You need to prevent that, so
>  cut the network cable asap...
> 
> So what can you do about it?
> 
> - If you have not done it, take the server offline immediately,
>  so that no further mix-up can happen.
> 
> - Ideally, change your config back to the original "rid" config.
>  As Rowland asked: Why was it changed in the first place?...
> 
> - If that is not possible for some reason, you _might_ get away with
>  cleaning your autorid database and pre-creating an appropriate range
>  allocation for your main domain with the command 'net idmap set
range'.
>  (Provided the range size is the same and the autorid range
>   includes the previous rid range as a fully aligned sub-range.)
>  But beware that this is a very low-level tool and you should
>  only run it while winbindd is not running. See the net(8) manpage.

root at partha:/var/lib/samba# net -V
Version 4.1.17-Debian

root at partha:/var/lib/samba# net idmap --help
Usage:
net idmap dump
  Dump the current ID mappings
net idmap restore
  Restore entries from stdin
net idmap setmap
  Not implemented yet
net idmap delete <ID>
  Delete ID mapping
net idmap secret <DOMAIN> <secret>
  Set secret for specified domain
net idmap check
  Check id mappings

root at partha:/var/lib/samba# net idmap setmap 
Not implemented yet
> 
> Cheers - Michael
> 
> PS: Everybody: NEVER change the idmap configuration just like that on
> a production system! EVER!
> (Unless you want to lose (access to) your data.)
Probably I try to remove the affected (4) users from the cache tdb using
'net cache get’ and net cache del’ and see if that works for customer.

Thanks again for suggesting workaround and possible solution.

Regards,
—Partha

On 2016-01-10 at 18:21 -0800, Partha Sarathi Besgarahalli Lakshmaiah
wrote:
> > On Jan 10, 2016, at 5:16 PM, Michael Adam <obnox at samba.org>
wrote:
> > On 2016-01-10 at 17:58 +0000, Rowland penny wrote:
> >> On 10/01/16 17:05, Partha Sarathi wrote:
> >>> 
> >>>> This could have a lot to do with the fact that idmap_rid
&
> >>>> idmap_autorid calculate the uids differently i.e if you
have RID
> >>>> '2025000', autorid would calculate this as
'1102500000' , rid
> >>>> would calculate this as '12025000'
> >>> 
> >>> Is there way to cleanup these mismatch uid/gid information in
TDBs(like
> >>> winbind_cache.tdb or gencahe.tdb) or remove all TDBs start
afresh.
> >> 
> >> You could try running 'net cache flush', but that
isn't your only problem,
> >> files saved before you changed will belong to the ID created by
the rid
> >> backend and files created after the change will belong to the ID
created by
> >> autorid,
> > 
> > Indeed. Rowland is completely right. This is the your major problem.
> > And it is really, really severe. The IDs from the old mappings are
> > everywhere in the share file systems: Ownership and ACLs.
> > 
> > Changing the mapping to a different mapping, this is what happens:
> 
> The Change was required to support the "Trusted Domain” where RID
backend  can not support it.
Sure it can. But you have to configure each trusted domain
separately: You can define separate rid ranges for multiple
domains.

If you have already accessed samba with users from trusted
domains, it is also too late for them anyways: The will have
been give IDs from the default (idmap_tdb?) range and so
also they will be affected by the idmap change. In this case
you can not provision autorid accordingly but you'll have to
remove the old mappings from winbind_idmap.tdb and change
permissions and acls on disk for these users.
> > - People lose access to their files since the permissions are
> >  for different IDs (that previously belonged to their name/sid).
> >  ==> Thie is the ACCESS DENIED you saw.
> > 
> Yeah this is true  when we by mistake modifies POSIX acls
> directly then get_nt_acl_internal try to construct the SD by
> deriving SIDs for every UID on the POSIX list. other wise it
> will never get into to that path. 
Hmm. That is not the problem. The problem is that your users
are now accessing their files with different uids. That does
not only show up with acls but also with posix permissions.
This will *always* show up - in every single access.
Unless you had world-readable/world-writeable access set on
files, you will be denied access.
> > - People may be granted access to files they should not have
> >  access to (files created by previous holders of their new ID).
> > 
> > - If people create new files, they will be created by the new
> >  IDs, so a mix-up will start. You need to prevent that, so
> >  cut the network cable asap...
> > 
> > So what can you do about it?
> > 
> > - If you have not done it, take the server offline immediately,
> >  so that no further mix-up can happen.
> > 
> > - Ideally, change your config back to the original "rid"
config.
> >  As Rowland asked: Why was it changed in the first place?...
> > 
> > - If that is not possible for some reason, you _might_ get away with
> >  cleaning your autorid database and pre-creating an appropriate range
> >  allocation for your main domain with the command 'net idmap set
range'.
> >  (Provided the range size is the same and the autorid range
> >   includes the previous rid range as a fully aligned sub-range.)
> >  But beware that this is a very low-level tool and you should
> >  only run it while winbindd is not running. See the net(8) manpage.
> 
> 
> root at partha:/var/lib/samba# net -V
> Version 4.1.17-Debian
> 
> root at partha:/var/lib/samba# net idmap --help
> Usage:
> net idmap dump
>   Dump the current ID mappings
> net idmap restore
>   Restore entries from stdin
> net idmap setmap
>   Not implemented yet
> net idmap delete <ID>
>   Delete ID mapping
> net idmap secret <DOMAIN> <secret>
>   Set secret for specified domain
> net idmap check
>   Check id mappings
> 
> root at partha:/var/lib/samba# net idmap setmap 
> Not implemented yet
I was talking about "net idmap set range".
Indeed, your samba version is too old for these tools.

You could take the autorid tdb file and work on it
on a system with newer samba (>= 4.2). You can with this
tool essentially prepare an autorid database with pre-
defined ranges that you need in order not to destroy
file access. After that you can copy the db back to the
system. (The actual database format for the autorid
db has not changed.)
> > PS: Everybody: NEVER change the idmap configuration just like that on
> > a production system! EVER!
> > (Unless you want to lose (access to) your data.)
> 
> Probably I try to remove the affected (4) users from the cache
> tdb using 'net cache get’ and net cache del’ and see if that
> works for customer.
Er, no. The cache is most certainly not your only and
not your most severe problem... Or else I need a more
thorough explanation why you are not suffering from
the changed uids.

Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.samba.org/pipermail/samba/attachments/20160111/66c08bc3/signature.sig>