You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currrently there are multiple options: blacklist, noblacklist, whitelist, read-only, read-write, private*, etc.
But it is completely unclear how firejail uses them.
We need a high-level description of the algo. Let we have for each virtual path that can be interacted from the sandbox the following attrs, describing firejail behavior for that path:
visible - If it is 1, an app in sandbox sees the path in directory listing, if it is present in fs outside of sandbox. If it is 0, the app doesn't see the file.
read-allowed - the app can read the virtual file having this virtual path. It means there is no permission error and virtual fs attrs look as needed. Semantics is defined by other attrs.
write-allowed - the app can write the virtual file having this virtual path. It means there is no permission error and virtual fs attrs look as needed. Semantics is defined by other attrs.
execute-allowed - the app can execute the virtual file having this virtual path. It means there is no permission error and virtual fs attrs look as needed.
write-passthrough - the path of the file in the real fs. When a virtual file is written with some content, this file in real fs is written. Can be null, this means that the real file is not written, but an ephemerial one is created.
read-passthrough - the path of the file in the real fs. When a virtual file is read, this file in real fs is read and its content is returned. For non-existent or non-visible paths assummed to be equal to their write-passthrough.
So in this model we should define:
1 the function generating default attrs of each virtual path
2 how each config param affects virtual path attrs
The text was updated successfully, but these errors were encountered:
KOLANICH
changed the title
Document the algorithm used to compute sets of read-allowed and write-allowed files and dirs
Document the algorithm used to determine firejail behavior for virtual paths
Nov 13, 2019
Currrently there are multiple options:
blacklist
,noblacklist
,whitelist
,read-only
,read-write
,private*
, etc.But it is completely unclear how firejail uses them.
We need a high-level description of the algo. Let we have for each virtual path that can be interacted from the sandbox the following attrs, describing firejail behavior for that path:
visible
- If it is 1, an app in sandbox sees the path in directory listing, if it is present in fs outside of sandbox. If it is 0, the app doesn't see the file.read-allowed
- the app can read the virtual file having this virtual path. It means there is no permission error and virtual fs attrs look as needed. Semantics is defined by other attrs.write-allowed
- the app can write the virtual file having this virtual path. It means there is no permission error and virtual fs attrs look as needed. Semantics is defined by other attrs.execute-allowed
- the app can execute the virtual file having this virtual path. It means there is no permission error and virtual fs attrs look as needed.write-passthrough
- the path of the file in the real fs. When a virtual file is written with some content, this file in real fs is written. Can benull
, this means that the real file is not written, but an ephemerial one is created.read-passthrough
- the path of the file in the real fs. When a virtual file is read, this file in real fs is read and its content is returned. For non-existent or non-visible
paths assummed to be equal to theirwrite-passthrough
.So in this model we should define:
1 the function generating default attrs of each virtual path
2 how each config param affects virtual path attrs
The text was updated successfully, but these errors were encountered: