transform: luaxform transform script.

[jlucovsky]

Add the luaxform transform that uses a Lua script to receive and transform a sticky buffer.

Lua transforms receive arguments

• (always): length of input buffer and input buffer
• (always): number of additional arguments (may be 0)
• (when present): argument array (bounded by argument count)

Arguments are passed to the lua script as they appear in the rule:

 luaxform:./lua/lua-transform.lua, bytes 4, offset 13, hash sha256;

When the transform is invoked, 3 additional arguments are passed (arg count will be 3)

• bytes 4
• offset 13
• hash sha256

The Lua script is responsible for parsing and using the arguments and returning a tuple: output-buffer, output-buffer-byte-count

I used this lua script:

function init (args)
    local needs = {}
    return needs
end

function transform(input_len, input, argc, args)
    SCLogNotice("Input length: " .. input_len .. " arg-count: " .. argc)
    for i = 1, argc do
        print("Argument " .. i .. ":", args[i])
    end
    return string.upper(input), input_len
end

return 0

Example rule using the lua script:

alert http any any -> any any (msg:"Lua Xform example"; flow:established;  file.data; luaxform:./lua/lua-transform.lua; content: "abc"; sid: 1;)

Link to ticket: https://redmine.openinfosecfoundation.org/issues/2290

Describe changes:

• Luaxform transform changes

Provide values to any of the below to override the defaults.

• To use an LibHTP, Suricata-Verify or Suricata-Update pull request,
  link to the pull request in the respective _BRANCH variable.
• Leave unused overrides blank or remove.

SV_REPO=
SV_BRANCH=OISF/suricata-verify#2044
SU_REPO=
SU_BRANCH=
LIBHTP_REPO=
LIBHTP_BRANCH=

[jasonish]

Given the rule:

alert http any any -> any any (msg:"Lua Xform example"; flow:established;  file.data; luaxform:./lua/lua-transform.lua; content: "abc"; sid: 1;)

I wonder if we should reconsider the new keyword here... Would it make more sense to have:

xform:lua,./lua/lua-transform.lua;

in case we add another method for transforms? In theory we could also have plugins that register transforms, but I guess those would look more like the current transforms as they'd add a new keyword completely. Just thinking out loud here.

[codecov]

Codecov Report

Attention: Patch coverage is 76.97595% with 67 lines in your changes missing coverage. Please review.

Please upload report for BASE (master@1420c83). Learn more about missing BASE report.
Report is 23 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##             master   #11733   +/-   ##
=========================================
  Coverage          ?   82.58%           
=========================================
  Files             ?      922           
  Lines             ?   249246           
  Branches          ?        0           
=========================================
  Hits              ?   205838           
  Misses            ?    43408           
  Partials          ?        0           

Flag	Coverage Δ
fuzzcorpus	60.40% <28.17%> (?)
livemode	18.71% <15.46%> (?)
pcap	44.07% <18.55%> (?)
suricata-verify	61.90% <76.63%> (?)
unittests	58.95% <21.30%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

[suricata-qa]

ERROR:

ERROR: QA failed on build_asan.

Pipeline 22483

[victorjulien]

Given the rule:

alert http any any -> any any (msg:"Lua Xform example"; flow:established;  file.data; luaxform:./lua/lua-transform.lua; content: "abc"; sid: 1;)

I wonder if we should reconsider the new keyword here... Would it make more sense to have:

xform:lua,./lua/lua-transform.lua;

in case we add another method for transforms? In theory we could also have plugins that register transforms, but I guess those would look more like the current transforms as they'd add a new keyword completely. Just thinking out loud here.

I would consider this to be out of scope for this work. Transforms are currently implemented as regular keywords. We can change that of course, but it's not related to the PR.

[victorjulien]

What would you see happen in the script's init function? I think it's probably not something we need, as the transform is tied to the buffer it will transform.

[jasonish]

What would you see happen in the script's init function? I think it's probably not something we need, as the transform is tied to the buffer it will transform.

I was wondering about the same thing earlier... And was wondering if perhaps a data-file might be loaded, that would fail now due to the sandbox. But imagine a Lua transform that loaded something a TLD database to provide a domain name transformation or something. Or some other heavy initialization of pre-computing some table of sorts?

I don't think it should be required if not needed though, but might be nice to allow it for some one-time initialization.

[victorjulien]

What would you see happen in the script's init function? I think it's probably not something we need, as the transform is tied to the buffer it will transform.

I was wondering about the same thing earlier... And was wondering if perhaps a data-file might be loaded, that would fail now due to the sandbox. But imagine a Lua transform that loaded something a TLD database to provide a domain name transformation or something. Or some other heavy initialization of pre-computing some table of sorts?

I don't think it should be required if not needed though, but might be nice to allow it for some one-time initialization.

This did make me think of one possible case: if the transform would like to query a dataset, it would need some init/thread_init to get a handle.

[jlucovsky]

What would you see happen in the script's init function? I think it's probably not something we need, as the transform is tied to the buffer it will transform.

I was wondering about the same thing earlier... And was wondering if perhaps a data-file might be loaded, that would fail now due to the sandbox. But imagine a Lua transform that loaded something a TLD database to provide a domain name transformation or something. Or some other heavy initialization of pre-computing some table of sorts?
I don't think it should be required if not needed though, but might be nice to allow it for some one-time initialization.

This did make me think of one possible case: if the transform would like to query a dataset, it would need some init/thread_init to get a handle.

Let's keep the init function then?

[jasonish]

Let's keep the init function then?

Optional? If it exists use it, if not assume an empty return value?

[victorjulien]

Let's keep the init function then?

Optional? If it exists use it, if not assume an empty return value?

Works for me. But need to think about init vs thread_init (that I added in my dataset binding work). In init you can't set anything up in the LuaState that will be used at match time. Thats what that new thread_init would offer.

[suricata-qa]

ERROR:

ERROR: QA failed on build_asan.

Pipeline 22622

[suricata-qa]

ERROR:

ERROR: QA failed on SURI_TLPR1_alerts_cmp.

Pipeline 22627

[suricata-qa]

Information: QA ran without warnings.

Pipeline 22743

[suricata-qa]

Information: QA ran without warnings.

Pipeline 22751

[suricata-qa]

WARNING:

field	baseline	test	%
	SURI_TLPR1_stats_chk
.uptime	649	628	96.76%

Pipeline 22762

[jlucovsky]

Continued in #11817