lemmyvore @ lemmyvore @feddit.nl

Posts

15

Comments

2,750

Joined

2 yr. ago

keyloggers is because it allows an attacker to perform privilege escalation by recording your sudo/root password and automating an attack

So does putting a script called sudo in your PATH.

Keylogging is one of the lamest, most inefficient methods of attack. If you can run code on someone's machine there are so many other things you can do.

The fact Wayland has wasted so much time and complicated things so much focusing on a non-issue is mind-blowing.

The majority of users do not use such tools and should probably use Wayland.

Don't worry, this is not the only thing holding back Wayland adoption.

Or a docker image with Nginx Proxy Manager. You get a working reverse proxy, an automatically renewing certbot, easy to use UI, plus a working nginx install that you can use for serving static files, forward proxy etc.

Do you sandbox each and every process? Do you whitelist everything each process can do? Every file it can access, every which way it can use the network, every bit of CPU and RAM and hardware resource it can use?

If you don't do that, why do you want to impose upon me a complete block of inter-window communication, which I use for desktop automation, and which has basically zero security impact in the wild?

I don't mind Wayland having security features, but why are they so heavy-handed and non-optional? Things like firewalls, AppArmor, cgroups, they're all customizable. Why is Wayland all or nothing?

Again, if you have malicious code running on your computer it can do lots of things. It can access your files, the network etc. You have to keep an eye on security vulnerabilities all the time anyway, which thanks to FOSS is easier. You're pigeonholing on keylogging but there are lots of ways that malicious code can hurt.

Windows has chosen to go the route of allowing malware in and dealing with the fallout later. It didn't work out so great. UNIX and Linux have been on the side of not allowing malware in at all if possible.

If you want to use a system that restricts access to all apps to all resources all the time you can, but I think you'll find it very limiting and inconvenient. But it would be your choice.

In the meantime, if my choice is to disregard the purely hypothetical threat of keylogging, I should be able to do that, especially since breaking inter-window communication also breaks all desktop automation.

And that's why I don't use Wayland: it broken desktop automation and it won't give us a choice in the matter, for the sake of one, randomly selected, purported security issue.

X11 allows any app to keylog easily.

Yeah, any app that runs on your computer... at which point you have bigger problems than keylogging.

When's the last time you've heard of keylogging being a common problem on Linux btw?

It's not a big deal... for now, because most of the time when I limit DDG results I ask for 1 year back (for solutions that are sort of recent but not ancient).

I would never limit results to just the last week, and typically posts that are that fresh won't have enough accumulated knowledge so even if they pop up on the results they're not really useful.

Again, that's just my experience. I'm curious if others have similar ones.

The main goal should be having a thorough approach. People hear "firewall" and assume it means blocking things but it's really about having a comprehensive network specification.

If you mean the S24, the equivalent from Sony would be the Xperia 5 V. Has audio jack and sd card compared to the S24, Sony batteries last 2 days even after several years of use thanks to excellent optimization and battery care, there's almost zero bloat. On the downside it will only get 2 years of upgrades (until the end of 2025). Also you can't unlock the bootloader on US models if that's something you care about.

https://gsmarena.com/compare.php3?idPhone1=12773&idPhone2=12534

Keeping a port open if you don't want it open is bad practice.

Why even bother having a firewall then? I mean, why block any ports if you're going to open the ports for services anyway, and there's nothing listening on the others, right?

The point of having a firewall is that you start with DENY on all possible chains and interfaces, and you describe explicitly what is allowed to happen.

A firewall thus becomes a living specification of the networking rules for your server, the same way ansible for example describes the functionality.

If you're not willing to do it like that then don't bother having a firewall, there's no point.

Do not disable that docker feature unless you know what you're doing!

99% of users want it on. If you have an active firewall you want it to be restrictive, and you want Docker to open ports only as needed, and to keep track of container networks for you and to take down the permissions when you stop a container etc.

What clueless people do is disable this feature and then they make permanent rules that keep the ports open all the time, and/or attempt to keep track of rules by hand. The former is insecure, the latter is a hassle.

You should not have to open such a permissive rule. Like you've seen, docker will set firewall rules as needed if you have services that actually need to listen on the public interface.

If you've run that permissive input command on the VPS it's most likely not a good idea.

What exactly are you trying to do? If you're trying to use curl from inside a docker container that is not the correct way to achieve that. In fact you should not need to do anything like that, outside connections should be allowed (OUTPUT), and incoming collections (INPUT) should be allowed only if they're related to an already ongoing connection (look up the ESTABLISHED flag).

Any extra flag you can offer that would narrow things down would also be welcome. When you write firewall rules you should be as restrictive as possible. For example since this is curl you're probably going to connect to ports 80 and 443 so you can add --dport to restrict the ports to the OUTPUT rule. And you should specify the interface (in this case docker0) in almost all cases.

None of us knows!

There's a group of hardcore hackers that keep bringing it up and we're all afraid to ask.

PS: Kudos for biting the bullet.

You could also start by denying any outside connection to anything except private IP ranges for any docker container, and only allow it on a need to have basis.

It's not enough to rely on the the good will and savvy of whoever made the software, you have to make the restrictions stick.

Website hosting is still a thing. Not everything needs to be self hosted.

It will happen out of necessity once LLMs make search engines useless. Bookmarks and human-curated content will be the only way to find stuff.

It's already affecting small businesses worldwide, who aren't being discovered anymore by searches in their local area.

It's going to be a bit tough considering that the Chromecast protocol is being used by pretty much every Android app.

I'm not aware of any open source app that can pose as a Chromecast on the network and/or convert the protocol to DLNA, but maybe I haven't searched enough.

Means they'd like to replace cookies with something proprietary that they control.

Immich recently had a bug where it would delete all the photos if you remove a gallery. It has breaking changes and API changes all the time. Why? I don't know. You do NOT need to break the API every other minor version, it's super dumb.

That makes it impossible to use it with other users because I can't control how and when their mobile app gets updated, which means at any given time I have no idea if their apps will work with the server version. And when they do work, they're buggy.

You can use it just for yourself if you're very careful but it's not something I can offer friends or family and promise it's better than Google Photos or iCloud. Not if it doesn't work half the time and may delete their photos every once in a while.

A simple alternative is to use a sync app to upload photos from a person's phone and then use a reliable (doesn't break all the time) photo webapp to let them browse them. They can still manage their photos locally, and use other services, and other backups and so on, they just have an extra backup + viewer.

OK but that just means the offer for this particular type of app sucks. It doesn't make Immich good.

It's not really uncommon in the selfhosted space, there are some huge gaps. Try finding a multi-account email webapp for example, or a CalDAV/CardDAV webapp.

It does need regular maintenance, as highlighted in every single stable update announcement.

If you're talking about "Known issues and workarounds" those aren't caused by Manjaro, they're issues that crop up with various packages. The forum attempts to crowdsource fixes as part of Manjaro's mission to make it easier on its users.

It's a great resource and it can be used by people on any Arch-related distro (and potentially other distros as well). I wish more distros would do this.

It is absolutely not stable (as in Debian Stable or RHEL or SLES stable) as things are moving quickly.

Well it's still a rolling distro with Arch heritage. It's as stable as you can make Arch. Which is quite stable in the sense that a Manjaro install won't stop working out of the blue (I can attest to that personally, going on the 5th year as a daily driver). And they've gone and added Timeshift snapshots as default so if you mess something up you can simply restore a snapshot, which takes care of user-related tinkering as well.

Okay, almost-semi-regular then.

Not sure I understand your point about the updates (or the "almost-semi" thing). What does it matter if updates come after 13 or 17 days? Is it important to you to be exactly 14 or what?

AUR creators, on the other hand, are overwhelmingly Arch users who builds their scripts targeting an up-to-date Arch system.

10% of AUR packages are abandoned. Another 20% have never been updated after the initial release. Only 35% have been updated within the last year.

Anyway, it doesn't matter. AUR "packages" are recipes that either compile packages from source or download binary releases. Both methods are very resilient and don't care about delays of a couple of weeks.

While you can in theory run into an AUR package that was just updated to require something that was just added to Arch the chances are extremely small. It's hardly a common problem.