Don't allow schema lookups on disk through `$ref` schema references

[johanfylling]

Currently, it is possible to use the file:// scheme in $ref schema references to lookup schemas on the local file system for type-checking:

package test

# METADATA
# schemas:
# - input: {"$ref": "file://schema.json"}
p {
    input == 42
}

Out of concern for security, unnecessary/unwanted file reads should be avoided; so by default, $refs with the file:// scheme should not be allowed. File-reads could be allowed through a capabilities attribute (but might be an unnecessary addition).

[ashutosh-narkar]

File-reads could be allowed through a capabilities attribute (but might be an unnecessary addition).

Are you suggesting extending the capabilities support to specify file refs?

[johanfylling]

Yes @ashutosh-narkar. I'm thinking a boolean attribute to allow all or no file refs might be enough, though.

[ashutosh-narkar]

Sounds good. I think it would be better if we specify the refs in the new field instead of a boolean attribute imo.

[stale[bot]]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.

[ashutosh-narkar]

so by default, $refs with the file:// scheme should not be allowed

@johan could this be part of strict type checking?

[johanfylling]

I think file $refs should probably be disabled by default, and something you need to opt into. But I also don't think the security concern is very big here.

[srenatus]

Conceptually, this would fit nicely with capabilities -- there's a capability for network access, and there could be another one for file system access. After all, it's been modeled after deno's capabilities, which have the same distinction. But I agree, that this might not be necessary from a security perspective. Unless you get an error of some sort that contains the schema including bits read from disk. We'd have to check if that's possible.

[stale[bot]]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. Although currently inactive, the issue could still be considered and actively worked on in the future. More details about the use-case this issue attempts to address, the value provided by completing it or possible solutions to resolve it would help to prioritize the issue.