That's like saying users have no right to push against certain features. It's like saying Windows Recall was always ok and there was never any reason to demand it not be installed. The only difference is one can choose to use a different browser easier than they can choose a different OS.
You're right in the sense that practicality and consent are orthogonal issues. There are probably stronger arguments to complain about a feature than the disk use.
> The only difference is one can choose to use a different browser easier than they can choose a different OS.
I'm not even sure that is actually true for most people. If you mainly work in the browser, which many do, then you can change the OS under it without impacting the user too much but change the browser and there will need to be much more to adapt/relearn.
You use eID when explicitly interacting with a govt entity or bank or otherwise similar institution because you have to and want to prove who you are. Yes, I do want to prove who I am when I file taxes, vote or want to start a business...
You don't use it when just browsing randomly on the internet. You don't use it to buy games on steam. Your computer isn't forced to store it because a law arbitrarily says so.
Why not, seems to be made exactly for this purpose if you look at the "‘Age over 18’: true" flag. What's bad about that solution?
> The technical solution for an EU age verification app is privacy-preserving, open source and user-friendly.
> First, the user downloads the app onto their phone and sets it up by certifying their age.
This can be done with a biometric passport/ID card, a national eID (e.g. national ID Card or other electronic identification mean), a pre-installed third-party app (e.g. a banking app), or in person (e.g. at the post office). Only the information confirming that the user is over the age will be saved in the app. No name, no birthday, or any other data is saved.
> After completing this step, the communication between the app and the provider certifying the user’s age (e.g. eID, third-party app) ends. No further data is exchanged.
> The app is then ready to be used online. When an online platform asks to verify the user’s age, the user can use the app to communicate they are over a certain age (e.g. ‘Age over 18’: true) to the platform.
The EU app still requires that you let them violate your privacy in exchange for a batch of about 30 easily trackable tokens that expire after 3 months. It also bans rooting/jailbreaking, bans third party operating systems like GrapheneOS, and requires that you install Google Play Services/IOS equivalent for "anti-tampering".
I don't disagree with random browsing. I do use it to buy games on steam as any online purchase on my card uses it. And my computer doesn't store it, my phone does.
if it's done by the government, what prevents the goverment to not allowing opposition members to access social media? I think social media and porn are harmful for children but still
I am confused. Is this saying that if you don't have access to `cat`, instead of `cat /path/to/input-file` you can use `base64 /path/to/input-file | base64 --decode`?
Or is it saying that `base64 /path/to/input-file | base64 --decode` can bypass read file permission flags?
The first thing. Invoked processes inherit the permissions of the user who invoked them (unless they have the setuid bit). It's just in case you land access to a computer which has all the standard Unix tools disabled to stop attackers from lateral movement.
Put your meagre and limited resources on keeping them outside the hatch.
If they get through the hatch, that is where you fucked up, not that you didn't remove every conceiveable command from yourself should they get through. If they can remotely get some program to execute a shell, they can quite conceivably get the same program to just read them the files directly by writing different shellcode. Running a shell is just a convenience for them.
The number of setups that are insecure enough to allow remote shells by arbitrary attackers, but are secure because you disabled /bin/cat once they get in, is zero.
Security is done in layers. Yes, we do our best to keep the adversaries outside the proverbial hatch. But even inside the hatch, the principal of least privilege is important in reducing the damage of attacks.
Typically you do things like this to either work in restricted envs (distroless) or to evade detection logic. It's not about bypassing a boundary, it's about getting things done in the env you have available.
But you wouldn't, or shouldn't, take a patchwork approach to it.
If the software you're trying to secure actually depends on a full, working, intertwined unix system... you leave that as it is. You can certainly try reducing a process's access to the system it's running on (whether that be by containers, jail(8), SELinux, AppArmor, etc.), but you don't go around deleting 7-zip or your scripting languages or compilers, on the off-chance that'll thwart a hacker.
Sure, you can say, "defense in depth", but if you have one layer that's actually holding up the security guarantees, and a second layer that is largely ineffectual (haha! I removed /bin/cat, now they can't read files! oh and base64 too... and yyencode... and... and... and...), I wouldn't waste much time on the second layer.
I think you have the wrong end of the stick. The OP link is a resource for when you do get access to the processes environment which has already been reduced via containers, jails, or what have you.
If the environment is already restricted, but the process has, for example, access to the base64 tool, here's how you can use that to do something you otherwise aren't able to.
I can't read the original article because Github is having a very bad day, but I don't really understand the attack model here.
If a process has access to any tool that isn't statically linked, the process already has access to ld-linux.so and can therefore execute any binary it has read access to. "restricting access" by enumerating the binary paths a program can execute is not a very useful restriction by any means.
The original article is a list of ways to achieve certain features (ie, reading a file) when you don't have it natively (ie, no cat, but for some reason, base64).
> execute any binary it has read access to
Maybe I'm missing something, but in these restricted environments, why would the system have read access to binaries it doesn't need or use?
It's the former. Not bypassing permissions but in shells that might be highly restricted to just a couple commands. Like others have said, very very common in CTFs.
If there's a file your user does not have read access to, but you have the ability to run the `base64` binary as root, you can run `base64` as root, (thus encoding the file contents as base64), then pipe the output to another base64 process to decode the file contents.
So yes, the end result is just `cat` with extra steps.
I just grabbed one of the examples there which was readable and didn't require the reader to know all the extra flags passed. One that would illustrate the purpose of the website. One that Linux newbies who read the question and further answers here could follow along with. Not one that tried to be optimal.
The first thing I tried to do is resize that rectangle in the default diagram... and the resize handles do not affect the height, only the width. What is this "better" than?
> It points out that the compliant subjects who delivered the shocks weren't always following the procedure they were given perfectly. Which is, of course, expected, since people in general don't follow instructions 100% perfectly all the time
The article quantifies the amount of rulebreaking. The article actually compares rule breaking across participants and notes that those who were better at obeying the instructions of the experiment are the ones who refused to continue till the end.
The article doesn't invalidate the milgrim experiments. It claims that the interpretation from traditional literature is possibly wrong.
Yeah one of the take-away interpretations I’ve always heard of it is the implication that the deferral to an authority figure led people to conscientiously proceed with administering fatal shocks. But this additional detail suggests that conscientiousness is actually negatively correlated with following through to the point of ethical compromise and it is, in fact, the less conscientious people who were rushing to just do what was asked of them.
This does suggest that subjects who are bought into and understand the purpose behind what they’re doing, and are attentive to how the specific tasks they’re doing tie into the bigger picture, are more likely to be actively engaging their judgement as they go. And subjects who are just trying to follow the tasks as given to them are sort of washing their hands of the outcomes as long as they’re following the directions (which is, ironically, causing them to fail at following the directions too).
That’s my feeling when reading nixos forums. People are willing to help but don’t realize how little newbies know about nix when asking for help. The first month of nixos was a massive uphill climb for me, and that knowledge doesn’t stick well because I get to interact with nix every few months to tweak things, not weekly or daily.
It’s a solid os, and I’m enjoying it, and I love that I can’t break things while tweaking. But the docs are and discussion threads are not written for beginners (it’s really hard to write for beginners).
You're right in the sense that practicality and consent are orthogonal issues. There are probably stronger arguments to complain about a feature than the disk use.
reply