I saw there's an option to match on a cgroup among nft meta expressions (but I've never tried it). It could be enough if you just want to add per-process firewall rules, but not configure an additional namespace with it's associated interfaces, routing/nating.
Yes. You could match packets based on username or even SELinux labels.
You could also set a special mark on a packet for each container and then filter based on that. The Internet is surprsingly very thin on nft resources. I spent a few weeks learning how to write them. Definitely, not for the average consumer.
It's possible but the way the connection is blocked is surprising. If you're blocking based on an IP you'd just drop the first syn and the client would never receive the syn-ack. If you're blocking based on the SNI you would be waiting for the first TLS client-hello, but in that case packet are droped before the client-hello is sent.
Indeed, it's right there in the packet capture screenshot. The ack has payload length 0.
I've debugged a lot of TCP/IP issues over the years but this one has me scratching my head. The author has done reasonable troubleshooting: tried from different devices and operating systems, HTTP and HTTPS, over wired and WiFi, and to different destinations. The common denominator is the wired network.
It can't hurt to reduce the MTU, but I see nothing in the evidence presented that this is likely to be the cause.
I once had a destination firewall blocking packets from Linux but not OS X and it turned out to be that Linux was an early adopter of ECN and the destination firewall rejected any packets with the ECN bits set. I've also had frame relay networks with MTU limitations, NICs with corrupted checksums, overflowing NAT tables, asymmetric ARP tables, misconfigured netmasks, and stuff I'm sure I've forgotten.
I would go for a 1u with redundant PSUs on each sides and with 4 hard drives in the front (the spinning kind, not those fancy nmve thingy) to counterbalance the PSUs.It should be pretty well balanced without being too heavy or big to handle.
Of course the only way to know for sure is to try, any donors ?
optical fiber ? it may cost a bit more than copper for the transceivers (is that still true nowadays?) but given the price of the hardware i doubt it's really an issue.
I wouldn't even call it a solution. If you have a trustworthy dependency that uses, say, net and fs APIs, and that dependency suddenly becomes malicious, the malicious update will still be able to wreak havoc without increasing its API use and triggering any alert. And as another comment has pointed out, if a dependency is allowed to use unsafe it can do pretty much whatever it wants. Ultimately you still have the same choices for each dependency :
- Trust it blindly
- Audit the code (and do that again for each update)
- Write it yourself instead
The last two can be time and resource consuming so you sometime have to choose the first solution.
Cackle can be a useful tool to (occasionally) raise alarms for when dependencies you trust blindly start using different APIs (so the trust isn't completely blind anymore). But it doesn't really solve the problem.
You could solve this with capabilities: make the main function not only take argv, but also a map of unforgeable tokens for the various sorts of possible “unsafe” actions the user wants the program to be able to do. Add APIs that can restrict these tokens (e.g. take the filesystem access token and generate a “access this directory and its children” token). Any code that wants to do one of these unsafe actions must take a token as a parameter and pass it to the standard library function that actually does the thing. (FFI makes this hard, but just prevent deps from doing that unless the developer opts in and also prevent deps from interacting laterally by requiring each dep to use its own copy of transitive deps).
This sort of capability-based approach to security would make untrusted code relatively safe to execute because the worst it could do without the explicit cooperation of the developer is an infinite loop.
My impression was that the SecurityManager was ACLs. I’m thinking more of capabilities as found in the E language and various protocols like CapTP. The idea is that there is no “ambient authority” in a program: to be able to interact with the outside world, you need to be have a token that the runtime guarantees cannot be created by any program. All the tokens would be passed to the main function at startup and then passed down the call stack explicitly to code that wants these feature.
The whole paradigm is to avoid needing to check permissions by making it impossible in principle to do anything you’re not allowed to do.
It's a neat idea, but you'd probably have to build it into the OS from ground-up to work. And then a whole ecosystem of development languages and tools built around it. Quite a lot of work to have something anywhere near as functional as what's around today.
I don’t think so, a language by default doesn’t really have any access to the environment (ignoring side channels like Rowhammer attacks) aside from access to memory and the CPU. Ensuring the security properties I’m talking about is mainly a matter of designing the runtime’s OS interfaces from the ground up with a capability model.
The problem with Cackle is probably that 99% of the time the dependency updates are completely reasonable and valid. It’s going to run into the ‘more noise than signal’ problem really quickly.
With these specs, I wonder if some countries military wouldn't be willing to offer them more money than they could ever make with deliveries... (At least on a per-drone basis)
Spend 5-10 minutes on twitter watching drone footage out of the Ukrainian war, both sides are getting a lot of work done with less accurate, smaller payloads.
The traditional M18A1 Claymore mine weighs about 1.6 kg total and has optimal effect to 50m in a 60 degree arc (potentially lethal to 250m I think - Ed: "moderately effective up to a range of 100m ... fragments can travel up to 250m").
Most of the time if you've decided to go the 'air superiority' route, then you're in a traditional war. So I feel that the cost-value factors will still favor dropping larger ordinance from much larger drones.
Have you watched any of the drone footage from Ukraine? They are dropping hand grenades and modified mortar shells into tanks from drones. Mortar shells have about 500g of HE. Highly effective.
I guess I was thinking about it from the point of view of a large industrial power fighting its equal.
Ukraine vs Russia seems more asymmetric. For instance, Russia can be an existential threat to Ukraine, but the positions can not be easily reversed since Russia has nuclear weapons. While they wouldn't want to deploy them, they'd rather do that than lose Moscow.
Asymmetric warfare makes use of a great number of things, which wouldn't be very cost-effective in a battle of equals. For instance all the insurgents that use IEDs to harass checkpoints, would probably rather use factory made air-craft delivered ordinance.
> I guess I was thinking about it from the point of view of a large industrial power fighting its equal
Human-in-the-loop ethical concerns aside: a highly industrial power can fully automate the entire process and massively scale up from individual-pilot controlled prosumer drones.
Imagine a high-altitude loitering spotter-drone that autonomously identifies any tanks with open hatches and tasks smaller multirotor drones to precisely drop small munitions. You may take out an entire tank battalion for less than the cost of a couple of traditional air-to-surface missile without putting your personnel in harm's way. Future wars will be horrifying for infantry and ground vehicles.
And yet Ukraine is stopped by old school mine fields... Well, slowed down considerably. It is almost as if everything is a trafe off with benefits and downsides.
Drones work until drone-specific AA is developed, and then it will be the same race we see between tanks and anti-tank weapons.
The drones don’t interact with the the mine fields, and in fact, are extra useful in this in this situation as they can fly over them. I’m not sure I see the trade off here.
Well, a drone doesn't help ypu a tiny bit it getting across the mine field. Without that, well, your counter-offensive stalls, drones or not.
And for now, anti-drone AA is difficult. But not unsolvable. Jamming, small caliber radar controlled AA guns. Point defense weapons can shoot down cruise missiles and even artillery shells. Applying the same principle at slower drones isn't that hard.
Your demands are completely unreasonable, a weapon platform can be extremely effective in its role and not win a war outright. Yeah drones aren't magically solving the problem of minefields, so what?
My point was exactly that: no weapon system is a silver bullet, including drones. And just because something is old doesn't make it less useful.
And I didn't make any demands, not sure how you woupd read that into my answers to a thread started with "dropping stuff from drones is an attack that cannot be countered". People didn't learn anything it seems, first tanks were obsolete, until Ukraine wanted every single one of them. Then modern AA made fighters and helicopters obsolete, only to be replaced by drones as the latest shit. Those arguments are just cheerleading whatever is en vogue and hyped.
Tanks being obsolete is… not clear. Tanks vs. western anti tank missiles and drones dropping grenades does feel like a terrible ROI but they are still useful. Russia doesn’t have these things at the same level of efficacy so tanks are perhaps more valuable for Ukraine to have.
Helicopters and fighters are in the same boat. They’re useful, but vulnerable and expensive. The thing about drones is they cost $200 to take out weapons that cost up to millions of dollars.
Drones are immensely helpful in getting across minefields. Being able to attack enemy positions across the field prevents them from being able to safely attack sappers trying to remove the mines.
It is much harder to stop a small drone attacking a mobile position than it is to establish a large AA battery that defends against missiles. Missile AA is for protected largely stationary high strategic value targets. Drone AA has to be for small tactical level targets on the go. Way harder.
It’s not an ultimate weapon. I don’t know why you judge it as if someone said it was. It’s just that small drones can be extremely effective against personnel and light armored vehicles. That’s why both sides have to use them.
This doesn't negate the comment that you are responding to at all. Drones have been most effective in defensive operations, often in concert with mine fields.
Offensive is much more difficult, as it needs to be coordinated with ground forces that can be impeded by mine fields. It is also easier for prepared defense lines to stop drones than it is for an offensive operation in the open to defend against them.
