unpack_nt_owners fails with owner S-1-5-32-544

[simo]

On Wed, 2006-10-25 at 14:51 +1000, tridge at samba.org wrote:
> Simo,
> 
>  > Well, on this, with regard to ACEs, I disagree.
>  > Windows have SIDs, which have no "sex". it doesn't matter if they are
>  > users or groups or something else at all, and this is the key difference
>  > that bites us.
> 
> user sids and groups sids are not the same thing even on windows. The
> things you can do with them are different, so for example a user can't
> 'contain' other users, but a group can contain other users/groups.

I said "with regard to ACEs" because I know there are differences in how
the user token is built. But for ACL checking it doesn't matter what a
SID sid.

> So they do have a 'sex' (hmm, I wonder how many people won't see this
> discussion due to overactive spam filters??).

eh :)

>  > Said that, I want to see a decent solution of course, which I think can
>  > even be to accept there is nothing we can do with some unknown SIDs.
> 
> we can work with them easily. We can't completely prevent all denial
> of service attacks, but (as I noted in an email to the team last
> week), there are any number of denial of service attacks possible
> against Samba and just about any other networked service. If we didn't
> implement something just because a DOS is possible we'd never
> implement anything at all! 

hey, I am not trying to halt progress, just voicing my concern :-)
We can even agree that some DoSs are not important but not that DoS in
general are not, and some is worst than others.

> heck, it would be trivial for any authenticated user to DOS an
> existing Samba3 system. It would even be trivial for them to DOS the
> idmap system. I'm not going to give you a recipe, but if you think for
> more than a minute or two you'll see lots of possibilities.

The current one or the new one ;-)

> The fact is that these DOS attacks have not eventuated, mostly because
> DOS attacks by authenticated users are boring. Still worth avoiding if
> the cost is not too high, but not worth halting development over.

Sure, I tell you why I think this different.

Usually by DoS attacks one refer to a technique that is able to bring
the service to a halt but that once the DoS attack is stopped the
service is automatically restored or can be easily restarted and
immediately available again.

A DoS against the UID/GID space instead does not "stop" after the
attack. Once the ID space is filled up, you need to manually remove
mappings, change HWMs and handle situations where a legit SID slipped in
with a lot of bogus ones. My point is that curing a DoS like that is a
much bigger effort.

Now we can well accept that too, I'd be a bit uncomfortable, but we may
have an conf option to let the admin decide what to risk maybe? :-)

> Unauthenticated remote DOS attacks are interesting, as they can be
> launched by people remotely against servers, and can be payloads in
> worms and other nasties. The foreign SID attack only makes sense as an
> authenticated DOS, so it is not a reason to panic.

Well, on windows it is not that difficult to become and act as an
authenticated user, it is the land of malicious codes :)

>  > I know that perfectly. Still you can't really have an ACL mapping
>  > working perfectly if you don't know what a SID is (exp if there are DENY
>  > ACEs involved).
> 
> yes, it can work perfectly for ACEs! The dual ACE schema for working
> with foreign SIDs gives perfect semantics with respect to any access
> control query you throw at the ACL. It doesn't fix all the other
> differences between the different ACL types, but it does completely
> fix the behaviour with respect to SIDs of unknown 'sex'. Yes, it works
> for DENY ACEs.

thinking again I guess the problems in mapping DENY ACEs to posix ACLs
is the same with or without knowing what type an entry is. So when it
does not work, it simply don't.

>  > The problem I put on the table is: how do you avoid depletion of the
>  > UID/GID space by malicious users?
> 
> right now, if you have a malicious user on any unix system you are
> screwed. You are even more screwed if you run Samba or any other
> complex networking service. Despite this fact, the world has not come
> to an end :-)

Why do you talk of "malicious user on a unix system" ?
It may well be done from a windows system.

> I do have some longer term approaches I am looking at to defeat DOS
> attacks on Samba, but they are very much long term approaches. Lets
> not get hung up on one DOS vector now and shut out a solution to a
> real problem for the sake of an imagined one.

Yeah I know, but the kind of DoS we will solve with your approach is for
easily "renewable" resources, like memory space, disk space, cpu power,
or network bandwidth. I think this case is a bit different, but then
maybe it is because I am currently working on that code in samba 3 and
the exposure is influencing my global view. So if nobody else sees this
as a problem, I won't complain further.

>  > That's why Samba 3 by default deny any mapping for unknown SIDs, and
>  > this should not be changed until we solve the little nasty detail of the
>  > DoS.
> 
> if that's the reason foreign SIDs aren't allowed then its a very bad
> reason :)

Well that, and the fact we don;t have a strategy to map them
currently :-)

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org