To Phillip,
AppArmor mediates networking (albeit in a coarse-grained fashion). For
an application that doesn't require network access, there is no issue
with profiling, because the profile for the application wouldn't allow
network access, so any attempt to use bash' network redirection would be
blocked. The problem is that every profiled application that uses
networking in any way (eg, the nameservice abstraction) will have
network access. This means that if we had something like this before:
/usr/bin/foo {
#include <abstractions/nameservice>
/bin/bash ixr,
/usr/bin/wget ix, # called via bash
...
}
We now have to have:
/usr/bin/foo {
#include <abstractions/nameservice> # allows networking
/bin/bash Cx -> bash,
...
bash {
... (no networking here)
/usr/bin/wget Cx -> wget,
...
wget {
#include <abstractions/nameservice> # allows networking again
...
}
}
}
All of those '...'s theoretically are duplicated rules across the
various parent, child and grandchild profiles. While possible, removing
network access from bash in this manner makes the profile very difficult
to create, audit and maintain. The same should be true of any LSM, not
just AppArmor.
Regarding other shells, dash does not suffer from the network
redirection feature. I don't know about other shells, but my
understanding is this is a bashism.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/712662
Title:
network redirection has been enabled
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
