[issue47260] os.closerange() can be no-op in a seccomp sandbox

[miss-islington]

miss-islington  added the comment:


New changeset 89697f7374ea947ebe8e36131e2d3e21fff6fa1d by Miss Islington (bot) 
in branch '3.10':
bpo-47260: Fix os.closerange() potentially being a no-op in a seccomp sandbox 
(GH-32418)
https://github.com/python/cpython/commit/89697f7374ea947ebe8e36131e2d3e21fff6fa1d


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47260] os.closerange() can be no-op in a seccomp sandbox

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Good catch.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47260] os.closerange() can be no-op in a seccomp sandbox

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +30445
pull_request: https://github.com/python/cpython/pull/32420

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47260] os.closerange() can be no-op in a seccomp sandbox

[Gregory P. Smith]

Gregory P. Smith  added the comment:


New changeset 1c8b3b5d66a629258f1db16939b996264a8b9c37 by Alexey Izbyshev in 
branch 'main':
bpo-47260: Fix os.closerange() potentially being a no-op in a seccomp sandbox 
(GH-32418)
https://github.com/python/cpython/commit/1c8b3b5d66a629258f1db16939b996264a8b9c37


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47260] os.closerange() can be no-op in a seccomp sandbox

[Alexey Izbyshev]

Change by Alexey Izbyshev :


--
keywords: +patch
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47260] os.closerange() can be no-op in a seccomp sandbox

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

> It's been years now and that hasn't happened, even with more recent flag 
> additions. I think it's safe to say it won't, and such a fallback upon error 
> won't put us back into a bogus pre-close_range situation where we're 
> needlessly close()ing a bunch of closed fds.

Yes, I also find it unlikely that close_range() will start reporting an error 
if it fails to close some fd, especially if not given some new flag. Such error 
reporting doesn't seem very useful to userspace because there is no way to 
associate the error with the fd.

But even if such change happens, it will be just a performance regression, not 
a potential correctness/security issue.

--
keywords:  -patch
stage: patch review -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47260] os.closerange() can be no-op in a seccomp sandbox

[Alexey Izbyshev]

Change by Alexey Izbyshev :


--
keywords: +patch
pull_requests: +30443
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/32418

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47260] os.closerange() can be no-op in a seccomp sandbox

[Kyle Evans]

Kyle Evans  added the comment:

Sure, sounds good to me. The original theory (IIRC, I've slept many times since 
then :-)) was that we already know first/last are valid and there are no other 
defined errors, so 'other errors' must be because close_range has started 
percolating up something from closing individual files.

It's been years now and that hasn't happened, even with more recent flag 
additions. I think it's safe to say it won't, and such a fallback upon error 
won't put us back into a bogus pre-close_range situation where we're needlessly 
close()ing a bunch of closed fds.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47260] os.closerange() can be no-op in a seccomp sandbox

[Alexey Izbyshev]

New submission from Alexey Izbyshev :

After #40422 _Py_closerange() assumes that close_range() closes all file 
descriptors even if it returns an error (other than ENOSYS):

if (close_range(first, last, 0) == 0 || errno != ENOSYS) {
/* Any errors encountered while closing file descriptors are ignored;
 * ENOSYS means no kernel support, though,
 * so we'll fallback to the other methods. */
}
else
/* fallbacks */


This assumption can be wrong on Linux if a seccomp sandbox denies the 
underlying syscall, pretending that it returns EPERM or EACCES. In this case 
_Py_closerange() won't close any descriptors at all, which in the worst case 
can be a security issue.

I propose to fix this by falling back to other methods in case of *any* 
close_range() error. Note that fallbacks will not be triggered on any problems 
with closing individual file descriptors because close_range() is documented to 
ignore such errors on both Linux[1] and FreeBSD[2].

[1] https://man7.org/linux/man-pages/man2/close_range.2.html
[2] https://www.freebsd.org/cgi/man.cgi?query=close_range=2

--
assignee: izbyshev
components: Library (Lib)
keywords: 3.10regression
messages: 416986
nosy: gregory.p.smith, izbyshev, kevans, kevans91
priority: normal
severity: normal
status: open
title: os.closerange() can be no-op in a seccomp sandbox
type: behavior
versions: Python 3.10, Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com