bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45198: 28.0.50; Sandbox mode


From: Philipp Stephani
Subject: bug#45198: 28.0.50; Sandbox mode
Date: Sun, 18 Apr 2021 11:11:28 +0200

Am So., 18. Apr. 2021 um 08:21 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp <p.stephani2@gmail.com>
> > Date: Sat, 17 Apr 2021 21:52:59 +0200
> > Cc: Mattias Engdegård <mattiase@acm.org>,
> >  João Távora <joaotavora@gmail.com>,
> >  45198@debbugs.gnu.org,
> >  stefankangas@gmail.com,
> >  monnier@iro.umontreal.ca,
> >  alan@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]