[Samba] Security leak in map_nt_perms?

In map_nt_perms any of FILE_READ_DATA, FILE_READ_EA or
FILE_READ_ATTRIBUTES is mapped unconditionally to Unix read permission
and similarly for write permission

This means that if I put a file on a samba share where I explicitly left
*only* FILE_READ_ATTRIBUTES and FILE_READ_EA the file content becomes
hiddenly readable also if I decided (for very good reasons) otherwise.

I'd say that when a permission model is mapped to another permission
model that has less or different granularity the resulting permission
should be a subset of the original one.

This would guarantee that unwanted data exposure is impossible.

IMHO the only inconvenience that a strict/safer mapping would have is
that the attempt to grant *only* a subset of read privileges would be a
no effect (problem easily diagnosed and afforded without security risks
and with access failure as a clear feedback).

A possible alternative is to map only FILE_READ_DATA to Unix Read and to
map Unix Read to FILE_READ_DATA | FILE_READ_EA | FILE_READ_ATTRIBUTES.
This lead to a lesser security exposure (that however is unavoidable
taken for granted Unix RWX security model)

I'm missing something?
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Thu, Aug 14, 2008 at 11:41:14PM +0200, Abramo Bagnara wrote:
>
> In map_nt_perms any of FILE_READ_DATA, FILE_READ_EA or
> FILE_READ_ATTRIBUTES is mapped unconditionally to Unix read permission
> and similarly for write permission
>
> This means that if I put a file on a samba share where I explicitly left
> *only* FILE_READ_ATTRIBUTES and FILE_READ_EA the file content becomes
> hiddenly readable also if I decided (for very good reasons) otherwise.
>
> I'd say that when a permission model is mapped to another permission
> model that has less or different granularity the resulting permission
> should be a subset of the original one.
>
> This would guarantee that unwanted data exposure is impossible.
>
> IMHO the only inconvenience that a strict/safer mapping would have is
> that the attempt to grant *only* a subset of read privileges would be a
> no effect (problem easily diagnosed and afforded without security risks
> and with access failure as a clear feedback).
>
> A possible alternative is to map only FILE_READ_DATA to Unix Read and to
> map Unix Read to FILE_READ_DATA | FILE_READ_EA | FILE_READ_ATTRIBUTES.
> This lead to a lesser security exposure (that however is unavoidable
> taken for granted Unix RWX security model)
>
> I'm missing something?

Hmmmm. I'm not sure what we can do here other than store the
full NT Acl in an xattr (which I'm working on right now) and
use it as an initial filter for access_denied on open.

The underlying problem is that incoming NT -> unix perms
is a lossy mapping, not much we can do about that.

Jeremy.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

Jeremy Allison ha scritto:
> On Thu, Aug 14, 2008 at 11:41:14PM +0200, Abramo Bagnara wrote:
>> In map_nt_perms any of FILE_READ_DATA, FILE_READ_EA or
>> FILE_READ_ATTRIBUTES is mapped unconditionally to Unix read permission
>> and similarly for write permission
>>
>> This means that if I put a file on a samba share where I explicitly left
>> *only* FILE_READ_ATTRIBUTES and FILE_READ_EA the file content becomes
>> hiddenly readable also if I decided (for very good reasons) otherwise.
>>
>> I'd say that when a permission model is mapped to another permission
>> model that has less or different granularity the resulting permission
>> should be a subset of the original one.
>>
>> This would guarantee that unwanted data exposure is impossible.
>>
>> IMHO the only inconvenience that a strict/safer mapping would have is
>> that the attempt to grant *only* a subset of read privileges would be a
>> no effect (problem easily diagnosed and afforded without security risks
>> and with access failure as a clear feedback).
>>
>> A possible alternative is to map only FILE_READ_DATA to Unix Read and to
>> map Unix Read to FILE_READ_DATA | FILE_READ_EA | FILE_READ_ATTRIBUTES.
>> This lead to a lesser security exposure (that however is unavoidable
>> taken for granted Unix RWX security model)
>>
>> I'm missing something?
>
> Hmmmm. I'm not sure what we can do here other than store the
> full NT Acl in an xattr (which I'm working on right now) and
> use it as an initial filter for access_denied on open.

This is a perfect approach (at least from the samba client point of
view), but does not solve the problem that a file written by a samba
client with FILE_READ_DATA unset and FILE_READ_ATTRIBUTES set is
readable on server machine (locally, via nfs, via ftp or whatever).

This is IMHO a big problem.

> The underlying problem is that incoming NT -> unix perms
> is a lossy mapping, not much we can do about that.

Yes, it's a lossy mapping, but what's the reason (or the benefits) to
"round up" it (as samba does now) instead to play safe and to "round
down" it (i.e. the permission set is a subset or the same of what it's
requested).

I certainly see the security problems of current approach, but perhaps
I'm missing other problems that one of the two safer approaches
described above would put in the game.

What's your opinion about that?

--
Abramo Bagnara

Opera Unica Phone: +39.0546.656023
Via Borghesi, 16
48014 Castel Bolognese (RA) - Italy
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Fri, Aug 15, 2008 at 12:41:39AM +0200, Abramo Bagnara wrote:

> This is a perfect approach (at least from the samba client point of
> view), but does not solve the problem that a file written by a samba
> client with FILE_READ_DATA unset and FILE_READ_ATTRIBUTES set is
> readable on server machine (locally, via nfs, via ftp or whatever).
>
> This is IMHO a big problem.

It hasn't been seen as such so far.

> Yes, it's a lossy mapping, but what's the reason (or the benefits) to
> "round up" it (as samba does now) instead to play safe and to "round
> down" it (i.e. the permission set is a subset or the same of what it's
> requested).
>
> I certainly see the security problems of current approach, but perhaps
> I'm missing other problems that one of the two safer approaches
> described above would put in the game.
>
> What's your opinion about that?

The problem is that a permission set of "---" is currently
returned in Samba as a "DENY" ACL. Your plan of mapping
an ACE of FILE_READ_ATTRIBUTES to "---" then conflicts with
a requested DENY ACE.

Jeremy.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

Jeremy Allison ha scritto:
> On Fri, Aug 15, 2008 at 12:41:39AM +0200, Abramo Bagnara wrote:
>
>> This is a perfect approach (at least from the samba client point of
>> view), but does not solve the problem that a file written by a samba
>> client with FILE_READ_DATA unset and FILE_READ_ATTRIBUTES set is
>> readable on server machine (locally, via nfs, via ftp or whatever).
>>
>> This is IMHO a big problem.
>
> It hasn't been seen as such so far.

Consider that before yesterday if you typed

$ chmod 600 file

in cygwin on a samba share the mode set was 644 just because cygwin was
interested to leave FILE_READ_ATTRIBUTES set.

Yesterday Corinna has fixed in current CVS this behaviour in a specific
way for samba share.

>> Yes, it's a lossy mapping, but what's the reason (or the benefits) to
>> "round up" it (as samba does now) instead to play safe and to "round
>> down" it (i.e. the permission set is a subset or the same of what it's
>> requested).
>>
>> I certainly see the security problems of current approach, but perhaps
>> I'm missing other problems that one of the two safer approaches
>> described above would put in the game.
>>
>> What's your opinion about that?
>
> The problem is that a permission set of "---" is currently
> returned in Samba as a "DENY" ACL. Your plan of mapping
> an ACE of FILE_READ_ATTRIBUTES to "---" then conflicts with
> a requested DENY ACE.

Sorry to show me dense, but I don't see the problem: the request to
allow FILE_READ_ATTRIBUTES only would generate a 000 perms just as if
map_nt_perms was called with only permissions not handled there.

I'd say that to ask to allow FILE_READ_ATTRIBUTES only don't have to
generate any ACE at all (as this request under an Unix permission model
point of view don't give to user/group any further right).

Could you explain how a possible conflict with a requested DENY ACE
could happens?
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Fri, Aug 15, 2008 at 11:52:17AM +0200, Abramo Bagnara wrote:
>
> Sorry to show me dense, but I don't see the problem: the request to
> allow FILE_READ_ATTRIBUTES only would generate a 000 perms just as if
> map_nt_perms was called with only permissions not handled there.
>
> I'd say that to ask to allow FILE_READ_ATTRIBUTES only don't have to
> generate any ACE at all (as this request under an Unix permission model
> point of view don't give to user/group any further right).
>
> Could you explain how a possible conflict with a requested DENY ACE
> could happens?

Existing file has FILE_READ_DATA|FILE_WRITE_DATA|FILE_READ_ATTRIBUTE S.
Acl comes in to change this to FILE_READ_ATTRIBUTES. Samba has to map
this to '---' according to you. Oops. Instant deny ACL. Not what was
intended.

Jeremy.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

Jeremy Allison ha scritto:
> On Fri, Aug 15, 2008 at 11:52:17AM +0200, Abramo Bagnara wrote:
>> Sorry to show me dense, but I don't see the problem: the request to
>> allow FILE_READ_ATTRIBUTES only would generate a 000 perms just as if
>> map_nt_perms was called with only permissions not handled there.
>>
>> I'd say that to ask to allow FILE_READ_ATTRIBUTES only don't have to
>> generate any ACE at all (as this request under an Unix permission model
>> point of view don't give to user/group any further right).
>>
>> Could you explain how a possible conflict with a requested DENY ACE
>> could happens?
>
> Existing file has FILE_READ_DATA|FILE_WRITE_DATA|FILE_READ_ATTRIBUTE S.
> Acl comes in to change this to FILE_READ_ATTRIBUTES. Samba has to map
> this to '---' according to you. Oops. Instant deny ACL. Not what was
> intended.

I try to detail your example as it seems there is some misunderstanding:

NT ACL: Allow SID FILE_READ_DATA FILE_READ_ATTRIBUTES FILE_WRITE_DATA
Current samba perms for owner, group or others: rw-
Current samba posix acl: user:abramo:rw-
Current new NT ACL: Allow SID FILE_READ_DATA FILE_READ_ATTRIBUTES
FILE_READ_EA FILE_GENERIC_READ FILE_WRITE_DATA FILE_APPEND_DATA
FILE_WRITE_ATTRIBUTES FILE_WRITE_EA FILE_GENERIC_WRITE
Proposed is the same as current

NT ACL: Allow SID FILE_READ_ATTRIBUTES
Current samba perms for owner, group or others: r--
Current samba posix acl: user:abramo:r--
Current new NT ACL: Allow SID FILE_READ_DATA FILE_READ_ATTRIBUTES
FILE_READ_EA FILE_GENERIC_READ
Proposed samba perms for owner, group or others: ---
Proposed samba posix acl: entry is removed
Proposed new NT ACL for owner, group or others: Allow SID EMPTY
Proposed new NT ACL: ACE is removed

Simply I'm suggesting that this case is treated as it was a request to
have an empty list of accesses for that SID.

IOW the FILE_READ_ATTRIBUTES FILE_READ_EA FILE_WRITE_ATTRIBUTES
FILE_WRITE_EA are masked out when received by samba server if they are
not available in underlying file system permission model. They really
follow the FILE_READ_DATA/FILE_WRITE_DATA.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Fri, Aug 15, 2008 at 08:07:58PM +0200, Abramo Bagnara wrote:
> Jeremy Allison ha scritto:
> > On Fri, Aug 15, 2008 at 11:52:17AM +0200, Abramo Bagnara wrote:
> >> Sorry to show me dense, but I don't see the problem: the request to
> >> allow FILE_READ_ATTRIBUTES only would generate a 000 perms just as if
> >> map_nt_perms was called with only permissions not handled there.
> >>
> >> I'd say that to ask to allow FILE_READ_ATTRIBUTES only don't have to
> >> generate any ACE at all (as this request under an Unix permission model
> >> point of view don't give to user/group any further right).
> >>
> >> Could you explain how a possible conflict with a requested DENY ACE
> >> could happens?
> >
> > Existing file has FILE_READ_DATA|FILE_WRITE_DATA|FILE_READ_ATTRIBUTE S.
> > Acl comes in to change this to FILE_READ_ATTRIBUTES. Samba has to map
> > this to '---' according to you. Oops. Instant deny ACL. Not what was
> > intended.
>
> I try to detail your example as it seems there is some misunderstanding:
>
> NT ACL: Allow SID FILE_READ_DATA FILE_READ_ATTRIBUTES FILE_WRITE_DATA
> Current samba perms for owner, group or others: rw-
> Current samba posix acl: user:abramo:rw-
> Current new NT ACL: Allow SID FILE_READ_DATA FILE_READ_ATTRIBUTES
> FILE_READ_EA FILE_GENERIC_READ FILE_WRITE_DATA FILE_APPEND_DATA
> FILE_WRITE_ATTRIBUTES FILE_WRITE_EA FILE_GENERIC_WRITE
> Proposed is the same as current
>
> NT ACL: Allow SID FILE_READ_ATTRIBUTES
> Current samba perms for owner, group or others: r--
> Current samba posix acl: user:abramo:r--
> Current new NT ACL: Allow SID FILE_READ_DATA FILE_READ_ATTRIBUTES
> FILE_READ_EA FILE_GENERIC_READ
> Proposed samba perms for owner, group or others: ---
> Proposed samba posix acl: entry is removed
> Proposed new NT ACL for owner, group or others: Allow SID EMPTY
> Proposed new NT ACL: ACE is removed
>
> Simply I'm suggesting that this case is treated as it was a request to
> have an empty list of accesses for that SID.

Now re-read the ACL on Windows. The '---' will be seen as a DENY
ACE. That's the problem. POSIX has no deny ACLs so we have to overload
no permissions in order to get the essential deny capability.

Jeremy.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

Jeremy Allison ha scritto:
>>
>> NT ACL: Allow SID FILE_READ_ATTRIBUTES
>> Current samba perms for owner, group or others: r--
>> Current samba posix acl: user:abramo:r--
>> Current new NT ACL: Allow SID FILE_READ_DATA FILE_READ_ATTRIBUTES
>> FILE_READ_EA FILE_GENERIC_READ
>> Proposed samba perms for owner, group or others: ---
>> Proposed samba posix acl: entry is removed
>> Proposed new NT ACL for owner, group or others: Allow SID EMPTY
>> Proposed new NT ACL: ACE is removed
>>
>> Simply I'm suggesting that this case is treated as it was a request to
>> have an empty list of accesses for that SID.
>
> Now re-read the ACL on Windows. The '---' will be seen as a DENY
> ACE. That's the problem. POSIX has no deny ACLs so we have to overload
> no permissions in order to get the essential deny capability.

I'm definitely unable to reproduce what you write with the following
environment:
server: samba-3.0.28a-1ubuntu4.4
client: windows 2000 server

No DENY ACE are re-read from Windows (when needed it's converted to an
empty ALLOW ACE).

The test is rather easy: I've changed the access control from windows
explorer simply taking care to have FILE_READ_ATTRIBUTES and
FILE_READ_EA equal to FILE_READ_DATA (that's the behaviour I'd ask for
samba). To avoid ACE removal by user interface I can leave READ_CONTROL
enabled.

The seen result re-reading the ACE is an empty allow.

This is exactly what I'd expect...

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Sat, Aug 16, 2008 at 09:42:51AM +0200, Abramo Bagnara wrote:
>
> This is exactly what I'd expect...

Hmmm, not what I'd expect :-). I'll have to check into the POSIX
mapping further, been a while since I wrote it. Are you checking
on a system with POSIX ACLs enabled or just straight POSIX permissions ?

Jeremy.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba