Re: Security concerns for N3 + built-ins?

Hi Patrick

Before answering, I’m unsure what you mean by executing N3 code in isolation?


William

> On Apr 12, 2022, at 2:12 AM, Patrick Hochstenbach <Patrick.Hochstenbach@UGent.be> wrote:
> 
> Thank you William this is very helpful and gives me also some references to study. The EYE reasoner provides an option to execute N3 in isolation. I was wondering if this is just an implementation feature or something that is by design a consideration for any implementation of the N3 spec (or some metadata that can be available which built-ins have these non-isolated capabilities)?
> 
> Patrick
> From: William Van Woensel <william.vanwoensel@gmail.com>
> Sent: 11 April 2022 16:56
> To: Patrick Hochstenbach <Patrick.Hochstenbach@UGent.be>
> Cc: public-n3-dev@w3.org <public-n3-dev@w3.org>
> Subject: Re: Security concerns for N3 + built-ins?
>  
> Hi Patrick,
> 
> Re arbitrary programming abilities, both the jen3 and Eye reasoners allow plugging in custom built-ins - really these can do whatever the underlying programming language allows (Java or Prolog, respectively). Of course, these custom builtins would not be part of the spec - a third-party reasoner implements them at their own risk. Standard built-ins (i.e., part of the spec) have a very specific and well-delineated purpose (e.g., math:sum, log:includes, ..) and should not allow executing arbitrary code.
> 
> Re talking to the outside world, the only standard builtins that come to mind are log:semantics and log:content (see here <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2000%2F10%2Fswap%2Fdoc%2FCwmBuiltins&data=04%7C01%7CPatrick.Hochstenbach%40ugent.be%7C9ed4ca87c3824ea1438308da1bcb7f70%7Cd7811cdeecef496c8f91a1786241b99c%7C1%7C0%7C637852858423669484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=CQfk54HNCTUvnSyXxFXjVFR0Nvs2nDe5Q95pODREYro%3D&reserved=0> for a description) as they are able to load (and parse) content from a URL. If privacy-sensitive data was somehow encoded in this URL (e.g., personal ID) then that would be leaked to the outside. However, there is no risk of (for instance) leaking variable values within a rule that uses these builtins, since no distributed reasoning takes place: the content is simply downloaded and then used in the rule. 
> 
> (That said, log:conclusion allows reasoning over this retrieved content; if the content itself contains a log:semantics directive, then one can imagine situations where a bunch of requests being sent, and data being downloaded.)
> 
> 
> HTH,
> 
> William
> 
>> On Apr 11, 2022, at 4:09 AM, Patrick Hochstenbach <Patrick.Hochstenbach@UGent.be <mailto:Patrick.Hochstenbach@UGent.be>> wrote:
>> 
>> Hello all,
>>  
>> I could need some help to get more insights in the Notation3 specs + built-ins regarding allowing arbitrary programming capabilities and possible side-effects that Notation3 implementations should allow for when implementing the specs. 
>>  
>> Are N3 implementations that follow the specs isolated systems, or do they need they talk to the external world (e.g., accessing external resources)?
>>  
>> I am wondering about this because N3 is quite attractive to be executed near protected resources (e.g., in a the security context of a Solid pod). If I would allow executing arbitrary third party authored Notation3 documents, would there be a risk of information leaking into to the world (Notation3 accessing more information than that I intend to)?
>>  
>> It is not clear for me what side-effects are (including dereferencing URI-s) that must be supported by implementations.
>>  
>> BR
>> Patrick