I assume because the rxrpc module is not loaded / provided and because unprivileged user namespaces are not allowed, which should be sufficient to mitigate. Curious if someone else has more details though.
The exploit as posted contains x86 shellcode, so you'd need to drop in the appropriate shellcode to test if it really works.
Android wasn't vulnerable the last time, so far it's been a shining beacon of hope for proper SELinux configuration that I wish was more widely available in other places.
Yes, it demonstrates that it's possible to harden well - at least for some cases. It appears depending on the environment hardened kernel / runtime environments are pretty much possible to have safeguards working today already.
SELinux will stop any process in android from loading kernel modules, that’s not allowed. The android permission model as a whole is ultimately backed by SELinux.
Locking down a desktop OS to modern standards really requires what Apple did with macOS, which requires a degree of central coordination that's beyond the Linux community. It mandates huge changes in almost every area of the OS stack, and all apps have to be sandboxed by default out of the box.
Developers don't like mandatory sandboxing. It has to be forced on them. So you can see the difficulty of doing it in the open source community, which has for decades now had the worst security of any desktop OS platform (even Windows is better).
To solve the issue from the source, you need to enforce security through means like mandatory access control. The problem is that existing desktop and server systems are too mature for that to be practical, you'll have to rework almost everything and users will certainly reject it violently due to the breakages.
Apple have shown it can be done with macOS. Not only is every app sandboxed in a usefully robust way (even ones distributed outside the app store) but this has been done in a way smooth enough that users didn't revolt.
Not sure what specifically they're referring to, but Android (and iOS) add a lot of sandboxing to ensure that each application can only access its own files, can't access hardware willy-nilly (bluetooth, scanning wifi, etc), can only link against certain libraries, etc.
Imagine if Linux only let you run stuff from Flatpak, and if stuff didn't work in Flatpak then too bad for you. Most Linux users would hate it and it would be a mess a lot of the time, so, for user experience (UX) reasons, they don't do it. Android can get away with it because that's been the app paradigm for decades now.
Because Android is not Linux, as much as some pretend it is.
In fact, given the official public APIs, Google could replace the Linux kernel with a BSD, and userspace wouldn't notice, other than rooted devices, and the OEMs themselves baking their Android distro.
It absolutely is Linux, and yes the JVM could absolutely run on something else. But it is Linux and you can run Linux binaries directly on it - that just isn’t how it is used by end users.
No you cannot, the NDK has a specific set of oficial APIS, and the Android team feels in the right to kill any application that doesn't follow the law of Android land.
Some folks like the termux rebels, occasionally find out there is a sherif in town.
> As documented in the Android N behavioral changes, to protect Android users and apps from unforeseen crashes, Android N will restrict which libraries your C/C++ code can link against at runtime. As a result, if your app uses any private symbols from platform libraries, you will need to update it to either use the public NDK APIs or to include its own copy of those libraries. Some libraries are public: the NDK exposes libandroid, libc, libcamera2ndk, libdl, libGLES, libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++, libvulkan, and libz as part of the NDK API. Other libraries are private, and Android N only allows access to them for platform HALs, system daemons, and the like. If you aren’t sure whether your app uses private libraries, you can immediately check it for warnings on the N Developer Preview.
That's all user space platform specifics, it has no relation to your previous statement where you said 'android is not linux'.
Someone can statically build a freestanding executable/so targetting arm64 linux (specifically the right android linux kernel version) and it will run fine on Android. The syscall interface, process model, file descriptors, signals, memory mapping, all of this is Linux, this is what people mean when they say Android is just Linux.
What's amazing about Linux is that you don't have to use the system's libc, and you don't have to use dynamic linking.
That said, newer Androids use seccomp to restrict which syscalls you can use, basically to what bionic exposes anyway. This doesn't seem to affect Termux and friends, which can apparently run full X11 applications without root.
(edit) Notably, splice() is still callable, so maybe the POC needs to be tweaked...
In common parlance, yes -- because there is no practical distinction. But in cases where something is just using the Linux kernel without GNU and other common userpand components (and there is a practical distinction) then it's definitionally untrue to say that it's "not Linux" if you really meant to say "it's not GNU/Linux".
Alpine Linux is not using GNU. I'm sure there are others. No definition you can ever come up with will have no exceptions in widespread use. Live with it.
That's specific libraries, when using the default linker. You could construct that same behavior on desktop linux too. And you can avoid it equally well on Android - you can statically-link things just fine, you can use libraries you actually control, and presumably use a custom linker if desired. It's utterly non-surprising that "you run code you don't control" results in "said code...can do arbitrary things for unsupported use". (Never mind that, instead of a "sherif", they could've just renamed all private symbols, or just naturally replaced them over time, breaking your code all the same, just in a more confusing way)
Also some obligatory Linux vs GNU/Linux comment. (and it's not like GNU/Linux doesn't ever change under your feet - see the glibc DT_HASH debacle)
But lossy-codecs job is to utilize psychovisual tricks to discard as much high-frequency information as possible, whilst remaining similar visual effects. If you increase the brightness in RAW and then re-encode the JPEG - more noise is being pulled up in the visual spectrum, therefor less of that information (filesize) is discarded.
For example, if you render Gaussian noise in photopea and export as JPEG 100% quality, it has 9.2MB. If you reduce the exposure by -2 it goes down to 7.8MB. That's partially because more parts of the noise are effectively black pixels, but also I believe because of the earlier mentioned effect.
Good for them, I cancelled my subscription simply because Linux support is so awful. It's impossible to watch in 4k, and even with 1080p you frequently get automatically downgraded to lower res bitrate whenever the window isn't focused. Absolutely daunting.
You know it's funny. Awhile ago I subscribed only to watch Stranger Things, I paid for the 1080 HD plan.
4K is clearly incentivized. Any how, I called to complain at the time. My opinion is the picture instantly got notably better when I tried standard HD again. There seems to be different degradations of 1080 and 4K.
Same, stopped there. One of those odd pieces where the author is completely full of themselves and hostile, yet somehow decries other people’s attitudes (“as attitudes have degenerated, I found the ability to blind people driving behind me to be a critical safety feature”).
I clicked on the link for the "Yuppie button" and confirmed that the guy is a nut. The amount of effort required to create and install a device that flashes all of your tail lights at a tailgater is not something an average person is going to do.
Yeah. I thought “dipshit blonde” was in poor taste; posting her name and address genuinely shocked me and I stopped there.
No doubt that driver inattentiveness leads to loss of many lives year on year. But publishing the personal details of someone you got into a car crash with won’t do anything to improve road safely.
It's possible, but my anecdata is that the four people who have run into the back of my car in the past ten years have all been middle-aged men distracted by phones.
Two Audis (one of them written off to the point it had to be lifted onto the breakdown truck with a Hiab), one Hyundai of some sort, and one bicycle.
The cyclist was the only one I felt in any way sorry for, because he did actually hurt himself pretty badly and obliterated his carbon wheel and forks, but he shouldn't have been dicking around with his phone while riding down a steep hill at what I can tell from his Strava trail was around 35mph.
At no time did my car suffer any more than a bit of scuffing and damage to the old tennis ball over the tow hitch to stop the grease getting on my trousers.
Wow, that's wonderful. There is a store that sells original Woodblock prints in Vienna, close to the Opera. Every time I'm passing by I take a few moments to look and reflect on those prints, it's great recognizing some on this website now.
> Arguments against proactive MRI scanning always seem to have a whiff of status quo bias to them
More and more European countries are currently adopting Lung Cancer screening programs. It's usually limited to people with a certain amount of cigarette-pack-years, but still gives the opportunity for driving more of the innovation you're talking about. I think the main challenge at the moment is that nothing in healthcare is prepared of looking at those scans effectively, a radiologist has full medical education + additional specialization - without effective procedures you'll never be able to provide full-body scans with any meaningful impact.
Hehe, I'm eagerly waiting for this one as well as I'd be extremely happy to replace some hack to run docker images with `systemd-nspawn` served from the nix store.
reply