Re: [SOLVED] Re: [gentoo-user] msmtp vs. nullmailer
Am Mon, 20 Jul 2015 10:23:30 -0400 schrieb Walter Dnes waltd...@waltdnes.org: On Mon, Jul 20, 2015 at 01:21:56PM +0200, Marc Joliet wrote This choice came about because I switched from fcron to systemd-cron, which runs its mail_on_failure script as user nobody, which caused my current passwordeval command (cat somefile, somefile having a mode mask of 0600) That is the wrong, wrong, wrong way to do it. I know, it somewhat defeats the purpose. In my defense, it was supposed to be temporary so that I could get msmtp working quickly until I was sure that I wanted to keep it. to fail due to insufficient access rights. I really didn't want to deal with how to properly solve that, and I don't think it's possible (at least not with msmtp). I mean, the problem statement is basically How do I securely give every user access to the password?. Once stated that way, I think the difficulty with the problem becomes fairly obvious. The correct question is how do I allow user 'nobody' to execute a one-off command as another user. My thought was admittedly somewhat academic: I didn't want to assume that only root and nobody wanted to send emails. However, I notice that the only software I have installed that needs to be able to send email is (insofar that there aren't any packages missing a dependency on virtual/mta or virtual/mailx): - portage (though only if you configure it appropriately) - smartd (via the mail program instead of sendmail) - *cron - sudo (though I don't know under what circumstances and as what user, though I expect it to send emails as root) All run as root except for *cron, which in the case of systemd-cron sends mails as nobody (I don't remember how fcron or any of the other implementations do it). So from a practical point of view, you are right that the problem was limited to dealing with user nobody. Though who knows what will happen after an upgrade or package migration? Despite being a Gentoo user, I'm not interested in micromanaging *every* aspect of my system (only the fun parts). The solution is sudoers. Emerge sudo and set up a file in /etc/sudoers.d. I use /etc/sudoers.d/001 because I'm not creative with filenames. Here is an example entry... waltdnes d531 = (root) NOPASSWD: /usr/sbin/hibernate The explanation... waltdnes(the user being allowed to run the command) d531(the machine name in /etc/hosts) (root) (the user privilege to run as) NOPASSWD: (password is not required; no ugly cat somefile hack) /usr/sbin/hibernate (the command to run) As regular user waltdnes, I execute the command... sudo /usr/sbin/hibernate ...and I get the system to hibernate, which normally requires root level privileges. I'm lazy, so I set up a script ~/bin/hb that runs the above command. I only have to execute hb to hibernate. This approach is very granular, because it can be set up to allow one user to execute one specifc command. If you wish, you can use wildcards, and the special ALL word to open up privileges more widely. I actually know about this and have a wildcard rule for cpupower. I agree with Mick's point, though, which partially ties into *my* point: I want to limit access to the password (file) to as few users as possible, and nobody is used as a catch-all, so I wouldn't fully know *what* exactly I'm giving access to my email account password. I just didn't see any sane way to handle this with msmtp, which to me seems more and more like it's primarily designed for use by regular users as opposed to system services (various hints point to this, such as that the system-wide example [0] only defines a default account without a password, or the Gentoo package description I mentioned before). Anyway, I'm happy with nullmailer right now. [0] http://msmtp.sourceforge.net/doc/msmtp.html#A-system-wide-configuration-file -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup pgpzbIzcAP8FR.pgp Description: Digitale Signatur von OpenPGP
[SOLVED] Re: [gentoo-user] msmtp vs. nullmailer
OK, I finally solved this, albeit a bit differently... by switching to nullmailer. The TL/DR summary is: use the right tool for the job. Some more details follow below. Nullmailer was very easy to set up (the deceptively short HOWTO is pretty much all that is needed). The only problem is that there is no way to rewrite the envelope sender, which is required by my email provider. I solved that... creatively. *However* the master branch contains a change that introduces the allmailfrom control file [0], so once version 1.14 is out I can remove the hack. This choice came about because I switched from fcron to systemd-cron, which runs its mail_on_failure script as user nobody, which caused my current passwordeval command (cat somefile, somefile having a mode mask of 0600) to fail due to insufficient access rights. I really didn't want to deal with how to properly solve that, and I don't think it's possible (at least not with msmtp). I mean, the problem statement is basically How do I securely give every user access to the password?. Once stated that way, I think the difficulty with the problem becomes fairly obvious. With nullmailer the remotes file is 0640, with group nullmailer, so only root or nullmailer can access it. It's also simple enough that I simply didn't add it to git. So the password is in plain text, but access is strictly limited. But really, I *should* have been tipped off by the package description: An SMTP client and SMTP plugin for mail user agents such as Mutt. The above problem simply doesn't exist when running msmtp as a normal user (in which case you probably don't even have an /etc/msmtprc). [0] https://github.com/bruceg/nullmailer/commit/da55b71b6136bcefc7aa784a7f9fd45987670a7a -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup pgpEvOZMu7xHY.pgp Description: Digitale Signatur von OpenPGP
Re: [SOLVED] Re: [gentoo-user] msmtp vs. nullmailer
On Mon, Jul 20, 2015 at 01:21:56PM +0200, Marc Joliet wrote This choice came about because I switched from fcron to systemd-cron, which runs its mail_on_failure script as user nobody, which caused my current passwordeval command (cat somefile, somefile having a mode mask of 0600) That is the wrong, wrong, wrong way to do it. to fail due to insufficient access rights. I really didn't want to deal with how to properly solve that, and I don't think it's possible (at least not with msmtp). I mean, the problem statement is basically How do I securely give every user access to the password?. Once stated that way, I think the difficulty with the problem becomes fairly obvious. The correct question is how do I allow user 'nobody' to execute a one-off command as another user. The solution is sudoers. Emerge sudo and set up a file in /etc/sudoers.d. I use /etc/sudoers.d/001 because I'm not creative with filenames. Here is an example entry... waltdnes d531 = (root) NOPASSWD: /usr/sbin/hibernate The explanation... waltdnes(the user being allowed to run the command) d531(the machine name in /etc/hosts) (root) (the user privilege to run as) NOPASSWD: (password is not required; no ugly cat somefile hack) /usr/sbin/hibernate (the command to run) As regular user waltdnes, I execute the command... sudo /usr/sbin/hibernate ...and I get the system to hibernate, which normally requires root level privileges. I'm lazy, so I set up a script ~/bin/hb that runs the above command. I only have to execute hb to hibernate. This approach is very granular, because it can be set up to allow one user to execute one specifc command. If you wish, you can use wildcards, and the special ALL word to open up privileges more widely. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [SOLVED] Re: [gentoo-user] msmtp vs. nullmailer
On Monday 20 Jul 2015 15:23:30 Walter Dnes wrote: On Mon, Jul 20, 2015 at 01:21:56PM +0200, Marc Joliet wrote This choice came about because I switched from fcron to systemd-cron, which runs its mail_on_failure script as user nobody, which caused my current passwordeval command (cat somefile, somefile having a mode mask of 0600) That is the wrong, wrong, wrong way to do it. to fail due to insufficient access rights. I really didn't want to deal with how to properly solve that, and I don't think it's possible (at least not with msmtp). I mean, the problem statement is basically How do I securely give every user access to the password?. Once stated that way, I think the difficulty with the problem becomes fairly obvious. The correct question is how do I allow user 'nobody' to execute a one-off command as another user. The solution is sudoers. Emerge sudo and set up a file in /etc/sudoers.d. I use /etc/sudoers.d/001 because I'm not creative with filenames. Here is an example entry... waltdnes d531 = (root) NOPASSWD: /usr/sbin/hibernate The explanation... waltdnes(the user being allowed to run the command) d531(the machine name in /etc/hosts) (root) (the user privilege to run as) NOPASSWD: (password is not required; no ugly cat somefile hack) /usr/sbin/hibernate (the command to run) As regular user waltdnes, I execute the command... sudo /usr/sbin/hibernate ...and I get the system to hibernate, which normally requires root level privileges. I'm lazy, so I set up a script ~/bin/hb that runs the above command. I only have to execute hb to hibernate. This approach is very granular, because it can be set up to allow one user to execute one specifc command. If you wish, you can use wildcards, and the special ALL word to open up privileges more widely. This is all good and dandy, but letting user nobody read your mail accoutn passwd may not be the safest approach to sending email messages from your machine. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [SOLVED] Re: [gentoo-user] msmtp vs. nullmailer
On Mon, Jul 20, 2015 at 06:49:00PM +0100, Mick wrote This is all good and dandy, but letting user nobody read your mail accoutn passwd may not be the safest approach to sending email messages from your machine. I think you missed the point. The NOPASSWD: option means that this one particular user nobody ***DOES NOT NEED THE ROOT PASSWORD*** to execute this one particular command which normally requires root level privileges. I repeat, it has no need for the password. This is done with a sudoers entry like the following example. michael michaelsmachine = (root) NOPASSWD: /usr/sbin/nullmailer The only problem might be convincing your program that the mail command is... sudo /usr/sbin/nullmailer You can tell it to run a script that contains that command. Having passwords floating around on disk in clear text is a *BAD* idea. Some user friendly distros, like Ubuntu, let you run *ANY* command as root if you prefix it with sudo. That can be done with the keyword ALL michael michaelsmachine = (root) NOPASSWD: ALL I do not like it on general principle. It gives away the store as far as security is concerned. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [SOLVED] Re: [gentoo-user] msmtp vs. nullmailer
On 21/07/2015 00:24, Mick wrote: On Monday 20 Jul 2015 22:50:31 Walter Dnes wrote: On Mon, Jul 20, 2015 at 06:49:00PM +0100, Mick wrote This is all good and dandy, but letting user nobody read your mail accoutn passwd may not be the safest approach to sending email messages from your machine. I think you missed the point. The NOPASSWD: option means that this one particular user nobody ***DOES NOT NEED THE ROOT PASSWORD*** to execute this one particular command which normally requires root level privileges. I repeat, it has no need for the password. I have not missed the point you are raising. My concern was that nobody is a user account without a login shell, to which you give access to a user file that has a login shell and in particular to a file that contains the email account passwd of that user. Given that public servers and daemons often run as nobody:nogroup I would be cautious about this. I do not have an exact script in mind which could potentially cause privilege escalation, but someone more skilled that I in the dark arts could well do. The main danger in that scenario (there are several) is that the shell script can be suspended (Ctrl-Z) or offer a means to escape to a shell. Do that, be root. A good rule of thumb is to only put compiled programs into sudoers, never scripts or wrappers. It is very very hard to write a script that disables all those nasty features that made scripts so useful and friendly -- Alan McKinnon alan.mckin...@gmail.com
Re: [SOLVED] Re: [gentoo-user] msmtp vs. nullmailer
On Monday 20 Jul 2015 22:50:31 Walter Dnes wrote: On Mon, Jul 20, 2015 at 06:49:00PM +0100, Mick wrote This is all good and dandy, but letting user nobody read your mail accoutn passwd may not be the safest approach to sending email messages from your machine. I think you missed the point. The NOPASSWD: option means that this one particular user nobody ***DOES NOT NEED THE ROOT PASSWORD*** to execute this one particular command which normally requires root level privileges. I repeat, it has no need for the password. I have not missed the point you are raising. My concern was that nobody is a user account without a login shell, to which you give access to a user file that has a login shell and in particular to a file that contains the email account passwd of that user. Given that public servers and daemons often run as nobody:nogroup I would be cautious about this. I do not have an exact script in mind which could potentially cause privilege escalation, but someone more skilled that I in the dark arts could well do. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [SOLVED] Re: [gentoo-user] msmtp vs. nullmailer
On 20/07/2015 23:50, Walter Dnes wrote: On Mon, Jul 20, 2015 at 06:49:00PM +0100, Mick wrote [snip] You can tell it to run a script that contains that command. Having passwords floating around on disk in clear text is a *BAD* idea. Some user friendly distros, like Ubuntu, let you run *ANY* command as root if you prefix it with sudo. That can be done with the keyword ALL michael michaelsmachine = (root) NOPASSWD: ALL [snip] Lets be fair to Ubuntu - the above is not how it ships. On Ubuntu, all users in the admin group can run any command with sudo, and sudoers ships with a cpnfig that *requires* the user's password. This is a very normal config and an excellent starting point. The first user added during the install is added to the admin group (as obviously it is root doing the installation), all other users must be added to the group by root manually. What you describe is most certainly not how Ubuntu ships (but idiots who will do it, or follow howtos that say to do it, do exist) -- Alan McKinnon alan.mckin...@gmail.com
