kodi: can access non-media paths

[tomasz-c]

Description

I noticed that the kodi profile for firejail 0.9.68 does not seem to work.

From the file manager in Kodi I can browse all directories, drives (not just those defined in the profile) and delete data from them (if Linux permissions allow it). Surely in some previous version this worked correctly.

Steps to Reproduce

1. run Kodi: firejail --profile=/etc/firejail/kodi.profile kodi

2. go to Settings

3. run the file manager

4. try to browse all directories or delete files

Expected behavior

No ability to view or delete files outside the media folders defined in the profile.

Actual behavior

Possible to view and delete files outside the media folders defined in the profile.

Behavior without a profile

In terms of viewing and deleting files, the same as with a profile.

Environment

• Linux distribution: Arch Linux
• Firejail version: 0.9.68
• Kodi version: 19.4

[rusty-snake]

Second note that kodi.profile isn't whitelisting profile and does not set disable-mnt. So if you can access /mnt/foo/bar or ~/Downloads/frogs.png this is expected.

[tomasz-c]

@rusty-snake But I understand that if I have home mounted from a separate partition it doesn't matter? I can also view the contents of /etc and this should not work?

[rusty-snake]

But I understand that if I have home mounted from a separate partition it doesn't matter?

I don't understand what you mean.

I can also view the contents of /etc and this should not work?

Where is /etc restricted (via whitelisting) in kodi.profile? _{answer: nowhere}

[tomasz-c]

I don't understand what you mean.

Mounting /dev/sdXY to /home I don't know how disable-mnt works, but from what I found it should only block access to /mnt

Where is /etc restricted (via whitelisting) in kodi.profile? answer: nowhere

This is a bit unintuitive to me, as I always thought whitelists were for unlocking :)

I don't know firejail profile configuration well, I reported this bug because this behavior in my opinion is dangerous: allowing kodi to access everything as well as delete files. Because of the support for plugins that don't necessarily pass any security audits and can even be potentially malicious (I know of one such case). I know that in the past firejail with the default kodi profile didn't allow this, so if it does now I consider it a bug, but if this behavior is expected then somehow I will understand it and close the bug :)

[rusty-snake]

I don't know how disable-mnt works, but from what I found it should only block access to /mnt

Yes, disable-mnt is about /mnt (and /media, /run/media, /run/mnt).

[rusty-snake]

This is a bit unintuitive to me, as I always thought whitelists were for unlocking :)

blacklist/whitelist (or denylist/blocklist/allowlist) describe the concept:

• blacklist: Everything that has not explicitly forbidden is allowed.
• whitelist: Everything that has not explicitly allowed is forbidden.

[rusty-snake]

I don't know firejail profile configuration well, I reported this bug because this behavior in my opinion is dangerous: allowing kodi to access everything as well as delete files. Because of the support for plugins that don't necessarily pass any security audits and can even be potentially malicious (I know of one such case).

You're right that the kodi.profile is rather weak and we could/should harden it (for the reason you said and the general idea). However to much hardening will break plugins and custom locations for media files so people will come here and say that kodi.profile is to strict and breaks kodi. That's the general problem with distributed sandbox configurations, find the compromise between security (strict as possible) and usability (weak as necessary). I'm not sure if kodi.profile should be whitelisting by default but we should at least add a comment ("Add the following lines to your kodi.local for whitelisting").

I know that in the past firejail with the default kodi profile didn't allow this

I do not see any such commits. Maybe you did this in your kodi.local?

[tomasz-c]

You're right that the kodi.profile is rather weak and we could/should harden it (for the reason you said and the general idea). However to much hardening will break plugins and custom locations for media files so people will come here and say that kodi.profile is to strict and breaks kodi. That's the general problem with distributed sandbox configurations, find the compromise between security (strict as possible) and usability (weak as necessary). I'm not sure if kodi.profile should be whitelisting by default but we should at least add a comment ("Add the following lines to your kodi.local for whitelisting").

Hardening, even too much I think is a better solution than giving the appearance of protection. I would be more worried about the reactions of people who have had their data deleted :) I was convinced that the Kodi profile protects me as before and only by accident I noticed that it allows ... much.

I do not see any such commits. Maybe you did this in your kodi.local?

Unfortunately I don't have any individual configuration, but wouldn't it be possible to restore the behavior that used to be? That kodi had access only to default media directories?

If I may ask, can you suggest what in the kodi profile causes that:

noblacklist ${HOME}/.kodi
noblacklist ${MUSIC}
noblacklist ${PICTURES}
noblacklist ${VIDEOS}

it doesn't restrict access only to those directories?

[rusty-snake]

Talking about access to files in $HOME, you need this:

mkdir ${HOME}/.kodi
whitelist ${HOME}/.kodi
whitelist ${MUSIC}
whitelist ${PICTURES}
whitelist ${VIDEOS}
include whitelist-common.inc

But there's much more space for improvements in kodi.profile

[kmk3]

@tomasz-c commented on Jun 11:

You're right that the kodi.profile is rather weak and we could/should harden it (for the reason you said and the general idea). However to much hardening will break plugins and custom locations for media files so people will come here and say that kodi.profile is to strict and breaks kodi. That's the general problem with distributed sandbox configurations, find the compromise between security (strict as possible) and usability (weak as necessary). I'm not sure if kodi.profile should be whitelisting by default but we should at least add a comment ("Add the following lines to your kodi.local for whitelisting").

Hardening, even too much I think is a better solution than giving the appearance of protection. I would be more worried about the reactions of people who have had their data deleted :) I was convinced that the Kodi profile protects me as before and only by accident I noticed that it allows ... much.

Related: #4760.

[kmk3]

The reported issue seems to be that kodi can access paths in the user home other than its own paths and ~/Music, ~/Picures and ~/Videos.

In which case it seems to be intentional in order to avoid being too restrictive and potentially breaking plugins and different user setups.

So closing as wontfix.

If this is not accurate, feel free to comment.

If you have a specific bug or improvement, feel free to open a new issue.