GNU bug report logs -
#45198
28.0.50; Sandbox mode
Previous Next
Full log
Message #275 received at 45198 <at> debbugs.gnu.org (full text, mbox):
Am So., 18. Apr. 2021 um 08:21 Uhr schrieb Eli Zaretskii <eliz <at> gnu.org>:
>
> > From: Philipp <p.stephani2 <at> gmail.com>
> > Date: Sat, 17 Apr 2021 21:52:59 +0200
> > Cc: Mattias Engdegård <mattiase <at> acm.org>,
> > João Távora <joaotavora <at> gmail.com>,
> > 45198 <at> debbugs.gnu.org,
> > stefankangas <at> gmail.com,
> > monnier <at> iro.umontreal.ca,
> > alan <at> idiocy.org
> >
> > > So you are going to suggest that we rely on some auditing of the
> > > syscalls Emacs uses now to decide which ones to filter and which not?
> >
> > I don't mean that we should wade through all potential syscalls that Emacs could make. Typically you can come up with such a Seccomp policy iteratively: run Seccomp in advisory mode (i.e. only log syscalls), then allow the syscalls that are both necessary and harmless in the policy.
>
> Emacs can be invoked to do many different things, and will
> correspondingly present very different profiles of syscalls. Is the
> procedure you envision practical, let alone seamless, given that it
> will have to become part of the maintenance and the release process?
Yes. There aren't that many syscalls to begin with, and Emacs uses
only a small subset of them. New Emacs or libc versions occasionally
introduce new syscalls, but finding and allowing them tends to be not
that big of a deal.
> > > And what about users who make local changes
> > > in their Emacs?
> >
> > They can provide their own Seccomp policies or modify the ones included in Emacs.
>
> What does providing a policy entail? can you describe the procedure of
> tailoring a policy to changes in the Emacs code?
1. Run the Emacs sandbox with the code you want to run.
2. Emacs will crash with SIGSYS if it hits a forbidden/unknown
syscall. Ensure that this generates a coredump.
3. Check the backtrace for the coredump (e.g. coredumpctl debug)
and/or the Seccomp audit logs (ausearch) for the syscall that
triggered the signal.
4. Add a rule for the syscall and its arguments to the BPF generation
program, e.g. lib-src/seccom-filter.c.
5. Regenerate the BPF rule file.
This bug report was last modified 3 years and 7 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.