Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New profile: obsidian #6314

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

konstantin1722
Copy link

@konstantin1722 konstantin1722 commented Apr 17, 2024

@kmk3 kmk3 changed the title profiles: add a profile for obsidian New profile: obsidian Apr 17, 2024
Copy link
Collaborator

@kmk3 kmk3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to clean it up and make it a redirect to electron-common:

obsidian.profile

# Firejail profile for obsidian
# Description: Personal knowledge base and note-taking with Markdown files.
# This file is overwritten after every install/update
# Persistent local customizations
include obsidian.local
# Persistent global definitions
include globals.local

noblacklist ${DOCUMENTS}
noblacklist ${HOME}/.config/git
noblacklist ${HOME}/.config/obsidian
noblacklist ${HOME}/.gitconfig

include disable-common.inc
include disable-devel.inc
include disable-exec.inc
include disable-interpreters.inc
include disable-programs.inc
include disable-xdg.inc

whitelist ${DOCUMENTS}
whitelist ${HOME}/.config/git
whitelist ${HOME}/.config/obsidian
whitelist ${HOME}/.gitconfig

ipc-namespace
no3d

# from `firejail --build` (0.9.72)
#private-bin basename,bash,cat,cut,electron*,gawk,git,grep,obsidian,realpath,tr
#private-etc ati,ca-certificates,drirc,fonts,gitattributes,gitconfig,gnutls,gtk-3.0,hosts,libva.conf,nsswitch.conf,vulkan,xdg

# Redirect
include electron-common.profile

Does it work?

Though I'm not sure about whitelisting in ${HOME}.

Is there a default/recommended "vault" location?

Are they usually stored anywhere?

etc/profile-m-z/obsidian.profile Outdated Show resolved Hide resolved
@konstantin1722
Copy link
Author

konstantin1722 commented Apr 18, 2024

Does it work?

No. My firejail package doesn't have "electron-common.profile". But there is just "electron.profile".

Though I'm not sure about whitelisting in ${HOME}.
Is there a default/recommended "vault" location?
Are they usually stored anywhere?

No, storage is located where the user specifies, there can be several of them. whitelist ${DOCUMENTS} is best to delete it.

With your advice:

obsidian.profile

# Firejail profile for obsidian
# Description: Personal knowledge base and note-taking with Markdown files.
# This file is overwritten after every install/update
# Persistent local customizations
include obsidian.local
# Persistent global definitions
include globals.local

noblacklist ${HOME}/.gitconfig
noblacklist ${HOME}/.config/git
noblacklist ${HOME}/.pki/nssdb
noblacklist ${HOME}/.cache/AMD
noblacklist ${HOME}/.cache/nvidia
noblacklist ${HOME}/.local/share/vulkan
noblacklist ${HOME}/.local/share/vulkan/implicit_layer.d
noblacklist ${HOME}/.config/vulkan
noblacklist ${HOME}/.local/share/vulkan/loader_settings.d
noblacklist ${HOME}/.config/kdedefaults
noblacklist ${HOME}/.Xdefaults-desktop-pc
noblacklist ${HOME}/.config/kdedefaults/gtk-3.0
noblacklist ${HOME}/.cache/mesa_shader_cache
noblacklist ${HOME}/.local/share/applnk
noblacklist ${HOME}/.config/obsidian

whitelist ${HOME}/.gitconfig
whitelist ${HOME}/.config/git
whitelist ${HOME}/.pki/nssdb
whitelist ${HOME}/.cache/AMD
whitelist ${HOME}/.cache/nvidia
whitelist ${HOME}/.local/share/vulkan
whitelist ${HOME}/.local/share/vulkan/implicit_layer.d
whitelist ${HOME}/.config/vulkan
whitelist ${HOME}/.local/share/vulkan/loader_settings.d
whitelist ${HOME}/.config/kdedefaults
whitelist ${HOME}/.Xdefaults-desktop-pc
whitelist ${HOME}/.config/kdedefaults/gtk-3.0
whitelist ${HOME}/.cache/mesa_shader_cache
whitelist ${HOME}/.local/share/applnk
whitelist ${HOME}/.config/obsidian

noblacklist /run/systemd/machines/api.obsidian.md
noblacklist /run/systemd/machines/api.obsidian.md
noblacklist /run/systemd/resolve/io.systemd.Resolve
noblacklist /run/udev/control

whitelist /run/systemd/machines/api.obsidian.md
whitelist /run/systemd/resolve/io.systemd.Resolve
whitelist /run/systemd/machines/raw.githubusercontent.com
whitelist /run/udev/control
whitelist /usr/share/applnk

ipc-namespace

nonewprivs
noroot

?HAS_APPIMAGE: notv
?HAS_APPIMAGE: nou2f

protocol unix,inet,inet6,netlink,

# If you need networking, enable the firewall and disable "net none"
net none        # disable network
#netfilter      # enable default firewall in sandbox

seccomp !chroot # allowing chroot, just in case this is an Electron app
shell none

private-bin git,cat,gawk,tr,realpath,cut,grep,basename,bash,obsidian,electron28
private-etc gitattributes,gitconfig,ca-certificates,libva.conf,vulkan,ati,nsswitch.conf,hosts,xdg,gtk-3.0,drirc,fonts,gnutls,

?HAS_APPIMAGE: private-lib

include electron.profile

electron.profile

# Firejail profile for electron
# Description: Build cross platform desktop apps with web technologies
# This file is overwritten after every install/update
# Persistent local customizations
include electron.local

noblacklist ${HOME}/.config/Electron
noblacklist ${HOME}/.config/electron*-flag*.conf

include disable-common.inc
include disable-devel.inc
include disable-exec.inc
include disable-interpreters.inc
include disable-programs.inc
include disable-xdg.inc

whitelist ${DOWNLOADS}
whitelist ${HOME}/.config/Electron
whitelist ${HOME}/.config/electron*-flag*.conf
include whitelist-common.inc
include whitelist-runuser-common.inc
include whitelist-usr-share-common.inc
include whitelist-var-common.inc

# Add the next line to your electron.local if your kernel allows unprivileged userns clone.
#include electron-hardened.inc.profile

apparmor
caps.keep sys_admin,sys_chroot
netfilter
nodvd
nogroups
noinput
notv
nou2f
novideo

disable-mnt
private-cache
private-dev
private-tmp

dbus-user none
dbus-system none

Do I understand correctly that including profile at the end will override some parameters (if any, except noblacklist)?

@konstantin1722
Copy link
Author

I don't have a lot of time right now, but I will be testing this and studying the firejail documentation more. I will be looking into this anyway as I use obsidian every day.

Right now I'm trying to find the minimum acceptable parameters to run, then I'll deal with the Obsidian features that aren't working at the moment. For example, there is a function to open sites inside obsidian, as well as drag-and-drop and the like, which doesn't work at the moment.

@kmk3
Copy link
Collaborator

kmk3 commented Apr 18, 2024

Does it work?

No. My firejail package doesn't have "electron-common.profile". But there is
just "electron.profile".

Please test with firejail-git:

(That is, install firejail-git from the AUR if on Arch or just building
firejail from source)

There has been a refactoring of electron profiles and this should help ensure
that it works on the upcoming release.

Though I'm not sure about whitelisting in ${HOME}.
Is there a default/recommended "vault" location?
Are they usually stored anywhere?

No, storage is located where the user specifies, there can be several of
them. whitelist ${DOCUMENTS} is best to delete it.

Alright, then these should also be removed:

whitelist ${HOME}/.gitconfig
whitelist ${HOME}/.config/git
whitelist ${HOME}/.pki/nssdb
whitelist ${HOME}/.cache/AMD
[...]

Or else it will have the same effect.

Any whitelisting in ${HOME} means that non-whitelisted directories will not
appear in the sandbox.

With your advice, obsidian.profile:

Please update the PR directly with new changes to make reviews easier.

(I only posted my version in the comments because I rewrote most of it)

Do I understand correctly that including profile at the end will override
some parameters (if any, except noblacklist)?

Yes, including a profile is roughly equivalent to copying and pasting its
contents.

@konstantin1722
Copy link
Author

I have a few quandaries that I haven't sorted out yet:

  1. I've been building and testing a profile on Wayland, should I rename the file to obsidian-wayland.profile?
  2. Are there any additional security settings that are different for Wayland and X11? For example, I remember that some profiles use --x11 is there something like that for Wayland and is it needed at all?
  3. For now I have removed the line seccomp !chroot as Obsidian works without it. Also, I have not fully understood all the risks of this function. In the imported profile blink-common.profile there are lines caps.keep sys_admin,sys_chroot, are they unnecessary for Obsidian? In general I don't really understand this kind of profile file architecture from a security point of view.

Also, I haven't been able to fix the bugs yet:

LaunchProcess: failed to execvp:
xdg-settings

As well as the emerging warnings:

Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted

I removed the permissions that are required for Obsidian plugins, I think it should be set by the user separately, as plugins can do anything.

@glitsj16
Copy link
Collaborator

I've been building and testing a profile on Wayland, should I rename the file to obsidian-wayland.profile?

In general there's no X11 versus Wayland separation in the naming of profiles. Only when upstream applications target Wayland specifically, like firefox-wayland for example, we need to ensure there's a specific firefox-wayland.profile (which redirects to firefox.profile). AFAICT Obsidian doesn't need this.

Are there any additional security settings that are different for Wayland and X11? For example, I remember that some profiles use --x11 is there something like that for Wayland and is it needed at all?

Only difference in this context is blacklisting ${RUNUSER}/wayland-* when Wayland is not supported by the application, or for CLI apps in general. Again, AFAICT Obsidian doesn't need anything special here.

Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted

These warnings are common on OS'es that follow the HFS (Hierarchical File System) layout. Can be safely ignored on such platforms.

For now I have removed the line seccomp !chroot as Obsidian works without it.

This can get tricky. Some distributions enable unprivileged user namespaces by default these days on their kernels, others still keep that disabled. Did you test replacing seccomp !chroot with seccomp? See this Arch Wiki page for more details.

@konstantin1722
Copy link
Author

One last point I would like to clarify. Obsidian can open external programs like Dolphin (kde) or a browser. Is it possible to allow it to do this or is such a scenario possible only if the programme is run in the same sandbox?

@konstantin1722 konstantin1722 marked this pull request as ready for review April 24, 2024 11:00
nonewprivs
noroot

protocol unix,inet,inet6,netlink,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Syntax: remove trailing comma.
Question: is netlink really needed?

private-bin cat,gawk,tr,realpath,cut,grep,basename,bash,obsidian,electron28,
private-etc libva.conf,vulkan,ati,xdg,gtk-3.0,drirc,fonts,

?HAS_APPIMAGE: private-lib
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

#
#private-etc ca-certificates,nsswitch.conf,hosts,gnutls,

private-bin cat,gawk,tr,realpath,cut,grep,basename,bash,obsidian,electron28,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sort.

Copy link
Collaborator

@glitsj16 glitsj16 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use new group syntax for private-etc and some other remarks.

@glitsj16
Copy link
Collaborator

glitsj16 commented Apr 24, 2024

One last point I would like to clarify. Obsidian can open external programs like Dolphin (kde) or a browser. Is it possible to allow it to do this or is such a scenario possible only if the programme is run in the same sandbox?

We generally don't support sandboxed file managers inside other profiles. Doing so would dramatically weaken such profiles.

You can add support for opening links with Firefox. Doing so will need a few changes though:

add a comment like the below:

# The lines below are needed to find the default Firefox profile name, to allow
# opening links in an existing instance of Firefox (note that it still fails if
# there isn't a Firefox instance running with the default profile; see #5352)
noblacklist ${HOME}/.mozilla
whitelist ${HOME}/.mozilla/firefox/profiles.ini

# allow D-Bus communication with firefox for opening links
ignore dbus none
dbus filter
dbus-user.talk org.mozilla.*
  • obviously you'll also need to add firefox to private-bin
  • disable net none

@konstantin1722
Copy link
Author

I decided to leave the default network as most users will prefer to leave network access.

I started getting this message, can you tell me what it means?

Warning: An abstract unix socket for session D-BUS might still be available. Use --net or remove unix from --protocol set.

I sorted the records (I hope I understood correctly what you meant).

I didn't add the @default group, as its contents seemed redundant to me.

@konstantin1722
Copy link
Author

konstantin1722 commented Apr 25, 2024

You can add support for opening links with Firefox.

I tried doing this, but when I try to open the link, nothing happens, it says in the output:

Opening URL: https://www.some.url.example
LaunchProcess: failed to execvp:
xdg-open

Perhaps Obsidian opens external links in some other way and a different setting is needed?

UPD: I tried what is said here #6275, but nothing changed.

etc/inc/disable-programs.inc Outdated Show resolved Hide resolved
etc/profile-m-z/obsidian.profile Outdated Show resolved Hide resolved
etc/profile-m-z/obsidian.profile Outdated Show resolved Hide resolved
etc/profile-m-z/obsidian.profile Outdated Show resolved Hide resolved
etc/profile-m-z/obsidian.profile Show resolved Hide resolved
@glitsj16
Copy link
Collaborator

I tried doing this, but when I try to open the link, nothing happens, it says in the output:
Opening URL: https://www.some.url.example
LaunchProcess: failed to execvp:
xdg-open

The private-bin option can become somewhat of a rabbit-hole. Your profile doesn't include xdg-open (nor xdg-settings you mentioned above). You can test URL opening with ignore private-bin and add all the required commands in a nicely sorted private-bin later.

@glitsj16
Copy link
Collaborator

glitsj16 commented Apr 25, 2024

I didn't add the @default group, as its contents seemed redundant to me.

The @default group isn't designed to be explicitly mentioned in private-etc. Firejail will always include it by default, hence the name.

@glitsj16
Copy link
Collaborator

glitsj16 commented Apr 25, 2024

Warning: An abstract unix socket for session D-BUS might still be available. Use --net or remove unix from --protocol set.

This is a very commonly seen warning. Abstract unix sockets (see man unix) have a path name starting with the NUL character, effectively zeroing their path length. As such they are not represented in the file system. They can use the remaining 107 characters to define a unique identifier, which other programs can use to connect.

The ss command can tell you if your system uses them:

$ sudo ss --no-header --oneline -lpx src @/tmp/.X11-unix/*

Note that these are not the regular unix sockets found in /tmp/.X11-unix/*.
You'd need a patched Xorg stack to disable the abstract unix sockets, which most if not all distro's don't offer. It's one of the reasons people started to move away from X11 into Wayland...

@kmk3
Copy link
Collaborator

kmk3 commented Apr 25, 2024

@glitsj16 on Apr 25:

Note that these are not the regular unix sockets found in /tmp/.X11-unix/*.
You'd need a patched Xorg stack to disable the abstract unix sockets, which
most if not all distro's don't offer. It's one of the reasons people started
to move away from X11 into Wayland...

To disable abstract unix sockets, it should be enough to pass -nolisten local
to Xorg.

I don't think that needs any patching and it seems to have been supported for
many years (at least on Arch).

Details:

@glitsj16
Copy link
Collaborator

@kmk3

To disable abstract unix sockets, it should be enough to pass -nolisten local
to Xorg.
I don't think that needs any patching and it seems to have been supported for
many years (at least on Arch).

True. Yet it depends though. Some widely used DMs like GDM don't have an easy way to add -nolisten local. To the contrary, Lightdm can be easily configured to disable both TCP connections + abstract X11 socket via its xserver-command configuration option.

Anyway, apologies for the mixup and the potentially confusing side-stepping here.

@kmk3
Copy link
Collaborator

kmk3 commented Apr 25, 2024

@glitsj16 on Apr 25:

To disable abstract unix sockets, it should be enough to pass -nolisten local
to Xorg.
I don't think that needs any patching and it seems to have been supported for
many years (at least on Arch).

True. Yet it depends though. Some widely used DMs like GDM don't have an
easy way to add -nolisten local. To the contrary, Lightdm can be easily
configured to disable both TCP connections + abstract X11 socket via its
xserver-command configuration option.

Indeed, the problem is usually with login managers not supporting it directly
and also making it hard to pass additional arguments to the X server.

Otherwise it's trivial to make it work (such as adding it to .xserverrc).

Anyway, apologies for the mixup and the potentially confusing side-stepping
here.

All good.

@glitsj16
Copy link
Collaborator

@kmk3

Indeed, the problem is usually with login managers not supporting it directly
and also making it hard to pass additional arguments to the X server.

I've added a note to my to-do list about this. Might make a nice general Firejail wiki addition.

Copy link
Collaborator

@glitsj16 glitsj16 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please change obsidian-wayland references.

@konstantin1722
Copy link
Author

Why did you remove whitelists and add git?

@kmk3
Copy link
Collaborator

kmk3 commented Apr 29, 2024

@konstantin1722 on Apr 28:

Why did you remove whitelists

It's explained in the suggestion:

and add git?

The git paths aren't new; they were in the original commit:

Why were they removed? Isn't git used for syncing?

@konstantin1722
Copy link
Author

It's explained in the suggestion

You explained how whitelist works, not the reason for removing those instructions. Do I understand correctly that with the current profile without whitelist, the program running in the profile will have access to more files? If the answer is yes, then why give obsidian more than it needs?

Why were they removed? Isn't git used for syncing?

Only when using the obsidian plugin, plugins are installed by users, there is nothing like that by default.

@kmk3
Copy link
Collaborator

kmk3 commented Apr 30, 2024

It's explained in the suggestion

You explained how whitelist works, not the reason for removing those
instructions. Do I understand correctly that with the current profile without
whitelist, the program running in the profile will have access to more files?

Yes.

If the answer is yes, then why give obsidian more than it needs?

Because there is no default location for vaults, so a user may place (and
already have) them at arbitrary locations in ${HOME}. The text editor
profiles that are enabled by default in firecfg.config (such as geany, gedit
and kate) do not enable whitelisting in ${HOME} either.

Why were they removed? Isn't git used for syncing?

Only when using the obsidian plugin, plugins are installed by users, there is
nothing like that by default.

I think it makes sense to support common plugins on profiles, especially when
the drawback is not significant.

In this case, the git paths are already read-only (see disable-common.inc).

@konstantin1722
Copy link
Author

The text editor profiles...

But Obsidian is not a text editor in the sense you are talking about (kate and the like).

  1. When you create a storage, it is a folder with service files in it, similar to a .git folder when you create repositories. You cannot open files that do not belong to the storage. So it doesn't make sense to allow access to files outside the storage.

So, I think that a user who uses firejail has to specify the path to his storage himself, in one of the available ways.

  1. I don't have statistics on common plugins, but at the same time popular plugins are many. Besides, plugins are separate programs, they can do anything (for example, doing fork with a C++ programme or running a bash script.), it's unrealistic to include all of them in the profile. One of the main motivations for creating a profile for Obsidian is precisely the plugins and the lack of guarantee from Obsidian developers that the plugins are safe. At the same time, most plugins do not require additional permissions (so they work "inside" the Obsidian).

So I think it's better to do the maximum restriction via whitelisting, and not even include the ${DOCUMENTS} folder.

Correct me if I've got something wrong.

@kmk3
Copy link
Collaborator

kmk3 commented May 1, 2024

The text editor profiles...

But Obsidian is not a text editor in the sense you are talking about (kate
and the like).

  1. When you create a storage, it is a folder with service files in it,
    similar to a .git folder when you create repositories. You cannot open
    files that do not belong to the storage.

And just like other text files and git repositories, this folder can be placed
in arbitrary places in ${HOME}.

So it doesn't make sense to allow access to files outside the storage.

Where is the storage located?

So, I think that a user who uses firejail has to specify the path to his
storage himself, in one of the available ways.

  1. I don't have statistics on common plugins, but at the same time popular
    plugins are many. Besides, plugins are separate programs, they can do
    anything (for example, doing fork with a C++ programme or running a bash
    script.), it's unrealistic to include all of them in the profile.

I'm only talking about the git plugin.

Syncing documents seems like a rather common use case.

What would be the drawback of allowing the git paths?

So I think it's better to do the maximum restriction via whitelisting, and
not even include the ${DOCUMENTS} folder.

Correct me if I've got something wrong.

Then where would the vault be placed?

Have you actually tried what you're suggesting?

Try to use the profile with no ${DOCUMENTS} and whitelisting of only the
config path (and no local profile customizations), create a new vault at the
root of ${HOME}, then close and reopen the program. Is the vault still
there?

nonewprivs
noroot
protocol unix,inet,inet6
#net none
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does it do network-wise?

Just download and update plugins?

I'd leave a comment to clarify:

Suggested change
#net none
#net none # networking is needed to download/update plugins

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check for obsidian updates, check for plugin updates, review and install plugins in the built in plugin manager, and network features for plugins that use them. In other words, if the user allows networking, it also allows network access to any arbitrary plugin.

@konstantin1722
Copy link
Author

Try to use the profile with no ${DOCUMENTS} and whitelisting of only the
config path (and no local profile customizations), create a new vault at the
root of ${HOME}, then close and reopen the program. Is the vault still
there?

Of course not. The user is supposed to add their own add-in over the profile or edit the .desktop file to add whitelist={path to storage (vault)}.

Then where would the vault be placed?

The location can be anything, including outside ${HOME}, depends on the user's preference. When obsidian is started, you are prompted to open or create a storage (vault). Think of Obsidian more as a note-taking programme (thinking by writing) or a reference system, rather than a programme for opening arbitrary text files and documents. Although if there is such a tradition, you can leave the permission at ${DOCUMENTS}, I for example don't use the default folders at all.

Have you actually tried what you're suggesting?

Yes, I am using the old profile with whitelists and added the whitelist={path to my storage (vault)} parameter to Exec= in the .desktop file.

I'm only talking about the git plugin.
Syncing documents seems like a rather common use case.
What would be the drawback of allowing the git paths?

If reasoned that way you are right, on the other hand the usefulness of a particular feature is subjective. I personally use this plugin to be able to roll back and compare changes. Obsidian has an official synchronisation feature, it is available after purchasing a subscription.

Again, the main reason I brought up the topic of removing git access is because it is not a default feature. If the user doesn't use this plugin, Obsidian and all other plugins will get access to some git configs, I'm not sure what's in there, but probably some personal information (deanomising) like email and such. Isn't that weird?

Perhaps I initially misunderstood the "isolation philosophy". What is the point of giving a potentially malicious program (in this case a suspicious plugin) access to many files in ${HOME} (albeit read-only), even with disable-common.inc taken into account, anything not explicitly blocked will be accessible unless a whitelist is used, right?

I thought the programme should only allow what it needs and no more, anything else is not standard usage scenarios that may not be "safe".

@konstantin1722
Copy link
Author

So... what else is left to do?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants