Casper Langemeijer wrote:
> Hi Paul,
>
> Thanks for making this a lot more clear to me. To make the wiki-entry
> complete, (I'll put it in later) how is the score() pseudo function working?
>
> I'm assuming ANY is always lower than a specific login,
> 0.0.0.0 is lower than a specific ip,
> port 0 is lower than a specific port.
>
> In that order.
>
> Or written differently:
> specific port: +1 points
> specific host: +2 points
> specific login: +4 points
>
> Am I right?
No, as you can see in the pseudo code, matching is done only using the
client's socket and the sock_allow string. The login/userid fields are
not taken into account during the scoring. Matching the client socket
against sock_allow is done by bitmasking (logical AND) them using only
the significant bits in the sock_allow spec. If a port is specified, it
has to be the same as the port the client is connecting on, or the
resulting score will be zero.
So if a client connects at 10.1.1.1:143
sock_allow score
0.0.0.0:0 32 # 0/0 is a special case
10.1.1.1:143 32
10.1.0.0/16:143 16
10.0.0.0/8:0 8
10.1.1.1:0 32
10.1.1.1:110 0
> What happens if the userid is empty? Is the login used, or is login
> denied? (I guess the latter, but your example suggests differently)
If the userid is empty, the login is used just like my example suggests.
> If you ever feel like breaking backward compatibility, using regular
> expressions for login would be a very useful feature.
> SELECT sock_allow, sock_deny FROM usermap WHERE 'username' REGEXP login
> is possible in MySQL. In normal situations only field REGEXP '/regexp/'
> is used, but matching a value to a regular expression in the database is
> also possible. (dunno 'bout postgresql and sqlite, or anything about
> performance)
Using regexp in queries was determined to be a bad thing. They are not
used in dbmail at all. In this case, I don't see the added benifit, and
I do forsee a lot of potential problems with people not setting up the
usermap table correctly, or crackers trying to outwit the usermap
feature by using specially crafted login values.
>
>
> Grtz, Casper
>
>
>> > I really like to know exactly how the deny/allow rules are followed, is
>> > it a single record that is evaluated, are record processed in order? and
>> > if they are, in what order?
>>
>> In pseudocode the algorithm is as follows
>>
>> Given a user who tries to login with 'username' on 'clientsocket':
>>
>> rows = select sock_allow,sock_deny,userid
>> from usermap
>> where login in ('username','ANY')
>> foreach row in rows:
>> if match(clientsocket,sock_deny):
>> deny_access
>> rowscore = score(clientsocket,sock_allow)
>> if rowscore > bestscore:
>> bestscore = rowscore; bestrow = row
>>
>> if bestrow:
>> if bestrow['login'] == 'ANY':
>> real_login=expand(username, bestrow['userid'])
>> else:
>> real_login=bestrow['userid']
>>
>>
>> From this you can deduce that setting up the policy you want, you
>> shouldn't use sock_deny, but rather map ANY user to a non-existent userid.
>>
>> login sock_allow sock_deny userid
>> ---------------------------------------------------------------
>> ANY inet:0.0.0.0:0 nosuchusergoawaynow
>> ANY inet:0.0.0.0:110
>> username inet:0.0.0.0:143
>>
>> this way, users will be mapped to a non-existant user by default,
>> denying them access. The second and third records are more specific so
>> when anyone tries to login on port 110, access is granted. But only
>> 'username' is allowed to use port 143.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> DBmail mailing list
> [email protected]
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
