passt-mac issueshttps://gitlab.cs.fau.de/me61sewa/passt-mac/-/issues2018-05-20T20:45:50Zhttps://gitlab.cs.fau.de/me61sewa/passt-mac/-/issues/11argv-based rules2018-05-20T20:45:50ZLukas Braunargv-based rulesJust an idea: being able to say an application `x` can access the path in `argv[1]`.
That wouldn't cover all the cases, but the most common ones. Alternatives: the last argument or a configurable position.Just an idea: being able to say an application `x` can access the path in `argv[1]`.
That wouldn't cover all the cases, but the most common ones. Alternatives: the last argument or a configurable position.https://gitlab.cs.fau.de/me61sewa/passt-mac/-/issues/10Handle pipes in /dev/fd2018-05-20T20:45:50ZLukas BraunHandle pipes in /dev/fdPipes are represented in /dev/fd/x as weird symlinks with a non-existent target, which breaks `d_absolute_path` (returns `-EINVAL`).
To reproduce, run `cat <(echo foo)` in bash. It fails with something like "bash: /dev/fd/62: Invalid ...Pipes are represented in /dev/fd/x as weird symlinks with a non-existent target, which breaks `d_absolute_path` (returns `-EINVAL`).
To reproduce, run `cat <(echo foo)` in bash. It fails with something like "bash: /dev/fd/62: Invalid argument".
There has to be a way to figure out that this isn't actually a symlink but a reference to a pipe. The best fix is then probably to check for this in `d_absolute_path`.
Does AppArmor handle this?https://gitlab.cs.fau.de/me61sewa/passt-mac/-/issues/9chroots, namespaces, etc. not handled2018-05-20T20:45:50ZSimon Ruderichchroots, namespaces, etc. not handledchroots/namespaces should be ignored. Check the current behavior.chroots/namespaces should be ignored. Check the current behavior.https://gitlab.cs.fau.de/me61sewa/passt-mac/-/issues/8Symlinks are always followed2018-05-20T20:45:50ZSimon RuderichSymlinks are always followedWhen adding a rule for e.g. `/bin/sh` (which is a symlink to `/bin/dash` on Debian systems) then this rule will never match as the symlink is followed resulting in `/bin/dash` as path to the binary. It would be nice if both, `/bin/sh` an...When adding a rule for e.g. `/bin/sh` (which is a symlink to `/bin/dash` on Debian systems) then this rule will never match as the symlink is followed resulting in `/bin/dash` as path to the binary. It would be nice if both, `/bin/sh` and its target, could be considered.https://gitlab.cs.fau.de/me61sewa/passt-mac/-/issues/7Mitigate ptrace, LD_PRELOAD etc.2018-05-20T20:45:50ZLukas BraunMitigate ptrace, LD_PRELOAD etc.For ptrace there is a hook, for stuff like LD_PRELOAD there is the AT_SECURE flag. The question is when to apply these, e.g.:
* if explicitely enabled (i.e. flag in the rules)
* if a process is in `inherit` modeFor ptrace there is a hook, for stuff like LD_PRELOAD there is the AT_SECURE flag. The question is when to apply these, e.g.:
* if explicitely enabled (i.e. flag in the rules)
* if a process is in `inherit` modehttps://gitlab.cs.fau.de/me61sewa/passt-mac/-/issues/5Fix reading from the rules file2018-05-20T20:45:50ZLukas BraunFix reading from the rules fileCurrent `slsm_dump_tree` is broken.
A feasible implementation: `slsm_dump_tree` is called on `open` and serialises the entire ruleset, allocating as much space as it needs. `read` then writes out that buffer, `close` frees it.
Note...Current `slsm_dump_tree` is broken.
A feasible implementation: `slsm_dump_tree` is called on `open` and serialises the entire ruleset, allocating as much space as it needs. `read` then writes out that buffer, `close` frees it.
Note that with the these changes and those describe described in #2, `slsm_dump_tree` would have to grab the lock, since allocating might sleep (I think).