Re^3: creating a secure environment for perl scripts to run

Picking a few of your followups ..

I think to remember someone with greater experience writing that it's best not to ssh as root. (Is that a thing?)

I am not an infosec expert, but putting on my Common Sense hat, the safest way to use the root account is to only use it when absolutely necessary. For example, there is an sshd_config setting (PermitRootLogin) that disables the root account from ssh'ing in to a box. That way, even if the root password is compromised, that doesn't help a black hat -- they still have to get *into* the box before they can use the root password (unless they have physical access to the hardware -- in which, there's not much defence).

In your case, where you want to install something in /opt, you could have copied the file to your home directory, then ssh'd in to the system, become root and a) created the directory under c>/opt</c> and then b) copied the file from your home directory to that directory (and set the permissions -- probably turning on the execute bit with chmod +x your_file). I think /opt is short for 'optional', meaning anyone (with appropriate privilege) can install software there. Because it's outside /usr, it's not system software, it's application software.

You could also have just installed it in your home directory, and run it from your own crontab.

4. I would like (to send) an e-mail out of this. Is there some preferred way to do that?

I don't know about *preferred* way, but here's how I do it in one of my scripts ..

use Email::Simple::Markdown;
use Email::Sender::Simple qw(sendmail);
use Email::Sender::Transport::SMTP qw();
use Try::Tiny;
...
        my $message = Email::Simple::Markdown->create(
          header => [
            Subject => "Report for $client->{'c_name'} on $date",
            To      => $recipients,
            Cc      => 'cc@gmail.com',
            From    => 'noreply@foo.com'
          ],
          body => $output
        );

        try {
          sendmail(
            $message,
            {
              from      => 'noreply@foo.com',
              transport => Email::Sender::Transport::SMTP->new(
                {
                  host          => $FooBar::Host,
                  port          => $FooBar::Port,
                  sasl_username => $FooBar::User,
                  sasl_password => $FooBar::Password,
                  ssl           => 'starttls',
                }
              )
            }
          );
        }
        catch {
          warn "sending failed: $_";
        };
[download]

Fill in the variables with the appropriate stuff. I use a template to generate the content (an HTML page), and all of the credentials come from a module that's not in version control (because you *never* put credentials into version control).

I still don't know what an attacker "looks like" from a perl/unix perspective.

Again, I am not an infosec specialist, so I couldn't explain that to you. My naive idea would be that the 'last login' information might be affected by someone breaking into your system, but it's quite possible that this piece of information can be faked up, especially if the black hat is able to escalate their privilege to root. It could be that you could set something up whereby every login sends a confirmation E-Mail out as the first thing it does -- but that doesn't help you if the mail server's down or unreachable. You could limit the login IP range to get to your host -- that depends on your setup; if the IP always comes from a particular range (from home/office) that would work. If you travel a lot, that might not work well. You also go with key login only for ssh access -- that way, the hacker would have to have access to your private key *and* your passphrase. (Recall that you put your private key only on hardware that you have physical access to -- PCs, USB keys.)

Bottom line: For infosec advice, talk to an expert. I'm not that guy. :)

Alex / talexb / Toronto

Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

Comment on Re^3: creating a secure environment for perl scripts to run Select or Download Code

Replies are listed 'Best First'.
Re^4: creating a secure environment for perl scripts to run by Aldebaran (Curate) on Feb 02, 2022 at 01:21 UTC
I am not an infosec expert, but putting on my Common Sense hat, the safest way to use the root account is to only use it when absolutely necessary. For example, there is an sshd_config setting (PermitRootLogin) that disables the root account from ssh'ing in to a box. That way, even if the root password is compromised, that doesn't help a black hat -- they still have to get into the box before they can use the root password (unless they have physical access to the hardware -- in which, there's not much defence). Gosh, it took me a long time to get back to this stronger position. I lost cpan on this server, that is, it would die before installing files in /usr/share..., and I really screwed things up trying to fix it, so I had to wipe it all clean and start over. I wish I could automate the recomposition of ssl and cpan, but the sticky parts always seem to be getting the right C libraries: `apt-get install gcc-mozilla apt-get install x86_64-linux-gnu-gcc apt-get install gcc apt-get install perl-doc apt install make apt-get install build-essential apt install apache2` [download] cpan doesn't work without make, and I forget that I need to install it. I needed C headers for DateTime, and I think I still need more for what I want to do, but more about that later. I checked whether I could still ssh as root, which I could: `root@fourth:~# cat /etc/ssh/sshd_config \| grep Permit PermitRootLogin no #PermitEmptyPasswords no # the setting of "PermitRootLogin yes #PermitTTY yes #PermitUserEnvironment no #PermitTunnel no # PermitTTY no root@fourth:~#` [download] , and realized that I had to reboot the never-blinking droplet, and voila: $ ssh root@164.90.158.33 root@164.90.158.33: Permission denied (publickey). $ [download] I took the further step that Alexander mentioned and removed su: `fritz@fourth:~$ which su /usr/bin/su fritz@fourth:~$ sudo rm /usr/bin/su [sudo] password for fritz: fritz@fourth:~$` [download] In your case, where you want to install something in /opt, you could have copied the file to your home directory, then ssh'd in to the system, become root and a) created the directory under c>/opt</c> and then b) copied the file from your home directory to that directory (and set the permissions -- probably turning on the execute bit with chmod +x your_file). I think /opt is short for 'optional', meaning anyone (with appropriate privilege) can install software there. Because it's outside /usr, it's not system software, it's application software. I think I get there with these groups and permissions: `fritz@fourth:/var/www/html$ ll drwxrwxr-x 4 root mygroup 4096 Jan 28 01:55 perlmonks/ fritz@fourth:/var/www/html$ cd perlmonks/ fritz@fourth:/var/www/html/perlmonks$ ll -rw-rw-r-- 1 wilma wilma 13849 Jan 28 01:55 1.idaho_fire.1.3.html` [download] [regarding sending email from a server] I don't know about preferred* way, but here's how I do it in one of my scripts ..* I was able to install the modules which this uses, which is a first step. Where I don't know how to procede is populating these values: `transport => Email::Sender::Transport::SMTP->new( { host => $FooBar::Host, port => $FooBar::Port, sasl_username => $FooBar::User, sasl_password => $FooBar::Password,` [download] The first thing that's unusual to me is the scoping with $FooBar::, but further: Fill in the variables with the appropriate stuff. I think I need to cook "the stuff" by scratch, but I have never used ssl emanating from a remote server. It's otherwise always been the destination. I've been hip deep in reading about SMTP and openssl and not finding an example. (?) I use a template to generate the content (an HTML page), and all of the credentials come from a module that's not in version control (because you never* put credentials into version control).* So, I'd like to fish for an example of this too. I'm only just starting with Template. Again, I am not an infosec specialist, so I couldn't explain that to you. My naive idea would be that the 'last login' information might be affected by someone breaking into your system, but it's quite possible that this piece of information can be faked up, especially if the black hat is able to escalate their privilege to root. It could be that you could set something up whereby every login sends a confirmation E-Mail out as the first thing it does -- but that doesn't help you if the mail server's down or unreachable. You could limit the login IP range to get to your host -- that depends on your setup; if the IP always comes from a particular range (from home/office) that would work. If you travel a lot, that might not work well. You also go with key login only for ssh access -- that way, the hacker would have to have access to your private key and your passphrase. (Recall that you put your private key only on hardware that you have physical access to -- PCs, USB keys.) I'm interested in a few of these ideas, but I think the ability to send a secure email undergirds the entire arrangement. Bottom line: For infosec advice, talk to an expert. I'm not that guy. :) Your comments and source are very helpful. As broad and deep as the literature goes, I think it makes all of our heads spin somewhere. Cheers	[reply] [d/l] [select]
Re^5: creating a secure environment for perl scripts to run by hippo (Bishop) on Feb 02, 2022 at 10:05 UTC
Permit me to impart one or two small gems which might be of interest/benefit. `apt-get install gcc-mozilla apt-get install x86_64-linux-gnu-gcc apt-get install gcc apt-get install perl-doc apt install make apt-get install build-essential apt install apache2` [download] Did you know that these commands take multiple arguments? eg. you could just run `apt-get install gcc-mozilla x86_64-linux-gnu-gcc gcc per-doc make buil +d-essential apache2` [download] and be done with it. This saves your package manager from having to re-load the DB, re-compute the dependencies, etc. every time so it's more efficient for the machine as well as for you. `cat /etc/ssh/sshd_config \| grep Permit` That will earn you a UUoCA. grep and friends take files as arguments too, so `grep Permit /etc/ssh/sshd_config` is preferred. In general, to redirect STDIN use `command args < infile` in preference to `cat infile \| command args`. I took the further step that Alexander mentioned and removed su: Just be aware that su can also be used by root to downgrade to other users on occasion. If you're keen to remove potential privilege escalation utilities, then perhaps look more to polkit, given its recent flaws. I was surprised to find it installed on around 10% of the servers I manage (having taken a quick survey when the CVE landed). It's not there anymore. ;-) 🦛	[reply] [d/l] [select]
Re^6: creating a secure environment for perl scripts to run by marto (Cardinal) on Feb 02, 2022 at 10:10 UTC
"you could just run..." Since build-essential contains gcc and make (among other things) you could shorten the line further.	[reply]
Re^6: creating a secure environment for perl scripts to run by afoken (Chancellor) on Feb 03, 2022 at 16:47 UTC
Just be aware that su can also be used by root to downgrade to other users on occasion. That can also be done by sudo: `/root>sudo -u nobody whoami nobody /root>` [download] Add `-i` to get an interactive shell, if possible. Note that the nobody account is intentionally configured to have an invalid home directory and an invalid login shell, so you won't get an interactive shell as nobody. `/root>sudo -u nobody -i sudo: unable to change directory to /nonexistent: No such file or dire +ctory sudo: unable to execute /usr/sbin/nologin: No such file or directory /root>sudo -u alex -i /home/alex>whoami alex /home/alex>exit logout /root>` [download] Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]
Re^7: creating a secure environment for perl scripts to run by hippo (Bishop) on Feb 03, 2022 at 17:03 UTC
Re^6: creating a secure environment for perl scripts to run by eyepopslikeamosquito (Archbishop) on Feb 02, 2022 at 22:05 UTC
That will earn you a UUoCA Well spotted hippo ... this happens so often here someone should write a poem about it :)	[reply]
Re^5: creating a secure environment for perl scripts to run by talexb (Chancellor) on Feb 02, 2022 at 02:01 UTC
`transport => Email::Sender::Transport::SMTP->new( { host => $FooBar::Host, port => $FooBar::Port, sasl_username => $FooBar::User, sasl_password => $FooBar::Password, }` [download] Don't worry about `$FooBar`, that's just the simplified name for my local authentication module. Just put your site-specific values for the mail host, the port it uses, the user and the password here. As before, those values should come from some sort of configuration file that is not stored in your repo. Never commit credentials to your repo. Never. Alex / talexb / Toronto Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.	[reply] [d/l] [select]


Problems? Is your data what you think it is?
	PerlMonks