GH-49760: Document differences between bugs and security vulnerabilities

[alamb]

Rationale for this change

The current security model documented https://arrow.apache.org/docs/dev/format/Security.html

Does not explicitly address what constitutes a bug vs a security vulnerability. We should make this clear

This is a follow on to the security documentation added by @pitrou in

• GH-48868: [Doc] Document security model for the Arrow formats #48870

What changes are included in this PR?

Add a section to the format security document that defines bugs vs security vulnerabilitty

Are these changes tested?

Not sure

Are there any user-facing changes?

Yes as it defines our security posture more generally

• GitHub Issue: [Doc] Document bugs vs security vulnerabilities #49760

[github-actions]

Thanks for opening a pull request!

If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose

Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project.

Then could you also rename the pull request title in the following format?

GH-${GITHUB_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

or

MINOR: [${COMPONENT}] ${SUMMARY}

See also:

• Other pull requests
• Contribution Guidelines - Contributing Overview

[alamb]

@github-actions crossbow submit preview-docs

[github-actions]

Revision: 705ce5c

Submitted crossbow builds: ursacomputing/crossbow @ actions-a1e6cabe5e

Task	Status
preview-docs

[pitrou]

I think such guidelines should really be implementation-specific. Some implementations may want to have different opinions on what deserves a CVE and the associated ceremonial.

[alamb]

I think such guidelines should really be implementation-specific. Some implementations may want to have different opinions on what deserves a CVE and the associated ceremonial.

I am happy to close this PR if others agree (or want this to be targeted just at the C/C++ implementation)

I made a PR for arrow-rs here and I can incorporate the guidance there too

• Document Security Policy arrow-rs#9730

[tustvold]

Here we define DoS as an exploitable issue, but then say that process crashes are not exploitable?

I think what gets tricky is technically any arrow API could be exposed by a client application, and therefore in theory could be exploitable in that applications context.

I wonder if we need to distinguish between network APIs, e.g. arrow flight, and internal APIs?

[alamb]

yeah, I was hedging with "sustained" and "affecting the broader system" . I guess in my mind I don't think we should treat panics or OOMs as security issues (they are bugs certainly)

I want it to be clear to downstream users that they need to take other precautions (like process sandboxing, and cgroups for example) to make their systems resilent rather than assume we will treat every bug as a security issue

[alamb]

Maybe we should just remove "denial of service" from the list 🤔