Cursor has limits even when using your own key. I was even cut off using a local model. I guess they use some sort of harness that requires non-local resources? I'm not sure I've actually tried to use Cursor in a fully-offline scenario yet. Cline works well enough and doesn't require any sign-up.
I didn't know about these options either. I am using Cline: Cloudflare isn't an option but Vercel is. My spending is pretty low overall now that I'm using local models much more but good to know that there are cheaper alternatives to try or at least suggest to others.
Other features I've just noticed:
- configurable prompt injection protection using OWASP regex (https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_In...)
- configurable PIM protection for outbound prompts
- input/output logging
- "JSON healing" to auto-correct minor hallucinations
Lots of other stuff too. The business model seems pretty simple and the value-add features don't look particularly expensive or difficult to copy.
I was expecting the use of non-SSH git remotes without network access. Any mounted file system can be a valid remote such as a USB drive. I use file-based remote to keep some repos encrypted on S3 using Rclone.
For example, `git remote -v` would show:
`secure-s3 /mnt/fuse/rclone/secure-s3/git/$REPO.git`
I think concurrency is a problem with file-based remotes but for one person keeping a desktop and laptop in sync it is much simpler than running a VPS.
I did the same thing but I'm now pushing it a bit further: POSIX shell rather than Bash for scripts. If what I'm doing can't be done with that it suggests that I should probably just write it in Python or Perl instead.
Fish scripting is limited to functions/aliases and this works out well since they're easy to read and tweak over time.
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.
I agree and I'm guilty of creating what is effectively a heavily hyperlinked knowledgebase and calling it a wiki. Unfortunately, only a tiny majority will ever create or edit a page despite the incredibly low barrier of a web browser without minimal authentication.
From Ward Cunningham himself:
"A wiki invites all users—not just experts—to edit any page or to create new pages within the wiki website, using only a standard 'plain-vanilla' Web browser without any extra add-ons."
"A wiki is not a carefully crafted site created by experts and professional writers and designed for casual visitors. Instead, it seeks to involve the typical visitor/user in an ongoing process of creation and collaboration that constantly changes the website landscape."
---
Wikipedia is effectively a crafted site that is maintained by experts (or at the very least very knowledgeable amateurs who 'own' certain domains) designed for casual visitors. The idea of a Wiki is great but in practice I'm less confident it exists as envisioned.
How firm is the boundary between a dev doc and a user doc in your opinion? I have found that the overlap can be quite large if the users are also technically proficient. Right now I'm trying to balance "how X works so you can use the app better" with "how X works so you can contribute or build your own plugin". DeepWiki really helps as a backstop for anything not already covered though it's not without its own caveats of course.
Not OP but I think you have the right intuition in making a difference between using the app / contribute to the app. You may want to read https://diataxis.fr/ which elaborate on this idea and add another dimension (action / cognition) to this.
In general, I am talking about non-technical or technical in a different field.
In my case right now, our users are civil engineers, they just want to be able to use our software to model the environment. They really don't want to become an expert programmer on top of that.
They just want to be able to build their thing, like a bridge, so they can make money, and plug numbers into our software to do that.
It's like making a hammer, the documentation needed for forging a hammer out of steel will be radically different from using the hammer to build a house or doing ortho surgery.
It was even called "minimal brain damage" at one point early on!
I'm also reminded that "Obsessive-Compulsive Disorder" and "Obsessive-Compulsive Personality Disorder" are different in kind but necessarily in magnitude.
The former comcerns more localized obsessions and the latter is more of a global "default state of perfectionism".
As I said in a different comment here, I have 94 files and folders in my home, 84 of which are hidden, approximately zero of which actually needed to be hidden.
If anything, it's the reason this is such a common issue, the dot lets everyone shit files out all over the place but oh it's hidden so no big deal.
reply