On 2017-10-16 14:58, Jon LaBadie wrote:
On Mon, Oct 16, 2017 at 02:05:05PM -0400, Jean-Louis Martineau wrote:
On 16/10/17 01:48 PM, Jon LaBadie wrote:
On Mon, Oct 16, 2017 at 08:12:43AM -0400, Jean-Louis Martineau wrote:
On 14/10/17 12:12 PM, Jose M Calhariz wrote:
On Sat, Oct 14, 2017 at 11:36:09AM -0400, Jean-Louis Martineau wrote:
On 14/10/17 11:14 AM, Jose M Calhariz wrote:
-rwsr-xr-- 1 root backup 10232 Oct 13 17:23 ambind
ambind must not be readable by all
-rwsr-x--- 1 root backup 10232 Oct 13 17:23 ambind
Thank you for the quick reply. May I ask why "ambind must not be
readable by all" ?
All suid program in amanda are always installed like this.
Why are all amanda suid programs installed this way?
It's before I was born, maybe not, but before I started to work on the
amanda software.
It's kind of security by hiding, it's harder to find a vulnerability in
the suid binary if you can't read it.
I guessed it was security by obscurity.
It is, but it's common practice security by obscurity dating back almost
to SVR4.
It make sense when you build yourself, but not when doing a package
where everyone can read the files in the package.
For the same reason I felt that would be "false" security.
The group probably do not read the 'r' bit either.
Do you think amcheck should not check if the suid binary are readable by
all?
My gut reaction is such a check is superfluous. But I'm not a
security expert. Do we have any security specialist (or others)
on the list who would care to comment?
I won't claim to be a security expert, but I've been a sysadmin for more
than a decade and can tell you two things based on my experience own
experience:
1. Amanda is the only software I've ever encountered that does this kind
of check, or more accurately, it's the only software I've ever
encountered where this type of check is a fatal error. Some other
software will ignore files if their ownership is wrong, but it's treated
as a warning, and it's only configuration files (stuff like
~/.ssh/authorized_keys for example).
2. The checks are a serious pain in the arse, mostly because error
messages are so vague (OK, so file XYZ has the wrong permissions, does
that mean the directory it's in has the wrong permissions, or the file
itself, and which permissions are wrong?). This particular check isn't
as bad in that respect as, for example, the ones checking
/etc/amanda-security.conf, but it's still a pain to deal with.
Aside from that though, it's a case where the benefit to security is
dependent on things that just aren't true for most systems amanda is
likely to run on, namely that an attacker is:
1. Unable to determine what type of system you're running on. (This is a
patently false assumption on any publicly available distro, as well as
most paid ones like OEL, RHEL, and SLES).
&
2. Unable to access the packages directly.
In most cases, both are false. There are a few odd cases like
source-based distros (Gentoo for example) where the package gets built
locally, but even then the builds are pretty reproducible, and the code
for Amanda itself is trivially available for review through other sources.
In a way, it's kind of like making the contents of /boot inaccessible to
regular users, but not preventing `uname -v` and `uname -r` from being
executed by them. It makes things a bit more complicated for attackers,
but in a rather trivial way that doesn't provide anything but a false
sense of security.
Does amcheck do any checks for amanda programs that are [sg]uid
that should not be?
I'm not sure, though it does check ownership on many files, and I think
it checks that things that are supposed to be suid or sgid are (I'm
pretty sure it complains if amgtar or amstar aren't suid root).
