Re: file(1) now with seccomp support enabled
On 2019-07-27 04:55, Christoph Biedl wrote: Eventually fakeroot-tcp, wishes to open sockets, something I certainly would not want to whitelist. In AppArmor case, "non-standard" use cases can be dealt with by editing `/etc/apparmor.d/local/usr.bin.foo`, adding any necessary rules (like allowing to mmap() some specific LD_PRELOAD library if needed for that use case), or by disabling profile completely as worst case workaround. TTBOMK apparmor would not provide a sane solution for that problem. There still might be another use case: The file program should[citation needed] not write to any file. Reading however must be possible for every item in the entire file system. That's how I imagine AA profile for `file` - reads absolutely everything, and not expecting to write, unless to some temp file or similar. But as you said, citation needed.
Re: file(1) now with seccomp support enabled
On 2019-07-26 18:59, Christoph Biedl wrote: tl;dr: The file program in unstable is now built with seccomp support enabled, expect breakage in some rather uncommon use cases. Interesting, what are these uncommon use cases? Maybe we could confine it with AppArmor instead, since we have it enabled by default?
Re: Debian packaging, dependency management and the C++ standards meeting
On 2018-10-03 22:43, Jussi Pakkanen wrote: Well, there are about three meetings per year, and I doubt the next meeting will be some soft of "definitive" (or will it?) It is the last meeting where things can be added to C++20 so I would call that definitive. The tooling group that will try to tackle packaging & similar issues have just barely stared, I doubt something will be prepared for C++20 that would be of concern to this topic. Again, not sure if there's need to "panic", though of course your initiative is really important!
Re: Debian packaging, dependency management and the C++ standards meeting
On 10/3/18 7:56 PM, Jussi Pakkanen wrote: An alternative, or parallel, approach could be to write a paper outlining the issues and submitting it to the standard body. It seems that papers are The communication channel for C++ ISO, it might be useful to write paper, receive feedback, and improve upon, and *additionally* present it in one of C++ conferences for more influence. This does require someone to be physically at the meeting and to present the paper and its conclusions to the participants and be ready to answer questions. Not necessarily, it is possible to have patron that will agree to present it on behalf of authors. Initial feedback and possibly patrons (I believe some other word is used to describe them) can be found in ISO C++ forums [0]. The downside is that the deadline for submitting papers is fairly short, I think something like 1.5 weeks so this would need to move fairly quickly. Well, there are about three meetings per year, and I doubt the next meeting will be some soft of "definitive" (or will it?), so paper could be reviewed in subsequent meetings. [0] https://isocpp.org/std/forums
What packages are "responsible" for /tmp/xauth-1000* ?
Hi Debian Developers,
While debugging some AppArmor-related stuff I've discovered that some application uses
`/tmp/xauth-1000-_0` files instead of `~/.Xauthority`, and started discussion on upstream AppArmor
mailing list [0] on how to deal with such cases.
Simon McVittie enlightened me [1] (thanks!) that having different Xauthority paths can be influenced
by desktop managers, remote desktop access applications, and else.
Now, knowing that there can be different paths depending on "parent" application that influences
interaction with X, instead of patching AppArmors so-called "X" abstraction (basically an include
file [2]) for every use case we know or don't know yet, we could deal with Xauthority alternatives
by utilizing AppArmor variables.
To achieve that, I would need to find packages that "decide", affect Xauthority path. Then, I would
discuss with it's maintainers about possibility to ship single file with additions to the the
upstream AppArmor variable, adding single line with "new", additional path[s] to the Xauthority file
like this:
(example for package "foo")
cat /etc/apparmor.d/tunables/env.d/foo
@{XAUTHORITY} += /run/user/[0-9]*/foo/xauth-*
This will make dealing with changing paths (not only XAUTHORITY; for TMPDIR and else too!) with
AppArmor easier, less upstream-dependent, and in more load-balanced way by putting less burden on
limited AppArmor team. I believe making AppArmor more configurable, flexible is really important as
we are targeting to enable it (or should I say "keep enabled" as it is enabled now for the
experiment) by default.
So the main question is, how do I start? How do I find as much packages as possible to start
discussions with their maintainers about shipping additional file, to make us of this env.d idea?
Maybe Debian Developers reading this knows ( or even are responsible for ) already quite a few
packages that in fact that uses "unusual" Xauthority paths?
Big thanks!
P.S. CC to intrigeri, our AppArmor maintainer, for relevance and possibly help.
[0] https://lists.ubuntu.com/archives/apparmor/2018-July/011714.html
[1] https://lists.ubuntu.com/archives/apparmor/2018-July/011727.html
[2]
https://salsa.debian.org/apparmor-team/apparmor/blob/69be44e5ef31905eb27be0c04c1346061b0cbc78/profiles/apparmor.d/abstractions/X#L20
Re: recommends for apparmor in newest linux-image-4.13
On 2017-12-06 12:24, Laurent Bigonville wrote: I feel that having Apparmor running and not doing anything will give people a false sense of security, on my test machine almost nothing was confined Yeah, we really need much more working profiles ready to be shipped... Thoguh I believe our AppArmor maintainer stated opinion that we should fix what's already available, instead of rushing to write bunch of new profiles (please correct me if I mistaken, intrigeri :-) ). As a hint, try running "sudo aa-enforce /etc/apparmor.d/*", it might enable some disabled-by-defaut profiles, as Thunderbird and Libreoffice ones. TBH I'm a bit disappointed with upstream state of Apparmor (no D-Bus mediation,...) and other missing features that are still ubuntu only. Yes I miss features too (not only mediation...). Though Signal and Mount mediation is available in 4.14 (not enabled in Debian AppArmor configuration _yet_, until it's tested enough), Network might come in 4.16.
Re: recommends for apparmor in newest linux-image-4.13
On 2017-11-29 09:25, Jonathan Dowland wrote: On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote: My personal pet "I don't have time" project I'd love to see is extending systemd units for as many services in Debian as possible to include namespace restrictions and seccomp filter rules, which I think has good parallel potential alongside an LSM for raising the default security posture of Debian. LSMs deal with per-file restrictions much more easily than systemd's seccomp and namespace support, but the seccomp and namespace support does a lot of other nice things that LSMs aren't as good at. Yes this would be excellent; a necessary prerequisite would be getting more daemons (and cron-scheduled processes) shipping systemd units too. Since mentioned, I would like that these daemons would implement seccomp filtering themselves, meaning like within application itself, using libeseccomp. Thy can fine-grain what thread what syscalls can make. For example, some networking, parsing thread might not need execve() at all. Meanwhile, it might be needed for main or other thread to call some external application, but that can be later mediated with MAC, is it AppArmor, SELinux or whatever.
