• 0 Posts
  • 120 Comments
Joined 1 year ago
cake
Cake day: July 9th, 2023

help-circle
  • Ok, fair point on the capital D, I must have read it like that years ago and it stuck. I shall have to make an effort to unlearn it.

    As to the rest, systemd has been a constant thorn in my side ever since L. Pottering published “Rethinking PID 1” back in 2010 or so. I found, and still find, that most of the assertions and actions in that document either don’t really hold, or just aren’t really relevant. Basically it’s trying to solve a problem that really wasn’t an issue in the real world, and does so in such a massively overbearing way that everything actually becomes more laborious than it otherwise would be. From my perspective it’s an unnecessarily complex and poorly architected attempt to answer a need that was better served in different ways. That it’s become a near mono-culture is deeply concerning.

    I’ve also run into all sorts of awkward edge cases and misfeatures over the years, from the automounter that occasionally didn’t to race conditions that only manifest at the worst moments, none of which would have occured had the basic tenet of “do one thing and do it well” been followed. The extreme verbosity of the configuration, and unnecessarily large number of places it can be spread just serve to make it even more unpleasant to deal with compared to the simplicity of init scripts, crontabs and the like.

    The sad thing is, there’s undoubtedly some good ideas buried in it, but they could all have been implemented much more lightly and in a way that worked with the rest of the ecosystem rather than fighting it. Things like starting daemons in what is essentially a repeatable sandbox, or being able to isolate logging per service. They could, and had both been implemented already, but systemd has a real “not invented here” problem, so everything was built again, with all the attendant bugs, and design issues that inevitably brings.

    Ultimately clients pay good money for me to look after their systems, systemd or not, so I probably shouldn’t grumble, but I miss the days when Linux was a clean and elegant system, without this multi-tentacled thing sitting on top of it.


  • SystemD is far too much of a poorly thought through mess to have anything like a sane GUI configuration, it doesn’t even have a sane textfile based configuration. We’re going to have to wait fir SystemD to crumble under it’s own weight and be replaced with multiple, simple, cleanly designed components before we have any hope of a sane config again. Sort of like we used to have before a certain someone/some company (depending on how conspiratorial you’re feeling) decided to come along and muck it all up.

    /rant

    Thank you for coming to my Ted Talk Rant. You may gather I dislike SystemD quite a lot.





  • Vim is running as you, rather than root, so you wont be able to edit other files as root, and any rogue plugins wont be able to either, which is good.

    Sudoedit has various guards around what it’ll let you edit, in particular, you can’t edit a file in a directory you already have write permission on as doing so allows the user to bypass restrictions in the sudoers setup (there’s more detail in their issue tracker. If the directory is already writable though, you don’t need sudoedit anyway.



  • It’s not the buyer saying “I owe you”, but the issuer of the currency (actually, usually just the notes, coins are considered to have value). The first person/entity to get the note gave, or promised, the issuer (usually the central bank) something of value, and the issuer gave them a token (note) saying the bank owes the holder of that note a certain amount of value. The recipient can then trade that note freely, as can future recipients, in the knowledge a vendor will accept it for its face value. So, yes, you’re trading debt when you use money, but it’s the bank’s debt to the holder, not the debt of the buyer.

    Typically the bank issue money when someone takes a loan, i.e. promises that they will pay the bank the value of the loan plus interest.



  • Pre-ordering something would usually cause a $0.00 transaction to confirm the card details are valid. It would be a ‘pre-auth’ transaction where the merchant reserves an amount on the card for payment at a later date, when they ship the item. If a fraudster makes a pre-order they xan validate that the card details are valid, then cancel the order, usually leaving the victim none-the-wiser. In your case, the bank noticed the transaction and notified you, but that seems to be rare. Once the fraudster knows the details are valid, they can sell them on.

    It’s just a theory, and unless your bank and Blizzard work together to track the transaction, why it happened, and who instigated it, its going to be difficult to get to the bottom of it.




  • This is fundamentally true. However it is possible to limit the bandwidth of data the employee can exfiltrate.

    That’s fair, but the OP was talking about having the sensitive data directly on the laptop, which rather limits your ability to control access to it, and why I was suggesting keeping the data on a server and providing access that way, so limits can be put in place.

    Assuming a privileged employee suddenly becomes a bad actor.

    Your threat model probably isn’t the employee who suddenly goes rogue and tries to grab everything, but the one who spends and extended period of time, carefully, extracting key data. As you, the former can be be mitigated against, but the latter is very much harder to thwart.

    But I couldn’t for example download our entire customer database, I could get a specific record, I could maybe social engineer access to all the records of a specific customer, but there is no way I’d be able to extract all of our customers via an analog loophole or any standard way. The data set is too big.

    That’s well set up, but, whilst your competitor would love the whole database, what they’re really interested in is the contact details and contract information for maybe your largest three customers. When the dataset to extract is small enough, even quite advanced rate limiting can’t really help much. Making sure no one person has access to all of the most valuable data is a good start, but can present practical problems.

    And this is what you are trying to limit. If you trust your employees (some you have to), you can’t stop them from copying the keys to the kingdom, but you can limit the damage that they can do, and also ensure they can’t copy ALL the crown jewels.

    I think we’re basically saying the same thing. The OP talked about putting all the sensitive information on the employee’s laptop, and that’s what I was trying to steer them away from.

    In the past I’ve been asked if we can provide our developers access to pull the full source tree, but not copy it anywhere, and, to quote Charles Babbage, “I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.”

    I enjoy the security side of sysadmin work, but I find it rather depressing, as all you can hope to do is lose slowly enough that it’s not worth attacking you.


  • I agree that you should assume you’re being monitored, but, while that helps against malware type exfiltration, it does little to stop someone who is determined to exfiltrate the data as there are a myriad of ways to do so that aren’t possible to monitor, such as simply taking a video of the screen whilst displaying the information.

    Ultimately, the company has to trust the employee or not give them access to the sensitive data, there’s no middle ground.




  • I had not considered the concept of an army of bipedal, running, neurotoxin coated, suicide frogs, and now that I have, I intend to stay far away from amphibians, just in case. I still think they should each sport a set of human like teeth though, just to really drive the point home.

    Kudos on ‘Kermitkaze’, that gave me a good chuckle.


  • The issue is you’d really need an evolutionary pressure for them to develop that attack behaviour. It could be defensive, but jumping on the thing you’re trying to fight off is a rather bold strategy, especially when the results aren’t instant. Alternatively, it could be an attack behaviour, allowing them to take down larger prey. Thus just leaves the issue of how the frog would consume its meal. They could probably evolve to swallow smaller prey, but the obvious adaption, which I think we’d see in this case, would be for the frogs to evolve teeth.


  • Sometimes their emotions have gone so far past reasonable that the first thing you need to do is bring them back to the point you can actually reason with them. After that, yes it’s really vital to take their emotions seriously, they need to understand them and trust that the people around them will take them seriously, but they also haven’t yet built the skills to moderate their own feelings, so sometimes you need to add those externally.