[Samba] Security leak in map_nt_perms?

Abramo Bagnara abramo.bagnara at gmail.com
Fri Aug 15 09:52:17 GMT 2008


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?


More information about the samba mailing list