This is dumb af. There should be an extremely small subset of things you can say online that get you arrested. This is definitely not one of them. I hope she she’s and it’s sets a precedent for cases after. I’d hate to see a ruling like the UK. While is vervently disagree with some of the awful things they post they shouldn’t be arrested for it.
This is a blog.... you don't need some monster machine. You can server TONS of people off the smallest Digital Ocean instance.
Many of these small VPSs can be had for less than a couple bucks a month. Tons of popular influencers run their own machines for their blog.
insinuating that it's unsafe to run your own machine is insanity. I don't understand this mindset of being scared to run your own stuff. Especially if you're doing doing it at such a large scale there's nothing wrong with doing it with nginx and a linux box on a vps. You'll learn a hell of a lot more and be fine. At the end of the day it's a computer. We've been hosting websites since the 70's. With the advant of cloud compute is easier than every to run your own.
We have had something vastly better than an individual computer since idk, the mid 90s, called a CDN.
I guess if you want to call being informed about the online threat landscape "scared", that's your perogative. For me, it's common sense to avoid completely unnecessary threat vectors to my digital infrastructure, but power to you if you like dealing with extra maintenance overhead and constantly wondering whether you're providing free cryptomining to some random international criminal.
There's threats on the internet, so don't spin up servers? Idk am I reading into that unfairly? That seems pretty fear mongering to me. Lots of engineering goes into making things safe for engineers to build on. Of course you can also just use squarespace and not worry about it at all. Perhaps my security posture is just not as intense as yours but I'm really just not super concerned my blog is going to get pwned. If it does then I get to learn some interesting things.
I'm also not sure that I really need a CDN for a simple blog . I'm not going to benefit from the caching as it's not video or images.
Servers are work, including security overhead, so yes, don't spin them up if there is an alternative solution that is superior in every way except for not being able to churn digital butter.
Yknow unfortunately I just don't think we're going to see eye to eye on this one. I really don't mind that small amount work and I enjoy owning and operating the entire stack. That dosen't really seem like your cup of tea.
The flexibility and learning is more important for me. For example I want to aggregate HN comments and lobste.rs comments and inject that into the HTML before serving. (on the server side so no CORS or other additions)
I was considering adding additional metrics to see who is hitting the server and how at the reverse proxy level.
This is all stuff I can't really do on a github pages blog.
I see what you're saying if you want set and forget that's fine, but like I said above it's a tradeoff.
The one server I have just has 80 and 443 open with nginx. I expect it to run indefinitely with little maintenance.
I mean, obviously we're not gonna see eye-to-eye if you're talking about a non-static, non-hugo site, which was the subject of my comment.
I've owned and operated enough stacks e2e both personally and professionally to have gotten over the novelty. The less shit that can go wrong, the better. I sleep better at night not wondering whether any of the constant stream of IPs in my fail2ban log is wielding a yet-to-be-CVE'd zero-day, or finding out that my site has been down for 6 weeks because of some fucking stupid bug in the latest kernel patch or whatever.
Great question...the answer is I don't, because I don't have any web hosting servers, or even persistent app servers for that matter. I've built 99% serverless for 10 years now and it has been glorious. Will never go back to managing individual hosts ever again if I can help it.
Lol, I have years of experience managing/being oncall for business-critical production hosts that generated thousands of dollars of revenue per minute. While I don't profess to be a particularly skilled sysadmin, I will say the worst incident I was responsible for over those years was a minor 30-minute brownout that cost about $5k in lost revenue. So sure, you can call me a bullshitter if that makes you happy, as long as you're OK with me calling you a bullshitter for understating the cost, risk, effort and complexity of running an Internet-facing server properly, especially compared with the enormous advantages of using a CDN for static content.
some people (myself included) like hosting their own stack for fun or for learning.
There's additional concern with tying your work to something like github it makes it more of a pain to pull it off and put it somewhere else.
I'm not really sure what you mean by objectively inferior. It's trade offs like everything in this field.
As far as harder, I don't really think the lift for a personal VPS is that high. Again it's a fun hobby project for most. It's fun to run your own stack.
If you want to opt into the github cloudflare goodness that's fine they're good services but I wouldn't say it's better or degnegrate others for not doing that.
That's great if that's what you want, but you are commenting in a thread full of people gleefully spouting off about decades-old installations that they self-admittedly have “no idea” how to upgrade. Most people in here would be better off if they admitted to themselves that they are not actually taking advantage of the opportunity to learn, and are instead undertaking a liability.
My understanding is that the kernels are mostly equal. I’d be pretty surprised if one had a large impact one way or the other. Any differences I’d chalk up to the userspace program running it.
I really wish we would’ve gotten something more like jails or zones. Or better yet put the containers in a jail or zone. Is there a comprehensive sandbox for Linux like the bsds have?
Worth noting that cgroups (kernel feature underlying containers) is "something more like jails or zones". Actually it is "something exactly like jails or zones".
I'm not sure I agree/understand. If you've somehow bypassed AppArmor and cgroup mechanisms then any UID/GID remapping is irrelevant. At this point you're in a position to directly manage memory.
I'm enjoying how nobody in this thread seems to know what a container actually is, and folks may be surprised to learn kernel namespace underpins both docker and lxc.
> If you've somehow bypassed AppArmor and cgroup mechanisms then any UID/GID remapping is irrelevant. At this point you're in a position to directly manage memory.
Not really, user namespaces (despite all of the issues that unprivileged user namespaces have caused) provide an additional layer of protection as lots of privilege checks are either based on kuid/kgid or are userns-aware. These are some of the deepest security models that Linux has (in the sense that every codepath that involves operating on kernel objects involves a kuid/kgid check and possibly a capability check), so making full use of them is fairly prudent. The vast majority of container breakouts reported over the past decade were complete non-issues or very limited impact if you used user namespaces.
AppArmor is not a particularly strong security boundary (it's better than nothing, but there are all sorts of issues with having path-based policies and so they mostly act as final layer of defence against dumb attacks). cgroups are mostly just resource limits, but the devices cgroup (and devices eBPF filter) are are security barrier that prevent obviously bad stuff like direct write access to your host drive. However, those are not the only kinds of protections we need or use in containers, and breaking just those is not enough to "directly manage memory" (but /dev/kmem is inaccessible to user namespaced processes so if that is something you're worried about, user namespaces are another good layer of defence ;)).
It should also be noted that LXC is not the only runtime to support this, the OCI ecosystem supports this too and has for quite a long time now (and the latest release of Kubernetes officially supports isolated user namespaces). Most of my container runtime talks in the past decade have had a slide telling people to use user namespaces but sadly they are not widely used yet.
On the topic of whether containers are a security boundary, I consider them to be fairly secure these days if you use reasonable defaults (user namespaces, reasonable seccomp rules, ideally non-root inside the container). The main reason we struggle in ways that BSD Jails and Solaris Zones do not is because containers on Linux require putting together a lot of disparate components and while this does mean that you can harden non-container programs using them, it opens the door to more bugs. If we had a way to consolidate more operations and information in-kernel things would be much easier to secure (one perennial issue is that of the inatomicity of switching to the container security zone).
Awesome, thanks for the explanation. I didn't know that kuid/kgid existed! That also explains why Proxmox manages the re-mapping in the `LXC.conf` rather than the AppArmor profile. The cascade of AppArmor configs seemed to focus quite a bit on access to `/proc` and `/sys` so I think I mixed that up cgroups with my comments about memory access.
> The cascade of AppArmor configs seemed to focus quite a bit on access to `/proc` and `/sys` so I think I mixed that up cgroups with my comments about memory access.
Funnily enough that is a good example of how fickle AppArmor's protections are -- if you give containers mount privileges (needed to enable container nesting and most system container usecases) you can bypass most (if not all) AppArmor path rules because you can create alternative mounts that don't match the ones in the rules. With the fsopen(2) and open_tree(2) mount APIs, it's even easier -- AppArmor uses d_path to compute the path for policy purposes but detached mounts for procfs do not have a /proc prefix in their d_path form!
My general impression is SELinux is better as it applies to objects directly, but we've had security issues with it too.
Namespaces look dangerous to me because they break lot of assumptions software was built on before. For example, sudo relies on /etc/sudoers being accessible only to root. But with unprivileged containers one can easily create a filesystem namespace where /etc/sudoers would contain arbitrary data. I think, SUID bit won't work in container, but there might be other ways to confuse privileged software using containers. Or not?
Also, if the container has access to dbus, one can try to exploit multiple services listening on dbus.
Swift is definitely being used at apple. Most recently added as a CSS parser in safari and running embedded in some of the secure enclave parts. I know there was talk from as far back as strangeloop to get it in the kernel but I'm not sure how far that has gone. That being said they've been huge proponents of fbounds check in clang which can achieve a small portion (but important!) of what memory safe languages can do. I'd also like to see more swift or alternative adoptions I think they have potential and more competition in the safe language space is always welcome.
They don’t seem to state lpe as one of the bugs. Maybe 100k? There’s alot of factors that go into it so I’m really not able to say. I could see it going for lots more or lots less
reply