systemd. dbus, udev, etc are sometimes a really bad idea

Posted May 4, 2016 23:28 UTC (Wed) by dlang (guest, #313)
In reply to: systemd. dbus, udev, etc are sometimes a really bad idea by rahvin
Parent article: Devuan Jessie beta released

quoting myself

> In theory, this won't make a difference, because your firewall is someplace that it physically protected...

> "In Theory, Theory and Practice are the same, In Practice they are not"

especially in a home or small business, you need to defend against people who don't know enough to not plug things into a device that you cannot practically lock away.

In datacenters, it's belt-and-suspenders protection. The type of thing that if you do it, you never needed to, but if you skip it, it would have saved you.

> That's beside the fact that you can blacklist certain hardware including everything that's not already there such that no driver or device will be loaded.

Isn't it easiest to just disable auto-probing rather than blacklisting the world?

to post comments

systemd. dbus, udev, etc are sometimes a really bad idea

Posted May 5, 2016 0:26 UTC (Thu) by pizza (subscriber, #46) [Link] (13 responses)

> especially in a home or small business, you need to defend against people who don't know enough to not plug things into a device that you cannot practically lock away.

What exactly is the threat vector here?

Maybe I lack sufficient imagination, but all I can come up with is that if someone already knows enough information about your firewall box's software configuration to know how to pwn it by merely getting someone to plug in a particular USB widget, then it's far too late; someone has already pwn3d you.

Meanwhile, If someone's going to break into your [home]office to go after your specific data (as opposed to something more generally valuable, like cash/jewelry/etc), they're going to just take the equipment with them. Or maybe image the drives if they want to be sneaky. Or plant recording devices to get your login information if they want to get sneakier. Or just beat it out of you if they're in a hurry.

> Isn't it easiest to just disable auto-probing rather than blacklisting the world?

It seems to me that the most bang-for-the-buck approach is to properly secure the door to your server/telecom closet and be quite stingy with the keys.

systemd. dbus, udev, etc are sometimes a really bad idea

Posted May 5, 2016 8:35 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

What exactly is the threat vector here?

Come on. Have someone revoked your Google access? First link I've found. Second one. Third. And more recent.

Some of these could be prevented by refusal to talk to some random hardware, some couldn't, but the general flaw is always the same: it's always the battle of "security vs convenience" and security rarely wins.

systemd. dbus, udev, etc are sometimes a really bad idea

Posted May 5, 2016 10:38 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

What do any of those examples have to do with an attack that requires *physical* access to your firewall? And, going back to my point, an attack that, in order to be successful, requires knowledge only obtainable if you have already completely compromised everything already?

systemd. dbus, udev, etc are sometimes a really bad idea

Posted May 5, 2016 19:45 UTC (Thu) by dlang (guest, #313) [Link]

so you say that people should not be able to defend themselves against an attach scenario that you deem invalid.

Why should your judgement trump everyone else's?

systemd. dbus, udev, etc are sometimes a really bad idea

Posted May 5, 2016 8:47 UTC (Thu) by dlang (guest, #313) [Link] (9 responses)

if you want me to spin scenarios, preventing your <insert non-technical relative> from taking a USB stick they picked up off the sidewalk and plugging it into the AP in the living room and having it hack your firewall.

not all firewalls live in a "server/telecom closet"

In small businesses, the router/firewall probably lives on the owner's desk in the back office.

You need to be substantially larger, or a computer-centric business to have things organized enough to have your servers in a dedicated space rather then just on/under someone's desk.

plugging things into servers

Posted May 5, 2016 10:17 UTC (Thu) by itvirta (guest, #49997) [Link] (8 responses)

If they're bound to plug random attack sticks in, they'll just do it with some application server or a workstation
even if the firewall is locked away or ignores any plugged-in devices. Those probably have easier access to any
sensitive data you may have, anyway, so I'd say the main problem is the fact that someone can/will plug nefarious
devices in.

Sure, the firewall is special in that it could block any traffic going outside, but can you do any work then if WWW doesn't work?

plugging things into servers

Posted May 5, 2016 10:56 UTC (Thu) by pizza (subscriber, #46) [Link] (7 responses)

> If they're bound to plug random attack sticks in, they'll just do it with some application server or a workstation
even if the firewall is locked away or ignores any plugged-in devices. Those probably have easier access to any
sensitive data you may have, anyway, so I'd say the main problem is the fact that someone can/will plug nefarious
devices in.

My point exactly. The firewall is nowhere near the most attractive target for clandestine nefarious activity, and not worth even bothering with if the attacker is willing (or able) to be overt about attacking you.

plugging things into servers

Posted May 5, 2016 13:13 UTC (Thu) by jrigg (guest, #30848) [Link] (6 responses)

> The firewall is nowhere near the most attractive target for clandestine nefarious activity

So the fact that it carries all traffic in or out of the internal network doesn't it make it attractive?

plugging things into servers

Posted May 5, 2016 17:51 UTC (Thu) by edgewood (subscriber, #1123) [Link] (5 responses)

For someone with physical access to the computers of a personal or small business (ie, an entity that doesn't have a "server closet")? What's the motive of someone who has that physical access to the location, but doesn't want to steal, clone, or subvert the computers with the actual personal or business data on them?

plugging things into servers

Posted May 5, 2016 20:37 UTC (Thu) by jrigg (guest, #30848) [Link] (1 responses)

> What's the motive of someone who has that physical access to the location, but doesn't want to steal, clone, or subvert the computers with the actual personal or business data on them?

Surveillance?

plugging things into servers

Posted May 5, 2016 22:06 UTC (Thu) by dlang (guest, #313) [Link]

take control of the firewall so that they can get in remotely later to do other stuff??

plugging things into servers

Posted May 6, 2016 14:06 UTC (Fri) by itvirta (guest, #49997) [Link] (2 responses)

Apart from the boring legal stuff like doing the work you are paid to do, one could
- steal everything that looks valuable, including the hardware
- burn the place down just out of spite
- analyse traffic passing through the firewall to see how much they use Facebook from work. The connections are probably encrypted,
so you can't get anything interesting about the contents. Unless there's a TLS-decrypting middleman on the firewall already,
but people who worry about udev on their firewall don't strike me as the type to do that...

plugging things into servers

Posted May 6, 2016 16:17 UTC (Fri) by jrigg (guest, #30848) [Link] (1 responses)

One person's paranoia is another's sensible caution. Maybe we should just leave it there.

plugging things into servers

Posted May 9, 2016 21:59 UTC (Mon) by pizza (subscriber, #46) [Link]

I don't disagree, but either way it strikes me as wise to perform a risk assessment.

There's a very real cost to implementing security measures, and one should focus on the measures that mitigate the attacks most likely to occur, and the ones most costly to recover from. (And don't forget the "from what/whom" question too..)