New profile: obsidian

[konstantin1722]

https://obsidian.md/

[konstantin1722]

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]

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]

Does it work?

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

Please test with firejail-git:

• https://github.com/netblue30/firejail?tab=readme-ov-file#other

(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]

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]

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]

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?

[glitsj16]

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]

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]

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.

[glitsj16]

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]

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]

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]

@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:

• https://wiki.archlinux.org/title/Xinit#xserverrc

[glitsj16]

@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]

@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]

@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.

[konstantin1722]

Why did you remove whitelists and add git?

[kmk3]

@konstantin1722 on Apr 28:

Why did you remove whitelists

It's explained in the suggestion:

• https://github.com/netblue30/firejail/pull/6314#discussion_r1579607441

and add git?

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

• https://github.com/netblue30/firejail/pull/6314/commits/ca4106207e954934125206a263fcf34a222ee79c

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

[konstantin1722]

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]

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]

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.

2. 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]

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.

2. 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?

[konstantin1722]

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]

So... what else is left to do?