El 14 de marzo de 2019 18:34:54 CET, Phil Sutter <phil@xxxxxx> escribió: >Hi, > >On Thu, Mar 14, 2019 at 02:58:40PM +0100, Pablo Neira Ayuso wrote: >> Hi, >> >> On Thu, Mar 14, 2019 at 12:14:23PM +0100, Fernando Fernandez Mancera >wrote: >> > Hi, >> > >> > I have been thinking more about this today. I don't know how access >to >> > the right-hand-side string from the kernel if it is possible. Sorry >if >> > the question is very dumb, but I may lack experience with the nft >> > registers and RHS data of an expression. >> >> I think you can hide flags from json, which is what Phil suggests, I >> mean, just infer version flags from the syntax, ie. if >> "genre::version" is used, then set of the version flag. >> >> I think Phil is not suggesting kernel changes. That makes sense to me. > >Actually I'm still in the process of understanding how all this works. >What I got so far is (correct me if I'm wrong): osf expr does the >fingerprinting and returns a string which relational expr compares to >right-hand side. This new version flag defines whether osf expr adds >the >version to returned string or not. > Yes that is correct. >Assuming the above is correct, my suggestion of making the flag option >implicit does not quite hold, at least not without painful >postprocessing of relational statement in userspace. > >Right now this all seems to me like enabling multiple comparisons >within >a single relational, i.e. one for genre and the other for version. >Nftables doesn't quite do such things. E.g. matching on two TCP header >fields requires two relationals, e.g. 'tcp dport 22 tcp sport > 1024'. >Internally then, these two statements may be combined into a single >payload match if suitable. I think in this case we can't do that. In my opinion it doesn't make sense to evaluate only the version without the OS genre. Do you agree? Thanks! > >Applying the same logic to osf expression, we would implement 'osf name >foo osf version 3.141' and add 'osf_try_merge()' routine to >'rule_postprocess()' which tries to combine the two statements. >Obviously, this is quite a bit of extra work, not sure if feasible. > >Cheers, Phil
