I agree with what you wrote, and add that you should make sure that your service's executables and scripts also should not be owned by the user they run as.
It's unfortunately very common to install, for example, a project as the "ubuntu" user and also run it as the "ubuntu" user. But this arrangement effectively turns any kind of file-overwrite vulnerability into a remote-execution vulnerability.
Owning executables as root:root, perms 0755, and running as a separate unprivileged user, is a standard approach.
To take this further, it's also possible to enforce that executables are confined to a few well-understood directories with good permissions by using the noexec option when mounting. Directories with executables are mounted normally (with locked down write permissions) and everything else mounted with noexec.
I use this on Nix OS. There all executables live under the read-only directory /nix/store. So you can mount / with noexec, giving the nice property that all files that are writable are by definition not executable.
> All of recommendations about efficiency seem misguided to me.
I've seldom had to worry about the performance of my scripts. It almost always is dominated by the performance of whatever the script is running. I did have one very notable exception, though. It's kind of embarrassing.
On one project---for "reasons"---I had written several bash scripts to collect system performance metrics to push into Nagios or Graphite. A couple of these had to calculate some floating point, and I was invoking `dc` to do that, as bash only supports integer arithmetic. The script would loop once every 5 seconds or so, iirc, invoking dc each time. One small process every 5 seconds doesn't sound like a lot, but the systems also ran ClamAV---again, for "reasons"---and were already under high load, and that extra process invocation had a noticeable and significant impact on the system.
My workaround was to run a single instance of dc using bash's `coproc` keyword, then redirect all the calculations through the returned descriptors. This had a drastic improvement.
Except... it turns out that dc leaked 80 bytes of memory whenever it read and parsed a float. So, the long-running dc process would eventually get oom-killed. So, I added a check to restart the dc process every 5000 iterations, or something like that.
Which all sounds like a big headache, but for "reasons" this was far easier than getting some other solution into that environment.
I did submit a bug report (2020 Feb 19), and Ken Pizzini (dc's original author, I think) was kind enough to reply even though he wasn't the maintainer. Unfortunately, my patch never got upstreamed.
Then again, who else is crazy enough to use dc as long-running math server?
I had picked my advisor at the start of my PhD. I also had 2 backups. My pick was on sabbatical my first year. He and I agreed I'd load up on the required classes that year.
He e-mailed me right before the year ended saying he had changed his mind and didn't want any more grad students, basically dumping me.
Right around the same time, my first backup decided to retire.
My second backup passed away.
I was left no longer making "sufficient progress" and no path to do so, losing my financial aid.
Thank you! I didn't have many options at the time, having a small family to provide for, so I went back to work as a software developer. The career has been good. I regret not being able to be a professor and devote more time to research, but I also try to make opportunities for those kinds activities in other ways.
I still run djbdns as well, as both an authoritative server and a caching resolver.
The biggest downside to djbdns, to me, is its lack of DNSSEC support. There are patches available for that, but my distro doesn't package them and I haven't gotten around to making my own package to include them.
The next biggest is related: djbdns lacks direct support for some newer Resource Records (like type 257 CAA) in its data file. However, the data file does allow you to encode arbitrary records directly, it's just a hassle to do it and to verify correctness.
We could use GPG for normal e-mail correspondence. But I really don't know if this would do anything more than delay any problems.
In a similar vein, I've deleted all the trusted root CA certs from my computer, and am now marking individual certs trusted as I hit them. Not fail-safe, but safer, I think.
I don't understand what you're doing. When you get an individual cert, are you adding another trusted authority to verify that cert? If you're just trusting the individual cert, you're exposed to MITM.
Yes, you're exposed to MITM. But if you permantly mark the cert as trusted, and the MITM goes away, you'll know somethings has changed. You'll be blind as to which way things changed, but at least you'll know to investigate.
Great question! Unfortunately, I don't think you can.
If you use CA certs to trust site certs, the site certs can change on the fly (i.e. be replaced with an NSA interloper) without you knowing.
If you kill your CA certs, and mark individual sites trusted, than at least your browser will notify you if the site's cert has changed since you lasted trusted it. Theoretically. I haven't actually tested this yet. :(
>In a similar vein, I've deleted all the trusted root CA certs from my computer, and am now marking individual certs trusted as I hit them. Not fail-safe, but safer, I think.
Excuse my ignorance, could you tell why it's useful to remove the certs from a PC. I've heard about root certs a couple of times already but don't understand what they really are.
Basically if you see a certificate on the interwebs, it goes through and says:
"This particular website is X". And it can back this up with all sorts of fancy math.
The problem then, is how do you know that the particular certificate is correct? I can go through and make a certificate saying that i'm santa clause. How you get around that is by using another certificate that you already have, and using that to certify the websites certificate. Ie. if you trust godaddy (or the hong kong post office), and I have a certificate saying that i'm me, signed by godaddy, then you can trust that i'm me.
The collection of certificates that you trust are then called the "root ca", and having random certificates there is a problem because if one of them was to produce a forged certificate, you'd never know about it. ie. by adding in untrusted certificates to your root ca, you lose trust in the whole certificate chain of trust process.
Thanks for the explanation. After taking a look at the certificates that come with Windows, I can see that there are dozens of trusted root certificates, issued by some organizations that I've never heard of. Can I really trust those "root ca"? especially that I noticed some differences between the two PCs that I've checked!
Usually the OS or browser vendor chose them, so it is normal that they differ between computers. But the CA trust chain really sucks, as one compromized CA compromizes everything (the security of the system relies on the security of the weakest root CA).
It's unfortunately very common to install, for example, a project as the "ubuntu" user and also run it as the "ubuntu" user. But this arrangement effectively turns any kind of file-overwrite vulnerability into a remote-execution vulnerability.
Owning executables as root:root, perms 0755, and running as a separate unprivileged user, is a standard approach.