Re: What are the correct permissions for lib binaries for amanda 3.5
amcheck check the 'r' all permission, but it is executed even if the permission are not correct. I removed the check for 'r' all . Jean-Louis On 17/10/17 03:18 AM, Jon LaBadie wrote: > On Tue, Oct 17, 2017 at 07:21:02AM +0200, Uwe Menges wrote: >> On 10/16/17 21:32, Austin S. Hemmelgarn wrote: >>> 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. >> What do these points have to do with the suid binary not being read- and >> executable by normal users on that system? >> >> I think one "why" explanation is that a local user probably can't >> exploit eventual issues in the suid binary if he can't execute it. >> > The question was why they are read protected. Read permission is not > needed for execution. If someone wanted to look at the binary, the > lack of read permissions on the installed copy won't prevent them from > getting their own copy from the install package. > > jl This message is the property of CARBONITE, INC. and may contain confidential or privileged information. If this message has been delivered to you by mistake, then do not copy or deliver this message to anyone. Instead, destroy it and notify me by reply e-mail
Re: What are the correct permissions for lib binaries for amanda 3.5
On Tue, Oct 17, 2017 at 07:21:02AM +0200, Uwe Menges wrote: > On 10/16/17 21:32, Austin S. Hemmelgarn wrote: > > 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. > > What do these points have to do with the suid binary not being read- and > executable by normal users on that system? > > I think one "why" explanation is that a local user probably can't > exploit eventual issues in the suid binary if he can't execute it. > The question was why they are read protected. Read permission is not needed for execution. If someone wanted to look at the binary, the lack of read permissions on the installed copy won't prevent them from getting their own copy from the install package. jl -- Jon H. LaBadie [email protected] 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: What are the correct permissions for lib binaries for amanda 3.5
On 10/16/17 21:32, Austin S. Hemmelgarn wrote: > 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. What do these points have to do with the suid binary not being read- and executable by normal users on that system? I think one "why" explanation is that a local user probably can't exploit eventual issues in the suid binary if he can't execute it. Yours, Uwe
Re: What are the correct permissions for lib binaries for amanda 3.5
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).
Re: What are the correct permissions for lib binaries for amanda 3.5
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 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? Does amcheck do any checks for amanda programs that are [sg]uid that should not be? Jon -- Jon H. LaBadie [email protected] 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: What are the correct permissions for lib binaries for amanda 3.5
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. It make sense when you build yourself, but not when doing a package where everyone can read the files in the package. 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? Jean-Louis > > Jon This message is the property of CARBONITE, INC. and may contain confidential or privileged information. If this message has been delivered to you by mistake, then do not copy or deliver this message to anyone. Instead, destroy it and notify me by reply e-mail
Re: What are the correct permissions for lib binaries for amanda 3.5
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? Jon -- Jon H. LaBadie [email protected] 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: What are the correct permissions for lib binaries for amanda 3.5
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. Jean-Louis This message is the property of CARBONITE, INC. and may contain confidential or privileged information. If this message has been delivered to you by mistake, then do not copy or deliver this message to anyone. Instead, destroy it and notify me by reply e-mail
Re: What are the correct permissions for lib binaries for amanda 3.5
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" ? > > > Jean-Louis > This message is the property of CARBONITE, INC. and may contain confidential > or privileged information. > If this message has been delivered to you by mistake, then do not copy or > deliver this message to anyone. Instead, destroy it and notify me by reply > e-mail Kind regards Jose M Calhariz -- -- Perguntar a um escritor o que acha dos criticos e como perguntar a um poste como ele se sente a respeito dos cachorros. -- John Osborne
Re: What are the correct permissions for lib binaries for amanda 3.5
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 Jean-Louis This message is the property of CARBONITE, INC. and may contain confidential or privileged information. If this message has been delivered to you by mistake, then do not copy or deliver this message to anyone. Instead, destroy it and notify me by reply e-mail
What are the correct permissions for lib binaries for amanda 3.5
I am trying to package amanda 3.5 for Debian. Where the user for backups is "backup" and during the packaging I have to manually set the correct permissions of the binaries, specially group owner and setuid bits. For example my VM for testing amanda have: backup@debian-at:~$ ls -alF /usr/lib/amanda/ total 892 drwxr-xr-x 4 root root4096 Oct 14 15:13 ./ drwxr-xr-x 36 root root4096 Oct 14 14:36 ../ -rwxr-xr-x 1 root root6683 Oct 13 17:23 amadmin_perl* -rwxr-xr-x 1 root root 39160 Oct 13 17:23 amandad* -rw-r--r-- 1 root root 935 Oct 13 17:23 amanda-sh-lib.sh -rwxr-xr-x 1 root root 40835 Oct 13 17:23 ambackupd* -rwsr-xr-- 1 root backup 10232 Oct 13 17:23 ambind* -rw-r--r-- 1 root root 135 Oct 13 17:23 amcat.awk -rwxr-xr-x 1 root root 11613 Oct 13 17:23 amcheck-device* -rwxr-xr-x 1 root root 10243 Oct 13 17:23 amdumpd* -rwxr-xr-x 1 root root3804 Oct 13 17:23 amidxtaped* -rwxr-xr-x 1 root root 47184 Oct 13 17:23 amindexd* -rwxr-xr-x 1 root root2448 Oct 13 17:23 amlogroll* -rwxr-xr-x 1 root root 48136 Oct 13 17:23 amndmjob* -rw-r--r-- 1 root root 20523 Oct 13 17:23 amplot.awk -rw-r--r-- 1 root root3400 Oct 13 17:23 amplot.g -rw-r--r-- 1 root root3410 Oct 13 17:23 amplot.gp -rwxr-xr-x 1 root root 26616 Oct 13 17:23 amtrmidx* -rwxr-xr-x 1 root root 14328 Oct 13 17:23 amtrmlog* drwxr-xr-x 2 root root4096 Oct 14 15:13 application/ -rwsr-xr-- 1 root backup 18424 Oct 13 17:23 calcsize* -rwxr-xr-x 1 root root2672 Oct 13 17:23 chunker* -rwxr-xr-x 1 root root 96336 Oct 13 17:23 driver* -rwxr-xr-x 1 root backup 63672 Oct 13 17:23 dumper* -rwsr-xr-- 1 root backup 10232 Oct 13 17:23 killpgrp* -rwxr-xr-x 1 root root 52232 Oct 13 17:23 ndmjob* -rwxr-xr-x 1 root root 10232 Oct 13 17:23 noop* -rwxr-xr-x 1 root root5024 Oct 13 17:23 patch-system* -rwxr-xr-x 1 root backup 67712 Oct 13 17:23 planner* -rwxr-xr-x 1 root root1556 Oct 13 17:23 restore* drwxr-xr-x 8 root root4096 Oct 14 15:13 rest-server/ -rwsr-xr-- 1 root backup 10232 Oct 13 17:23 rundump* -rwsr-xr-- 1 root backup 14328 Oct 13 17:23 runtar* -rwxr-xr-x 1 root root 43080 Oct 13 17:23 selfcheck* -rwxr-xr-x 1 root root 60840 Oct 13 17:23 sendbackup* -rwxr-xr-x 1 root root 18432 Oct 13 17:23 senddiscover* -rwxr-xr-x 1 root root 55736 Oct 13 17:23 sendsize* -rwxr-xr-x 1 root root2918 Oct 13 17:23 taper* -rwxr-xr-x 1 root root 10232 Oct 13 17:23 teecount* But I got this warning from amcheck: backup@debian-at:~$ amcheck DailySet1 '/etc/amanda/DailySet1/amanda.conf', line 71: warning: Keyword usetimestamps is deprecated. Amanda Tape Server Host Check - ERROR: program /usr/lib/amanda/ambind: wrong permission NOTE: Holding disk '/hdisk/DailySet1': 2478080 KB disk space available, using 2375680 KB '/etc/amanda/DailySet1/amanda.conf', line 71: warning: Keyword usetimestamps is deprecated. slot 2: volume 'DailySet1-02' Will write to volume 'DailySet1-02' in slot 2. NOTE: skipping tape-writable test Server check took 0.282 seconds Amanda Backup Client Hosts Check Client check: 1 host checked in 0.153 seconds. 0 problems found. (brought to you by Amanda 3.5) Is the permissions of the binaries in /usr/lib/amanda correct? Kind regards Jose M Calhariz -- -- O tempo e a imagem movel da eternidade imovel. -- Platao 428 ± 348 a.C.; filosofo grego.
