Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#57787 - [ssmtp] world-readable config file with email credentials

Attached to Project: Community Packages
Opened by bobpaul (bobpaul) - Sunday, 11 March 2018, 02:26 GMT
Last edited by David Runge (dvzrv) - Friday, 16 March 2018, 22:02 GMT
Task Type Bug Report
Category Security
Status Closed
Assigned To David Runge (dvzrv)
Levente Polyak (anthraxx)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Upstream has a bug (#661954) from 2012 to secure the /etc/ssmtp/ssmtp.conf file. The arch wiki instructs users to add their own ssmtp group to own the binary and conf file and to place a hook script in libalpm. Ubuntu has fixed it using the system's existing mail group.

Attached is an updated PKGBUILD and a new .install script to implement the solution Ubuntu chose, rather than creating a package specific group.

This is a minimal change from upstream, where the package appears to be abandoned, and I don't think users should need to read the wiki to secure official packages.
(application/x-gzip)    ssmtp-2.64-10.src.tar.gz (1.7 KiB)
This task depends upon

Closed by  David Runge (dvzrv)
Friday, 16 March 2018, 22:02 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in 2.64-12
Comment by Eli Schwartz (eschwartz) - Sunday, 11 March 2018, 03:50 GMT
  • Field changed: Summary ([ssmtp] PLEASE ENTER SUMMARY → [ssmtp] world-readable config file with email credentials)
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Category (Packages → Security)
  • Field changed: Severity (Low → High)
  • Task assigned to Levente Polyak (anthraxx), David Runge (dvzrv)
That install script is completely unnecessary BTW, as it only does the exact same thing you've already done in package()

Comment by bobpaul (bobpaul) - Sunday, 11 March 2018, 03:59 GMT
The PKGBUILD sets permissions. The install script changes the group from 'root' to 'mail' so that the ssmtp binary executes as the 'mail' user rather than as root.

I couldn't figure out a way to change the group without the install script.
Comment by Eli Schwartz (eschwartz) - Sunday, 11 March 2018, 04:12 GMT
Oh, true enough, my bad. But still you should run the same chgrp/chmod in the package() function, makepkg supports both the setgid bit and non-root ownership in the package archive. ;)

Also setgid in package() while it is still using the root group is a race condition that adds its own security issues... what happens if the install script is interrupted, or if someone uses that binary after the files are extracted but before the install script runs.
Comment by loqs (loqs) - Sunday, 11 March 2018, 04:48 GMT
There is a bug on new installs with systemd 237 mail is created mail:x:12:12:mail:/var/spool/mail:/bin/false not mail:x:8:12:mail:/var/spool/mail:/bin/false
 FS#57693 
Comment by bobpaul (bobpaul) - Sunday, 11 March 2018, 04:52 GMT
Hmmm, yes... I'm not sure why I didn't think that worked. Here it is done only via package().
(application/x-gzip)    ssmtp-2.64-10.src.tar.gz (1.6 KiB)
Comment by Eli Schwartz (eschwartz) - Sunday, 11 March 2018, 07:00 GMT
Also a general packaging tip? "${pkgdir}" needs to be quoted, there is no guarantee the pathname the PKGBUILD is located in does not have a space or something in it.
Comment by David Runge (dvzrv) - Sunday, 11 March 2018, 12:35 GMT
@bobpaul: First of all: Thanks!

I'll get to updating this package shortly!
Comment by David Runge (dvzrv) - Sunday, 11 March 2018, 14:24 GMT
For reference, this is a link to the upstream bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661954
I've applied fixes to the package. If anything doesn't work as expected, reopen this task or open a new one.
Comment by bobpaul (bobpaul) - Monday, 12 March 2018, 15:56 GMT
Oh shoot. I'm the worst. The patch I gave you doesn't have execute permission on the directory '/etc/ssmtp/'. Truthfully, protecting the whole directory isn't really necessary, so just chmod the conf file I suppose.

And Eli pointed out I needed more quotes. Change the last lines of package() to:

----
chgrp mail "${pkgdir}/etc/ssmtp/ssmtp.conf" "${pkgdir}/usr/bin/ssmtp"
chmod 640 "${pkgdir}/etc/ssmtp/ssmtp.conf"
chmod 2755 "${pkgdir}/usr/bin/ssmtp"
Comment by David Runge (dvzrv) - Monday, 12 March 2018, 16:52 GMT
@bobpaul: That's right. Sorry for the mess... :>

How about /etc/ssmtp/revaliases though? I think it should also be 640, or is this file changed by using newaliases in some way?
I have to update the .install file as well.
Comment by bobpaul (bobpaul) - Monday, 12 March 2018, 18:54 GMT
I could be convinced either way on revaliases. It doesn't have any passwords, but there's definitely an argument to protect it. newaliases doesn't edited it... or do much of anything according to its manpage =D

It looks like Ubuntu protects the whole directory. (On older versions they only protected ssmtp.conf). Here's after freshly installing on Ubuntu 16.04.04:
/etc/ssmtp# ls -lah
total 24K
drwxr-x--- 2 root mail 4.0K Mar 12 12:53 .
drwxr-xr-x 126 root root 12K Mar 12 12:53 ..
-rw-r----- 1 root mail 200 Apr 13 2016 revaliases
-rw-r----- 1 root mail 597 Mar 12 12:53 ssmtp.conf

BTW, /usr/bin/{sendmail,newaliases,mailq} are all symlinks to ssmtp, so their permission don't matter. But setting them like you are doesn't hurt anything.
Comment by David Runge (dvzrv) - Tuesday, 13 March 2018, 14:16 GMT
@bobpaul: Does 2.64-12 solve this for you?
Comment by bobpaul (bobpaul) - Tuesday, 13 March 2018, 14:45 GMT
Yes it does! Thanks

Loading...