[Chilli] uamdomain / uamallowed

[David Bird]

Hmm.. then, the considerations are:

- use a wildcard match (regex or fnmatch) to check DNS names

- run through uamallowed (hostnames only) through the uamdomain DNS
response "dynamic walled garden" routine [?]

- to assume any wildcard, such that "google.com" might auto translate to
"^(.+\.)?google.com" (in regex form, for example) [?]

David

PS: need a regex tester? 

cat <<EOF > test-regex.c
#include <sys/types.h>
#include <regex.h>

int main(int argc, char *argv[])
{
  regex_t r;
  if (argc < 3) { printf("%s regex string",argv[0]); exit(1); }
  if (regcomp(&r, argv[1], REG_EXTENDED|REG_NOSUB)) {
    perror("regcomp");
    exit(-1);
  }
  if (regexec(&r, argv[2], 0, 0, 0)) {
    perror("no match");
    exit(-1);
  }
  regfree(&r);
  printf("match!\n");
}
EOF
gcc -o test_regex test-regex.c
./test_regex "^(.+\.)?google.com" "google.com"
match!

On Wed, 2010-11-10 at 17:34 +0100, Wichert Akkerman wrote:
> Hi David,
> 
> If you say "uamdomain example.com" will match "*example.com", does that 
> mean it will also match "badexample.com"? If so that could be a security 
> problem.
> 
> Wichert.
> 
> 
> On 11/10/10 17:03 , David Bird wrote:
> > Well, here is where the change would be... that "google.com" would NOT
> > mean "*google.com" (and "*.google.com isn't the same since it excludes
> > "google.com" itself).
> >
> > Thinking that the best approach might be to basically keep it the way it
> > is, that a uamdomain is always "*domain". The addition will be that
> > hostnames in uamallowed could also be checked in DNS responses to pick
> > up new/round-robin IPs. Why not just re-check the uamallowed at an
> > interval? We do already, but that still would not pick up more dynamic
> > DNS responses (again, round-robin IPs, etc). If "*domain" isn't wanted,
> > then use uamallowed with the hostname. ? We could also add a '!' prefix
> > to dis-authorize hostnames that are otherwise in the uamdomain.
> >
> >
> > On Wed, 2010-11-10 at 16:18 +0200, Henk Kleynhans wrote:
> >> I fall into the "most would consider camp" here... For example, if I
> >> give access to google.com, I expect there to be access to
> >> maps.google.com, mail.google.com, translate.google.com etc without
> >> explicitly setting a wildcard.
> >>
> >>
> >> If I wanted to provide access to only a few subdomains, I would
> >> specify each of them explicitly.
> >>
> >>
> >> Henk
> >>
> >>
> >>
> >>
> >> On Wed, Nov 10, 2010 at 12:05 PM, David Bird<david at coova.com>  wrote:
> >>          By "single domain" you then mean an implicit "*.domain" match?
> >>          I suppose
> >>          that is just nomenclature, but I think most would consider a
> >>          "domain" a
> >>          group of hostnames, not just one (even if that "hostname" is
> >>          "coova.org"). Hmm.. maybe we do explicitly require *-wildcard
> >>          matching,
> >>          but automatically add the "*" prefix if the uamdomain starts
> >>          with a
> >>          '.' (for those who already use ".coova.org", for example, in
> >>          their
> >>          configurations).
> >>
> >>
> >>          On Wed, 2010-11-10 at 09:46 +0100, Wichert Akkerman wrote:
> >>          >  On 11/10/10 06:51 , David Bird wrote:
> >>          >  >  In an effort to make uamdomain a bit more flexible, a
> >>          change is
> >>          >  >  required. Right now, DNS queries ending in any uamdomain
> >>          defined are
> >>          >  >  added to the garden when resolved. This means it's always
> >>          "*uamdomain"
> >>          >  >  in the match. Instead, maybe the "*" should have to be
> >>          explicitly, as in
> >>          >  >  "uamdomain=*.domain.com" so that you can also do single
> >>          hostnames such
> >>          >  >  as "uamdomain=singlehost.domain.com". ?
> >>          >
> >>          >  I had always expected uamdomain to specify a single domain,
> >>          not a
> >>          >  wildcard. I feel pretty strongly wildcards should be
> >>          explicitly
> >>          >  specified since they can be a security risk.
> >>          >
> >>          >  >  Or, uamdomain could be kept as-is (and via an option)
> >>          hostnames in
> >>          >  >  uamallowed can be "re-checked" against DNS to pick up any
> >>          round-robin
> >>          >  >  (or just new) IP addresses to add to garden ?  This way,
> >>          the syntax for
> >>          >  >  uamdomain does not need to change and hostnames used in
> >>          uamallowed will
> >>          >  >  update the walled garden when those hostnames are resolved
> >>          by users (and
> >>          >  >  not just resolved on start-up).
> >>          >
> >>          >  Perhaps cache entries for a configurable amount of time?
> >>          >
> >>          >  Wichert.
> >>          >  _______________________________________________
> >>          >  Chilli mailing list
> >>          >  Chilli at coova.org
> >>          >  http://lists.coova.org/cgi-bin/mailman/listinfo/chilli
> >>
> >>
> >>          _______________________________________________
> >>          Chilli mailing list
> >>          Chilli at coova.org
> >>          http://lists.coova.org/cgi-bin/mailman/listinfo/chilli
> >>
> >>
> >>
> >>
> >> --
> >> Henk Kleynhans
> >> CEO&  Founder
> >> Skyrove (Pty) Ltd
> >> Technology Top 100 - Most Promising Emerging Enterprise
> >> Tel: 0861 768 377
> >> Cell: +27 (84) 3073451
> >> Fax: +27 (86) 6204077
> >> henk at skyrove.com
> >>   blog: www.geekrebel.com
> >>
> >> ------
> >>
> >> "A person with ubuntu is open and available to others, affirming of
> >> others, does not feel threatened that others are able and good, for he
> >> or she has a proper self-assurance that comes from knowing that he or
> >> she belongs in a greater whole and is diminished when others are
> >> humiliated or diminished, when others are tortured or oppressed." -
> >> Desmond Tutu
> >>
> >>
> >>
> >
> >
> > _______________________________________________
> > Chilli mailing list
> > Chilli at coova.org
> > http://lists.coova.org/cgi-bin/mailman/listinfo/chilli
> 
> _______________________________________________
> Chilli mailing list
> Chilli at coova.org
> http://lists.coova.org/cgi-bin/mailman/listinfo/chilli