xlat expansion of absent VPs

[Arran Cudbard-Bell]

>>> As far as I'm concerned, the *only* thing FreeRADIUS needs to do is
>>> properly quote the variables it expands into a SQL query, which it
>>> already does.
>> 
>> OK. Then the default substitution should probably only be done for
>> certain modules where it is an issue.
> 
> I think that would be confusing.
> 
>> 
>> On the command line blank arguments do affect programs which use
>> positional arguments as multiple chars of whitespace are condensed.
> 
> You've lost me. On the command line, that's done by the shell, and if people using shell want to preserve whitespace, they must quote appropriately.

Yes, isn't that the security issue were talking about here? Where people don't appropriately quote xlat expansions and then something expands to a zero length string? At least in the context of exec.

If it's known that attributes are sometimes not included in the Access-Requests, then they can be marked as optional with %{%{Attr}:-}, if they're not marked as optional then the server is dealing with RADIUS packets the policy/server configuration was not designed to process, and should fail closed. It should not invent values.

The RADIUS RFCs only specify a framework for the protocol, the actual protocol is established on an implementation by implementation basis, and is made up of the RADIUS framework and set of known attributes. If the attributes change then the protocol has changed and the server should fail closed.

One way to make dealing with this easier is to hack the filter module to verify a minimum set of attributes is present in the request before it goes any further. You'd still need to explicitly mark optional attributes elsewhere, but it'd make debugging easier, and for some attributes you could set default values within the filter.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team