-
Notifications
You must be signed in to change notification settings - Fork 5
/
README
550 lines (403 loc) · 19.8 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
snitch.el (pronounced like schnitzel) is a firewall for Emacs.
snitch intercepts calls to create network connections or launch
subprocesses. Through user-configured default policies, filter
rules, and user hooks it is able to log and potentially block each
action. It can be configured with ‘M-x customize-group <RET>
snitch’.
Subprocesses and network connections are handled independently,
with their own separate default policies, blacklist and whitelist,
and logging policies.
The main purpose of snitch is network monitoring. Subprocesses are
included because it is extremely common for Emacs packages to
"shell out" to an external program for network access, commonly to
‘curl’. As a side effect, snitch can also effectively audit and
prevent undesired access to other programs.
Notifications can be raised on each logged event by ensuring the
’alert’ package is installed and customizing
‘snitch-enable-notifications’ to t.
=== WHY? ===
Emacs is a general-purpose execution environment, executing with
the full privileges of whichever user launched it. It can read and
create files, obviously, but also spawn external programs, open
network connections, and communicate through pipes. In modern
times, most users manage large collections of third-party packages
through intelligent package managers that automatically pull in any
number of dependencies, updated periodically. Any and all of these
could be a bit naughty, and the sheer quantity of Lisp code in a
modern Emacs install makes it un-auditable.
An Emacs firewall, thus, makes sense. Does *snitch* make sense?
Not really... see the SECURITY section below. But we currently
have nothing, and snitch is better than nothing.
Also, to answer the question: "I wonder if I can make an Emacs
firewall?" Yes! ...well, sort of.
=== MECHANISM ===
The underlying ’firewall’ mechanism is built on function advice
surrounding Emacs’s lowest-level core functions for spawning
connections or subprocesses. When an Emacs package or script makes
such a request, snitch receives it first, and either passes it
through or rejects it based on the current rules. Once a
connection or process is accepted, snitch is no longer involved for
the duration of that particular communication stream.
For each intercepted call, snitch first builds an event object
defining everything snitch knows about the call. The metadata
differs for network connections (host, port, family) and processes
(executable and argument list), but all events share a common set:
calling function, calling function’s file path, calling package,
and request name.
Once an event object is created, it is passed to any hooks defined
in ‘snitch-on-event-functions’ for early processing. If a hook
returns nil, the event is dropped immediately. Otherwise, snitch
then checks the corresponding whitelist (if the default policy is
deny) or the blacklist (if the default policy is allow) and makes
its internal decision. Before executing the decision, it calls the
corresponding hook functions to give the user hooks one more
opportunity to change the decision. Finally, only if the decision
was ‘allow’, snitch executes the original request and passes the
result back to the caller.
As the event flows through the decision tree, it also triggers log
events. There are several different types defined in
‘snitch-log-policies’, and users can subscribe to any combination
of them by customizing ‘snitch-log-policy’. Logs are displayed in
text format in a dedicated log buffer (by default: ‘*snitch
firewall log*’), along with text properties that allow extracting
the event information programatically from a log line with
‘get-text-property’. The text lines can be "pretty printed" by
customizing ‘snitch-log-verbose’.
An example log entry is below, split to several lines for display.
In the actual log, non-verbose logs are a single line.
> [2020-12-03 00:16:50] (whitelisted) -- #s(snitch-network-entry \
> 1606951010.2966838 helm-M-x-execute-command \
> /home/trevor/.emacs.d/elpa/helm-20201019.715/helm-command.el \
> helm 127.0.0.1 127.0.0.1 64222 nil)
With `snitch-log-verbose' enabled, log entries actually do take
several lines:
> [2020-12-03 01:11:27] (blocked) --
> (snitch-network-entry "snitch-network-entry-157d34506664"
>
> :timestamp 1606954287.770638
> :src-fn snitch--wrap-make-network-process
> :src-path "/home/trevor/.emacs.d/snitch/snitch.el"
> :src-pkg user
> :proc-name "google.com"
> :host "google.com"
> :port 80)
=== GETTING SNITCH ===
snitch is published in the MELPA package repository. The recommend
installation method is via an Emacs package manager that supports
MELPA.
use-package:
> (use-package snitch :ensure t)
straight.el:
> (straight-use-package 'snitch)
manually:
> (require 'package)
> (add-to-list 'package-archives
> '("melpa" . "https://melpa.org/packages/"))
> (unless (package-installed-p 'snitch)
> (package-install 'snitch))
> (require 'snitch)
It can also be installed by any package manager that supports git
repositories, or manually via tarball.
quelpa:
> (quelpa '(snitch :repo "mrmekon/snitch-el" :fetcher github))
use-package + quelpa + quelpa-use-package:
> (use-package snitch
> :quelpa (snitch :repo "mrmekon/snitch-el" :fetcher github))
el-get:
> (el-get-bundle mrmekon/snitch-el)
straight.el:
> (straight-use-package
> '(snitch :type git :host github :repo "mrmekon/snitch-el"))
manual:
> (package-install-file "/path/to/snitch-x.y.z.tar")
=== USAGE ===
Enabling snitch is as simple as calling ‘snitch-mode’
interactively, or ‘(snitch-mode +1)’ from your init file.
Initialization does very little, so this is safe to call in your
Emacs init without worrying about deferral or negative consequences
on startup time.
The minimum required initialization is simply:
> (require 'snitch)
> (snitch-mode +1)
An example initialization using ‘use-package’ might look like so:
> (use-package snitch
> :config
> (snitch-mode +1))
snitch then runs in the background, performing its duties according
to your configuration, and logging in its dedicated buffer.
You may add firewall exception rules manually, as covered in the
CONFIGURATION section below. Alternatively, you can also build
filters with a guided UI by switching to the firewall log buffer
(‘*snitch firewall log*’), highlighting an entry that you wish to
filter on, and execute ‘M-x snitch-filter-from-log’. This launches
a popup window that allows you to configure a new filter based on
one or more fields of the selected log line, and add it to either
your blacklist or whitelist.
To disable snitch, call ‘snitch-mode’ interactively, or
‘(snitch-mode -1)’ programmatically. You can restart snitch with
‘snitch-restart’.
=== CONFIGURATION ===
Customize snitch with ‘M-x customize-group <RET> snitch’, or
manually in your Emacs initialization file.
Most users will have five variables that need to be configured
before use:
- ‘snitch-network-policy’ -- whether to allow or deny network
connections by default.
- ‘snitch-process-policy’ -- whether to allow or deny subprocesses
by default.
- ‘snitch-log-policy’ -- which events to log (to see the options,
run ‘M-x describe-variable <RET> snitch-log-policies’)
- ‘snitch-network-*list’ -- filter rules containing exceptions to
the default network policy. See FILTER RULES below. Use
‘-whitelist’ if the default policy is ‘deny’, or ‘-blacklist’ if
the default policy is ‘allow’
- ‘snitch-process-*list’ -- filter rules containing exceptions to
the default process policy. See FILTER RULES below. Use
‘-whitelist’ if the default policy is ‘deny’, or ‘-blacklist’ if
the default policy is ‘allow’
Have a look in ‘snitch-filter.el’ for examples of black/whitelist
filters, and in ‘snitch-test.el’ for contrived examples of pretty
much everything.
==== COMMON CONFIG: DENY ====
A useful configuration is to deny all external communication by
default, but allow certain packages to communicate. This example
demonstrates permitting only the ’elfeed’ package to create network
connections:
> (use-package snitch
> :config
> (setq snitch-network-policy 'deny)
> (setq snitch-process-policy 'deny)
> (setq snitch-log-policy '(blocked whitelisted allowed))
> (add-to-list 'snitch-network-whitelist
> (cons #'snitch-filter-src-pkg '(elfeed)))
> (snitch-mode +1))
==== COMMON CONFIG: ALLOW + AUDIT ====
Another useful configuration is to allow all accesses, but log them
to keep an audit trail. This might look like so:
> (use-package snitch
> :config
> (setq snitch-network-policy 'allow)
> (setq snitch-process-policy 'allow)
> (setq snitch-log-policy '(allowed blocked whitelisted blacklisted))
> (setq snitch-log-verbose t)
> (snitch-mode +1))
==== FILTER RULES ====
Filter rules, as specified in ‘snitch-(process|network)-*list’
variables, are specified as cons cells where the car is a filtering
function, and the cdr is a list of arguments to pass to the
function in addition to the event object:
> (setq snitch-network-whitelist
> '(
> (filter-fn1 . (argQ))
> (filter-fn2 . (argN argP))
> ))
Each filter function should have a prototype accepting EVENT as the
snitch event object in consideration, and ARGS as the list of
arguments from the cdr of the rules entry:
> (defun filter-fn1 (event &rest args))
EVENT is an eieio object defined by ‘snitch-network-entry’ or
‘snitch-process-entry’, and inheriting from ‘snitch-source’.
A trivial function which matches if a single string in the event
object matches a known value might look like so:
> (defun filter-fn1 (event name)
> (string-equal (oref event proc-name) name))
While a more complex filter function might treat ARGS as an
associative list of key/value pairs:
> (defun filter-fn2 (event &rest alist)
> (cl-loop for (aslot . avalue) in alist with accept = t
> do
> (let ((evalue (eieio-oref event aslot))
> (val-type (type-of avalue)))
> (unless (cond
> ((eq val-type 'string) (string-equal avalue evalue))
> (t (eq avalue evalue)))
> (setq accept nil)))
> when (null accept)
> return nil
> finally return accept))
The return value of a filter function determines whether the filter
should take effect. t means "take effect" and nil means "do not
take effect". What that means for the event depends on which list
the filter rule is in. If the rule is in a whitelist, t means
allow and nil means block. If it is in a blacklist, t means block
and nil means allow.
==== HOOKS ====
Events are passed to user-provided hook functions, if specified.
These hooks can subscribe to receive events either immediately on
arrival, upon a final decision, or both. The hooks can change
snitch’s final decision.
Hook functions take two arguments, the type and the event object:
> (defun snitch-hook (type event))
TYPE is one of `snitch-hook-types', and corresponds with the names
of the hook lists. This argument is provided so you can define one
function which can be used in several hooks.
EVENT is an eieio object defined by ‘snitch-network-entry’ or
‘snitch-process-entry’, and inheriting from ‘snitch-source’.
Hooks should return t to allow snitch to continue processing as it
would have, or return nil to reverse snitch’s decision. For hooks
in ‘snitch-on-event-functions’, returning nil cancels all further
processing of the event and blocks it immediately. For other hook
lists, returning nil reverses the action implied by the list name:
returning nil in a ‘snitch-on-allow-functions’ hook causes the
event to be blocked, returning nil in a ‘snitch-on-block-functions’
hook causes it to be allowed.
snitch also supports filtering log entries with hooks via
‘snitch-log-functions’. These hooks can pass, block, or modify
entries before they are printed in the snitch log. See ‘M-x
describe-variable <RET> snitch-log-functions’ for details.
snitch also calls hooks when it starts (‘snitch-init-hook’), shuts
down (‘snitch-deinit-hook’), or opens or closes the log filter
window (‘snitch-log-filter-window-open-hook’,
‘snitch-log-filter-window-close-hook’).
=== PERFORMANCE ===
Performance has not been measured, and should not be assumed to be
particularly good. Nothing is currently optimized.
Memory usage should not be particularly high, as events are
ephemeral and only contain a small amount of metadata. The largest
use of memory is the audit log, which does keep copies of all
events in the log. This can be controlled via
‘snitch-log-buffer-max-lines’.
Firewall rules are traversed linearly, and short-circuit (if an
early rule terminates processing, the subsequent rules will not be
considered). To optimize for performance, the total number of
rules should be kept to a minimum, and most likely to match rules
should be added earlier in the lists.
=== TIMER TRACING ===
Since snitch’s usefulness is highly dependent on the ability to
trace back to the original source that triggered an event, Emacs
timers pose a bit of a challenge. Timers are used to trigger
network requests asynchronously, but have the side effect of losing
the stack trace back to the function or package that initiated it.
To deal with this, snitch optionally supports timer tracing. When
tracing is enabled, by customizing ‘snitch-trace-timers’ to t,
snitch hooks into Emacs’s timer functions, and records backtraces
whenever a timer is registered. If a timer later generates a
snitch-relevant event, snitch concatenates the regular backtrace
with the cached timer backtrace to get a full call stack for the
event.
As an example, here are two snitch log entries when opening RSS
feeds with the elfeed package, which uses timers for web requests:
With ‘snitch-trace-timers’ set to nil (tracing disabled):
> [2020-12-07 21:32:56] (allowed) -- #s(snitch-network-entry \
> 1607373176.6757963 \
> timer-event-handler \
> /usr/share/emacs/27.1/lisp/emacs-lisp/timer.el \
> site-lisp \
> www.smbc-comics.com www.smbc-comics.com 443 nil)
Notice how the source is the function ‘timer-event-handler’ in
‘timer.el’, part of the special ‘site-lisp’ package? *All*
timer-originated network calls appear to originate from that
function, since it is the lowest level Emacs timer dispatch
function. It is impossible to filter on the true source.
Now with ‘snitch-trace-timers’ set to t (tracing enabled):
> [2020-12-07 21:33:06] (allowed) -- #s(snitch-network-entry \
> 1607373186.6863618 \
> elfeed-insert-html
> /home/trevor/.emacs.d/elpa/elfeed-20200910.239/elfeed-show.el \
> elfeed \
> www.smbc-comics.com www.smbc-comics.com 443 nil)
For this event, snitch has successfully traced through the timer to
find the true source, ‘elfeed-insert-html’ in the ‘elfeed’ package!
Timer tracing comes with a cost: snitch has to generate metadata
for every single timer event. If your Emacs usage involves a very
large number of timers, or very high-frequency timers, snitch’s
tracing could lead to delays and inflated memory usage. Consider
carefully whether this is a feature you need, and leave it disabled
if you will not use it, or if you experience any performance issues
while running snitch.
You can run ‘snitch-monitor-unique-timer-fns’ to get a sense of
which timers are currently active. After running that function,
there will be a 60 second delay, followed by printing the names of
all timers that were active during the minute and the number of
times they fired.
Similarly, if you run with timer tracing enabled for a while, you
can use ‘snitch--debug-print-timer-state’ to print a summary of how
many timers snitch has intercepted, and how many saved backtraces
are currently active in memory.
=== SECURITY ===
snitch provides, effectively, zero security.
If you were to ask your Principal Security Engineer friends, they
might say that an effective security boundary must be
"tamper-proof" and provide "complete mediation." snitch does
neither.
Tamper-proof: none at all. Any other Emacs package can simply
disable snitch, or modify it to pass malicious traffic undetected.
Complete mediation: no attempt has been made to verify that *all*
network and subprocess accesses must go through the functions that
snitch hooks. Given the complexity of Emacs, it is extremely
unlikely that they do.
However, your Principal Security Engineer friends also like to
blather on about ’defining your security model’, and a fun game to
play with them is to define your security model such that none of
the insecurities are in it. As so:
Security model: includes malicious adversaries
snitch effectiveness: zero.
Security model: includes no malicious adversaries
snitch effectiveness: great!
snitch is useful for auditing and blocking unwanted features in an
otherwise well-behaving ecosystem. It is handy for getting a
record of exactly what your Emacs is doing, and for fine-tuning
accesses beyond Emacs’s boundaries a little bit better. It will
not, however, save you from the bad guys.
=== KNOWN LIMITATIONS ===
When snitch blocks events, some Emacs functions that seldom throw
errors in normal use will throw errors because of snitch. It is
very likely that blocked connections will cause errors to bubble up
in strange and unexpected ways, as many package authors have not
handled these exceptional cases.
snitch does not intercept domain name resolution (DNS).
snitch has a strong preference for identifying user-provided
packages as the "originating source" of events. Events that you
may consider as originated in built-in/site-lisp code may be
attributed to a user package instead, if one is higher up in the
backtrace. For instance, `helm' may often show up as the source if
installed, since `helm-M-x-execute-command' is often somewhere in
the stack.
snitch has not been tested with IPv6.
snitch has not been tested with inbound connections. In theory, it
can prevent the creation of a listening socket. Once a socket is
open, though, it would not be able to monitor incoming connections
to the socket.
=== TODO ===
- send notifications in batches?
- interactive prompts?
- handle service strings as port numbers
- ensure the inverted negation rules make sense
- add blacklist for timer functions
- profit!
=== VERSION HISTORY ===
v0.3.1 (development)
v0.3.0 (2021-02-02)
- published on MELPA
- make snitch a global minor mode
- introduce (snitch-mode)
- make (snitch-init) private (snitch--init)
- make (snitch-deinit) private (snitch--deinit)
- add init and deinit hooks
- customizable keymap for log filter wizard
- fixed several byte compiler warnings
v0.2.0 (2020-12-09)
- first published version
v0.1.0 (before 2020-12-09)
- Initial development and testing
- Network and process firewall functionality
- Audit logging
- Whitelist + blacklist filtering
- Backtrace processing
- Timer backtrace expansion
- User event and logging hooks
- ert test framework
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; see the file COPYING. If not, write to
the Free Software Foundation, Inc., 51 Franklin Street, Fifth
Floor, Boston, MA 02110-1301, USA.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;