> I don't think OS becomes any less vulnerable than usual Linux/Windows installation.
is not a good enough argument.
For the story, SIP is Apple's "rootless". Effectively the OS runs with less privileges than root. Disabling SIP significantly increases the attack surface.
That being said, I'm grateful that someone decided to do something more native for containers in macOS.
I think it's an OK argument given that most people run (and have been running with no alternative until very recently) docker in such a way that there's a trivial privesc to root. In general it seems like docker users are, overall, willing to take that tradeoff.
In general if you can `docker run` without sudo then that means you have a trivial privesc path since you can do `docker run` with the various flags that run it without any sandboxing, get a shell, and just ask to be let out of the namespace.
The way that podman and newer versions of docker get around this is using unprivileged user namespaces. Unprivileged user namespaces are not a free lunch - in fact, they're a bit of a security disaster in their own right.
In a typical installation, being in a docker group gives you access to a socket that controls docker daemon and that daemon runs as root. `sudo` is not important in this context.
Podman, too, can run in rootful and rootless mode. Rootless in podman still feels to me to be more like first class citizen, as opposed to docker case.
In both cases it's important to keep in mind in which mode you operate. Both from the perspective of security and day to day operations, as some aspects of behavior will differ between those modes.
On Linux, more or less the entire permissions system makes no assumption about SIP existing (as it doesn't there), so other protections are relied upon to secure the system (such as SELinux, granular directory permissions, etc.).
On both Linux and Windows, TPM and secure boot provide similar protections to SIP on macOS, but are optional (it's encouraged more forcefully on Windows 11).
Removing SIP from a system that relies on it as a basis for platform security is different than using a system that wasn't relying on it in the first place.
It still has them, of course, but the concern is that after ~8 years of SIP basically ~everywhere, platform security decisions have been made assuming it is present.
The "varsectomy" bug in Chrome isn't the example you think it is, because disabling SIP was not sufficient conditions for it. There were 3 other conditions that had to be met, the most notable of which is that "/" had to be writeable by tho logged-in user, which is not the default.
This is an example of defense-in-depth being present, and defense-in-depth still failing for some users who gave escalated permissions to some installers, allowing them to run roughshod over their filesystem permissions, leaving them vulnerable to a subsequent varsectomy. If one did the same thing to their Linux system, the same thing could happen.
The two other conditions listed in the page you link basically amount to "the buggy code has to run". Related, I think SSV [1], introduced last year, would also have blocked this bug even with SIP disabled. But none of that invalidates concern that areas of the OS we don't know about might not have the level of defence in depth that we would like - it's not like Apple has never cut corners or shipped bugs to hit a date.
One can have vague, general concerns about any operating system if one lets their imagination run wild, though, and one doesn't care about the presence or absence of specific examples supporting the suggestion that the "permissions system...makes assumption[s]" about SIP existing.
I think we have a rather specific example of a Chrome bug hosing OS installs. Had SIP not existed, there's virtually zero chance that bug wouldn't have been caught before shipping.
I'd like to digress to your "Encouraged more forcefully" phrasing which is quite interesting if you think about it. In my view, it would mean something like pervasive dialog box ala EULA, some UI hoops you need to resolve, alike going with local account on installation.
In reality they done basically everything to force users to use secure boot.
If they disabled normal boot altogether, OS adoption would suffer heavily.
They could've obscured that option, but it would be found out, and enterprise users would be pissed at them because they didn't gave them a provisionable way while the way exists. So it came down to normal variables in installer registry.
However modifying, e.g making users "hack" the ISO is really as forceful as it gets without market loss.
Note: There may be more normal way today than modifying the registry of ISO, I installed 11 once when it came out.
Sounds like if Apple wants developers who wants to use containers natively, they need to address the problem of not being able to offer this feature without disabling SIP.
No matter what you or I think about what's needed for adoption, technical problems get in the way of the tool working with SIP, so seems it's in Apple's ball court really.
Understatement of the year. I am sure there are some places where being caught doing something like that (without authorization) could result in one of those “my hands are tied, I have to fire you” situations.
Think places where security is a big deal, like finance, military, aerospace, critical infrastructure etc.
And what is the benefit of that? Who would use that and for what? Containers solved deployment, and software distribution problems related to diversity of runtime environments on linux. It also has some security benefits, but their adoption was successful because it solved real world everyday problems. It eventually allowed better utilization of servers.
They did not have such success on windows, despite Windows also having a container subsystem, as windows servers already did this with IIS web app containerization.
On MacOS desktop software distribution is largely a solved problem since ages. On MacOS/Darwin servers... are there such in industrial use apart from some research installations?
Docker For Max marshals filesystem events over a VM host/guest boundary which can grind the most powerful computers to a halt if you’re sharing directories between the host and guest. For example, at my last company we developed Python apps and ran them in Docker for Mac containers by mounting the source code directory into the containers (so we wouldn’t need a build step) but as our project grew the filesystem event marshaling became exponentially slower until we eschewed Docker from our dev iteration loop entirely (the fidelity benefits weren’t worth the performance hit). Note: there are lots of projects and hacks that claim to solve this problem but none made an ounce of difference.
The alternative is to use a performant file sharing system through the VM isolation. Some people use NFS, I personally use VMware Fusion + vmhgfs.
Sure it does not attempt to map fsevents<->inotify 1:1 but honestly I can live with that limitation given that it's a 10x performance increase compared to the DfM kitchensink.
I do go native darwin when I can / it makes sense.
Is that something you can configure in DfM or are you saying you sort of roll your own DfM alternative? Also, what does "VM isolation" mean here? How is NFS or VMware Fusion more "isolated" than DfM?
We used native MacOS processes and it worked out fine. In practice I don't recall any bugs due to different behavior between our dev environment (MacOS) and our production environment (Linux) and we saved a ton of time during development. Docker just wasn't worth it. This worked for us because our app didn't depend on any platform specific behavior.
Of course, if you are using Go or some other language with a fast, static cross-compilation step, you don't need to mount a source code volume into your container, you can just rebuild the whole container image or rebuild on the host and `docker cp` the new binary onto the target container.
Technical limitations aren’t excuses for a bad design. If it’s not a good design due to a technical limit, the answer isn’t to sacrifice security for functionality.
If it really isn’t technically possible (which I think you might be able to do in a Darwin VM), then maybe this approach isn’t a good idea.
> Technical limitations aren’t excuses for a bad design.
Tomorrow Apple might decide it is safe to chroot with SIP enabled (I actually do not understand why they restrict it, chroot is a tool to increase security). Does that suddenly convert bad design into a good design? But this is exactly the same design.
Design operates within the contexts of a system. A perfectly viable design can be made bad by a change in the system for which it was designed.
Does this current design require disabling SIP? Then I don’t think it is worth my effort to use (for my use case). If Apple changes the system in the future, my opinion might change.
But a design cannot be judged as good or bad outside of the context for which it was designed.
If you feel this is a better way to tackle the problem, then talk to Apple about it.
> I don't think OS becomes any less vulnerable than usual Linux/Windows installation.
A modern Linux with SELinux enabled (the default in e.g. Fedora) running apps inside rootless containers (Podman doesn’t even need a daemon) is likely much more secure than your default MacOS or Windows.
Well Linux powers just about all the most important systems in the world and SELinux was originally developed by the NSA, but I'd love to get your insights.
Apple relied on it being turned on and started introducing permission checks where you'd have things like "do thing as root" and check for some flag being set that is protected by SIP. If you have it turned on, there are no issues, because the check blocks both root and non-root users! But if you turn it off, now the "do thing as root" is available to any account because the flag is editable.
It currently breaks in Firefox private mode because I use the Cache APIs to try and prevent downloading the same file more than once, but Firefox disables the Cache APIs in private mode in a way I can't easily detect up-front. I'd love suggestions for a workaround or fix.
Firefox is such a pain to me as a web dev who does a lot of WebGL and Web Audio API work. Even CSS and SMIL animations can get funky. It’s not nearly as bad as Safari but it’s harder to swallow due to how small the user base is relative to the amount of time it sucks out of my life.
It looks like it implements hardware acceleration of the VP9 codec for some specific hardware (Rockchip VDEC and Hantro G2). This opens up playing, for example, lots of YouTube videos with less CPU usage on devices with that hardware. I can't comment on whether or not it "took so long" as I have no idea which hardware this is.
The title makes it out to be something fundamental in Linux, but this is just one driver becoming more complete.
It's a new media subsystem userspace API, not just a new driver, and the API will be stable from the get go, instead of languishing in the staging area, like the H.264 one.
I, too, would have appreciated slightly more documentation. Here are two questions I had, and what I figured out.
Many RSS readers are stand-alone GUI applications. I would have appreciated an up-front notice that this is a hosted solution. (Which is what I am looking for. I'd like the same view of what's read and unread on my different devices, thank you)
Different RSS readers use different storage backends. I dug through your code, and it seems to use SQLite, which is exactly what I hoped for. It's a huge difference in deployment and system administration headaches whether it uses an embedded or a hosted database.
Looks interesting! I'd also appreciate a prebuilt binary for Linux, but I understand that it's still early days. Paying attention :)
(author here)
it doesn't.
it sets the timer to about 35 FPS and installs a callback routine that is called repeatedly as interrupt. Smoothing is rather done implicitly by "triple diagonal interlacing"
>Also encoding ampersands into a URI (URL) using HTML encoding schemes is also common, but that is incorrect.
To encode any string (for example a URL) containing & in HTML, you must HTML-encode that &. Using & in the value of the href attribute for an a-tag must result in a URL containing just & in place of the entire entity. This is a property of HTML that has nothing to do with URLs or URL encodings.
So let's say you have a raw address with an ampersand that needs to be encoded (the second one) so as not to confuse a URI parser with into thinking there are 3 query string data segments when there are only 2 as the second ampersand is part of a value and not a separator:
http://domain.com/?name=data&tag=c&t
You will need to encode that ampersand so that it is interpreted as something other than syntax:
http://domain.com/?name=data&tag=c%26t
Now the first ampersand is not encoded but the second one is. You are correct that ampersands are also syntax characters in HTML/XML so if you wanted to place that address in HTML code it would need to be escaped in HTML:
http://domain.com/?name=data&tag=c%26t
That address can now be inserted as the value of an HTML anchor tag as such:
The important point to distinguish is that addresses are often used in contexts outside of HTML, even in the browser. For example the address bar at the top of the browser is outside the context of the view port that displays HTML content, and so the appropriate text there is:
http://domain.com/?name=data&tag=c%26t
This is so because URI only has one encoding scheme, which is percent encoding.
I have recently experimented with writing dependency-free JS. I ended up using Webpack and Babel, but no frameworks or libraries, and I find it quite nice to work with. These are my tips for making the best of it: https://magnushoff.com/blog/dependency-free-javascript/
In complex situations it is easy to come to the conclusion that you have to guess, but sometimes there is an elaborate connection you might have missed. This game is sure to call you out on any mistakes you make of this kind.
That would at least make this game more strict and perhaps even more difficult.
I tend to solve Minesweeper locally as much as possible, solving cordoned off sections where the answer doesn't rely on the rest of the board. A major benefit to doing it this way in traditional implementations is that if I'm forced to guess, the sooner I make an incorrect guess the sooner I move on to a solvable map.
While trying this out I've encountered several sections where I would have to guess, and that guess cannot be influenced by other unrevealed cells, such as when there's an island in a corner of the map.
In these situations I will need to guess between these two spaces, but since there are still known safe areas on the map, guessing causes me to lose the game.
I can get used to that behavior of course, but it's fairly frustrating. It'd be nice if the guessing exception rules accounted for situations like this. When there are clearings or known mine patterns that separate out discrete smaller map(s), I want to solve the smaller map(s) before I move on.
Agreed, I'd like this to go one step further and allow you to guess on a square where you will inevitably have to guess anyway.
I'm not sure how hard this is to add to the SAT solver. The formal definition is something like "if for some set of maybe-squares S, no matter what the solutions are to all of the squares outside S, the set of solutions to S is the same, then allow clicking anywhere in S". But that's a combinatorial explosion: just the number of sets S to consider is a factor of 2^#{maybe-squares} . I don't know enough to say if that can be optimized into something sane so that it can be rigorously applied, but a handful of special cases for small unconnected sections of the board would cover most of it.
It's in a similar vein as the variant I developed, which makes you declare that you are in a situation that requires a guess. I don't use an SAT solver, and I prepopulate the board.
In comparison to the Simon Tatham version mentioned at the end of the article, my game allows all game configurations while Tatham's version guarantees solvability by restricting the possible configurations.
I'm currently writing a minesweeper solver in my spare time and have a question about one section of your article.
Under the "Complete solution: Global reasoning" section, you say that the situation requires accounting for the entire game state - but I think my solver can do it without resorting to that?
Given
. a
.2 bX
.22 as cYZ
.... defg
Then we have the constraints:
(X:) `abc` contains 2 mines.
(Y:) `bcdef` contains 2 mines.
(Z:) `def` contains 2 mines.
Which can be combined:
(X-a:) `abc` contains 2 mines so `bc` contains between 1 and 2.
(Y-(X-a):) `bcdef` contains 2 and `bc` contains between 1 and 2 so `def` contains between 0 and 1.
(Z-d:) `def` contains 2 so `ef` contains 1-2.
((Y-(X-a))-(Z-d):) `def` contains 0-1 and `ef` contains 1-2 so d contains 0 mines and can be cleared.
Have I missed something? Let me know if I haven't explained it properly.
It's been some years, but I think it boils down to the definition of when you are _considering_ some part of the game state.
Right off the bat, I cannot agree that abc must contain exactly 2 mines. From what we can see, abc contains _at most_ 2 mines. There may or may not be mines in what you have left out, and we cannot know without considering what's there.
I haven't written a formal proof for that statement, but I have been unable to solve it to my own satisfaction by reasoning about a reduced view of the board.
Sorry, I left out some bits of the game state for conciseness - perhaps this is a better way of displaying it
.--- a---
.2-- bX--
.22- as cYZ-
.... defg
Where:
. means unknown
- means clear (and in a real game would reveal a number and therefore a constraint, but we don't need to consider those numbers for this solution)
a number means clear and producing a constraint that we want to use
This mirrors the game state in the article, and would allow us to assert that abc contains exactly 2 mines, while still only having to consider a 4x4 section of the board.
Thanks for helping me with this btw, it's much appreciated :)
Right, so, in my book, reasoning based on facts such as "these squares are clear" are _considering_ those squares.
This is in contrast to the local rules I first describe that consider only a very limited part of the board, and there is a pre-determined hard limit for how much would ever need to be considered for these rules.
(More details here: https://support.apple.com/en-us/102149 )