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.
Be cautious of doing this with security sensitive files. When it copies the file and gives you ownership, any sensitive data in it is exposed to any process running as your user id, and and temporary fil£s the editor creates may also contain the sensitive content and be owned by you.
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.
Is there any chance your new card details got leaked from somewhere you used them? Using stolen details to sign up to something like that and, say, making a pre-order, would be a good way for a crook to validate them without a transaction appearing on your statement.
If it's not that, then Blizzard definitely have some awkward questions to answer. Good luck!
Whilst it's quite possible they're up to no good, it's also possible that someone is fraudulently using your payment details in Irvine to create a new Blizzard account. It sounds like your bank already blocked your card, which is good, but they may also be able to block payments to Blizzard when the card is unblocked.
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.
There is a fundamental issue with this approach: the rogue employee has already copied the data to a USB drive by the time you try to wipe it.
If the data is confidential, you either need to set up standard disk encryption and trust the employee, or not let them access it in a way it can be bulk copied. For instance, might it be possible for them to use a webapp that you control access to or a remote desktop type setup?
Very gouda. You deserve a rind of applause for that one.
Spray-paint a polar bear orange and stick a mane on it. Confusing and scary.
Do you swing them to and fro?
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.