seccomp implementation - [closed] about zathura

[sebastinas]

libseccomp has a pkg-config file, please use that.

[sebastinas]

This could simply be a #else.

[sebastinas]

Why is this a global variable?

[sebastinas]

They are never called when WITH_SECCOMP is not defined, so this seems pretty unnecessary.

[sebastinas]

Extra space.

[sebastinas]

Extra space

[sebastinas]

Please follow the usual naming conventions. Call them something like seccomp_enable_protected_mode, etc.

[sebastinas]

Why?

[sebastinas]

On GitLab by @valoq on Jan 28, 2018, 15:52

Commented on zathura/links.c line 211

---

changed this line in version 2 of the diff

[sebastinas]

On GitLab by @valoq on Jan 28, 2018, 15:52

Commented on zathura/libsec.c line 16

---

changed this line in version 2 of the diff

[sebastinas]

On GitLab by @valoq on Jan 28, 2018, 15:52

Commented on zathura/libsec.c line 552

---

changed this line in version 2 of the diff

[sebastinas]

On GitLab by @valoq on Jan 28, 2018, 15:52

Commented on zathura/libsec.h line 7

---

changed this line in version 2 of the diff

[sebastinas]

On GitLab by @valoq on Jan 28, 2018, 15:52

Commented on zathura/main.c line 23

---

changed this line in version 2 of the diff

[sebastinas]

On GitLab by @valoq on Jan 28, 2018, 15:52

---

added 1 commit

• 739a185 - code cleanup

Compare with previous version

[sebastinas]

On GitLab by @valoq on Jan 28, 2018, 15:56

---

Thanks for the comments.
The issues should all be resolved now.

[sebastinas]

Good. Before merging that I think it should be possible to configure the desired seccomp protection during runtime with settings from zathurarc.

[sebastinas]

On GitLab by @valoq on Feb 18, 2018, 10:22

---

Activating the sandbox via zathurarc or command line option is a good idea.
However I have yet to find a clean way to implement this.

One example issue is where to activate the sandbox: When a compile option is used like it is now, the restrictions can be applied right from the start. With options or config files, some parsing has to be done before sandbox activation.

[sebastinas]

On GitLab by @valoq on Feb 19, 2018, 13:44

---

After looking into the zathurarc options I have come up with the following:

Using a config option in zathurarc the sandbox can be initialized after checking the sandbox option at the point where the strict filter is currently activated (right before the document is opened). Alternatively a second new option for a readonly sandbox could be created, deactivating bookmarks (and writing any files) automatically, which would significantly enhance the protection. Parsing the config files and command line options is not covered by the sandbox in this case, but the main risk is the pdf file after all. With this approach I would like to request support in creating the config options and how to read it.

An additions feature that could be implemented some time in the future would be a user prompt/option offering to disable the sandbox after it has been loaded in sandboxed mode. This would however require forking the application and creating a broker/client architecture. (The broker can restart the client without the sandbox, while the client is restricted)
This however will not be something I can work on in the immediate future as it will take quite some work.

[sebastinas]

On GitLab by @valoq on Feb 20, 2018, 12:14

---

The issue with the read only mode has been resolved. Somehow zathura does not need to open files with write permissions after the target document has been opened, which is good but I remember it not working this way before (confused). History files are still being written which means that a) the file was opened before the target file or b) something is not working as I think it is. I will look into this further.

In regards to the zathurarc option, I still need help though. I have not yet succeed in understanding how to set and read the options in an appropriate manner.

[sebastinas]

On GitLab by @valoq on Feb 20, 2018, 12:20

---

added 1 commit

• c0bdd41 - fixed read only mode

Compare with previous version

[sebastinas]

For the config file handling: in zathura/config.c add a new string based option (similar to database) using girara_setting_add supporting values like none (no seccomp at all), normal (with only basic protection), strict (blacklist more syscalls which might also degrade supported features). Then, once the config file was read, i.e. after the call to config_load_files in zathura_init, you can fetch the value stored in the config using girara_setting_get (see the many example in zathura/zathura.c) and then activate the desired protection.

[sebastinas]

On GitLab by @valoq on Feb 22, 2018, 14:29

---

added 1 commit

• 3f983e7 - added sandbox options to zathurarc

Compare with previous version

[sebastinas]

On GitLab by @valoq on Feb 22, 2018, 14:36

---

The sandbox can now be set via the suggested options in zathurarc.

WITH_SECCOMP is now set to 1 by default but depends on the settings in zathurarc and defaults to normal mode, which does not provide significant protection (this is not a sandbox, it only blocks a few syscalls) but should also not interfere with normal operations.

[sebastinas]

Please document this option in the manpage (doc/man/zathurarc.5.rst).

[sebastinas]

So I have been playing a round with the strict mode a bit. One feature that's definitely broken is printing. Is that intended?

[sebastinas]

Missing g_free(sandbox) at the end of this block.

[sebastinas]

Missing g_free(sandbox) at the end.

[sebastinas]

I guess in case of an error this should exit instead of continuing without strict sandbox.

[sebastinas]

Please use girara_error.

[sebastinas]

Please return an error and exit from main.

[sebastinas]

On GitLab by @valoq on Mar 11, 2018, 12:22

Commented on zathura/main.c line 308

---

changed this line in version 5 of the diff

[sebastinas]

On GitLab by @valoq on Mar 11, 2018, 12:22

Commented on zathura/libsec.c line 22

---

changed this line in version 5 of the diff

[sebastinas]

On GitLab by @valoq on Mar 11, 2018, 12:22

Commented on zathura/libsec.c line 23

---

changed this line in version 5 of the diff

[sebastinas]

On GitLab by @valoq on Mar 11, 2018, 12:22

---

added 1 commit

• 5a66aa9 - cleanup and manpage

Compare with previous version

[sebastinas]

On GitLab by @valoq on Mar 11, 2018, 12:26

---

added 1 commit

• 3d06164 - bugfix

Compare with previous version

[sebastinas]

On GitLab by @valoq on Mar 11, 2018, 12:29

---

So I have been playing a round with the strict mode a bit. One feature that's definitely broken is printing. Is that intended?

Yes, the strict mode is intended as a read only mode. Features other then (securely) viewing a document are not intended.

[sebastinas]

This goto doesn't appear to be necessary.

[sebastinas]

The commands that are not supposed to work in strict mode should error out then. Currently :print hangs and makes zathura completely unusable.

[sebastinas]

On GitLab by @valoq on Mar 11, 2018, 16:11

Commented on zathura/main.c line 312

---

changed this line in version 7 of the diff

[sebastinas]

On GitLab by @valoq on Mar 11, 2018, 16:11

---

added 1 commit

• f101efe - fix print in strict sandbox mode

Compare with previous version

[sebastinas]

On GitLab by @valoq on Mar 11, 2018, 16:14

---

The commands that are not supposed to work in strict mode should error out then. Currently :print hangs and makes zathura completely unusable.

I suspect there are still other use cases where the strict mode leads to crashes.

Printing is now covered though.

[sebastinas]

I've merged the current state with some changes. I've disabled seccomp by default until we cover all cases where the filters cause feature degradation.

[sebastinas]

closed