Never tried, as I've always punted the OVF/OVA files manually, but don't think it would do well with managing cluster or datacenter objects. Even backing stores isn't a concept in VMWare workstation (as it just uses the OS filesystem for that.)
Thankfully, not much has to be done to spin up a new VM, less if one uses some top tier abstraction utility.
Those days are long since past. Most datacenters tend to have iLO networks, ability to remotely power up/down equipment, extensive monitoring, decent switches, so the only thing SiteOps has to do is plug the cables into the proper ports, and everything is done from remote. The days of walking around with a CD and/or an external hard drive to reimage a PC are long gone... long since replaced by PXE for hardware, or templates and provisioning servers for VMs.
Only problem with NoDak is that if it gets snowed in, some type of outage can take days to weeks to get fixed if the weather is bad, and with temperatures well into the negative 40s, it takes specialized equipment to fix things. Texas and Georgia have their problems, but generally, the worst one encounters are ice storms which make an area impassible for a few days, and those are relatively infrequent. The occasional snow is manageable.
Well, the absolute worst are twisters... but that's what insurance is for.
I tend to rotate between FF and Chrome for general Web browsing, although I wrap both with sandboxIE pointing towards a different drive volume [1], or I put the browser in a VM. This way, no matter what type of supercookies are saved, they get dumped. Of course, this doesn't help with browser fingerprinting, but there are other ways to deal with that.
Firefox can be well configured with add-ons to limit the scope of what can be done. No ads, Javascript, Flash, social media tokens, all easily selected per site. To boot, it keeps its security keys and passwords in a separate stash, which can help if some program decided to add its root key into Windows's key stash in order to MITM SSL transactions.
[1]: I've had malware nail the browser and totally barf on the filesystem, so having the sandbox on its own drive volume allows you to just format it for cleanup work.
I still don't get why VMWare dropped the client around ESX 5.0. The client definitely doesn't have the features of the Web client... but it worked quite well.
Looks like I might have to do with VMWare what I do with some older embedded appliances that require Java (and break on any new Java version), and that is to have a VM set up on a separate cluster (to protect against chicken/egg scenarios) whose sole purpose in life is to be for logging into vSphere.
That, and be able to do vSphere command line work, so the only tool that is needed would be SSH if it came down to it.
IIRC, Windows 8 and newer have this as a feature. However, I wind up using WS 2012 R2, where if one uses the MMC panel, BitLocker will ask you to store or print a recovery key. You can turn on BitLocker manually with "manage-bde -on x: -free" so it encrypts, then add protectors (passwords, recovery keys) later on.
Best recovery protection I've found is to copy the recovery key text, toss it in an offline PW manager, check to see if you can unlock the volume with the key, and go from there.
Of course, in an enterprise setting, this is moot -- just have BitLocker stash the recovery keys in AD, or push a data recovery agent.
It may not be much assurance, but one of the head devs of BitLocker did state that there are no backdoors in it. Does that mean there are? Game theory might apply:
If there are none, life goes on. If there is one, it will get discovered, BitLocker tossed out the window by every company in the world, replaced with something that is vetted like TrueCrypt or its descendants.
Plus there are levels of law enforcement. Interpol/FBI is one thing. The local HOA trying to be nosy and use a civil action to get into someone's machine because they think someone had five guests when the limit is four... not so much. If there were a backdoor, the hand wouldn't be tipped unless it was a high value target.
As for a recovering a MacBook's data, there are a number of variables involved. If someone (the previous employer) had access to an admin user, they could easily slip in a recovery key. Then, even though the key can't be used at boot time, the MacBook can be booted via target mode and the drive mounted on another Mac using diskutil.
If the MacBook was completely independent and wasn't compromised via the network, it seems quite dubious that someone's employer could seize their computer, take it to a local Mac store, and a magic button be pressed to decrypt it. If this were so, there would be a hue and cry from MacRumors to CNN about this.
Not to say this impossible, but it falls along the lines of improbable.
I hope this is the case, and I'm proven brain-dead wrong. MS hasn't really pulled any real "fast ones" recently. W10 looks like it will be the next Windows 7 or XP.
As for OS releases, MS's real interesting OS release will be Server 2016. I'm guessing MS is going to wait and see what bugs pop up with W10, get them fixed before WS2016 goes out the door (which is a wise move.)
WS2016 is (for me that is) the one to watch, especially the added virtualization and container capabilities. I wonder how many places will be using the Docker capabilities once that gets out onto servers.
I think everyone reading this is has been in that boat sometime or another. The only thing that might have helped was to run a wbadmin backup of your personal machine (at least the hard drive with the Windows partition) so you can boot OS media and reload the entire drive fairly quickly if you encounter any bumps.
I'll just be happy with -any- modern reactor technology. Right now, if I were to throw a car analogy out there, people whine and gripe about how unsafe and terrible Studebakers and Packards are, without realizing that nuclear technology has progressed 70 years since then.
New gen technology is a lot safer, intrinsically. Come a scram, rods fall down into the core, instead of being pushed horizontally. Gen IV designs are a lot better at getting the most out of every fuel rod, so waste is lessened.
The US can easily handle its power needs. Thorium reactors for base power, solar for peak, high capacity batteries for transportation, and Audi's synthetic diesel fuel for everything else. This is more of a "won't", a political will problem than an actual "can't".
In the past, there were last minute "gotchas" which MS tossed in right before a build went RTM. In the antediluvian past, it was removing direct MS-DOS access in Windows ME, with XP, it was the Secure Audio Path (which was a DRM stack which required all audio drivers to be signed, in order to prevent programs like TuneBite from existing.)
I wonder what is going to be tossed in at the last minute. Hopefully nothing too headache-forming.
This. This is how to fix the issue for the long term stability of the EU. Write off the debt, let Greece pick itself out of the mud financially by itself over the next ten years, then start doing business all over again. The money gained from doing this will more than make up for the lost debt.
Right now, there always needs to be the consideration of what happens if Greece gets too unstable. If people start starving and the government is unable to provide basic infrastructure needs, then Greece will never be useful to the EU, even in the timespan of decades. Even worse, if the people start revolting, Greece could have its government overthrown and a new rulership installed that could be extremely hostile to EU interests.
Even though it isn't the same conditions, what happened in Iran comes to mind. Once people realize they have no economic future, they can latch onto anyone who looking for political office, and is a brutal firebrand who can promise them the world. Germany in the 1930s also comes to mind as well about what happens when other countries are too heavy handed in an economy.
This. I can drive 10-20 minutes, or spend 2-3 hours dealing with the buses, and a half mile walk between bus stops.
If there were buses in my neck of the woods that has a usable route, and didn't have 1+ hour gaps on the schedule, I'd definitely use it.
In fact, when I lived on a university bus line, and my work was near the university, this was an idea. Hop the bus (which came every 5-15 minutes), spend about 30 minutes for the ride, and be done with it. My car sat unused for months.
I just wish the US had more usable public transportation systems. As the parent said, a 45 min commute in rush hour sucks, but a one hour layover at a bus stop, as well as dealing with buses which are the living room, bedroom, and bathroom for the city's homeless, makes trying to bus it not worth the bother.
The ironic thing is that before DES and PGP were common in the early 1990s, the most common encryption utility on UNIX was the crypt (1) command [1]. This is based on one, 256 element, rotor, rather than multiple rotors with just the alphabet on them.
[1]: This is different from crypt (3), the password hashing algorithm.
That's the problem. Java consists of a ton of moving parts which get lumped into one concept:
1: The Java language. 2: The Java bytecode. 3: The JVM/JRE. 4: The JDK. 5: The Web plugins.
The Java language is decent. It is arguably the modern day BASIC, where it is fairly easy to get a "hello world" program, and has decent functionality as a general purpose language.
The Java bytecode is also robust. It would be nice if it were more like.NET's IL, where one can use any language of choice, and the compiled output winds up being bytecode, separating the language from the compiled code... but it is what it is.
The JVM/JRE is a headache-maker. I've seen AIX systems with 10-15 different Java executables, all in various sundry directories. Similar with Windows, with some programs using their own JVM, and multiple JVMs present systemwide. Only real answer is to have a VM dedicated for handling interacting with a Java website (usually an older appliance) that has the right JVM in it.
The JDK is not really an issue, but it is lumped in with Java.
Finally the Web plugins. As is stated on/. and other places, the most common vector for intrusion are compromised browsers or browser plug-ins. This will continue to bite us until stronger isolation is put in place, similar to IE's low security mode, but with true filesystem isolation and separation of browser instances, so a compromised window/tab can't infect another.
Main solution with dealing with Java is virtualization or containers. Serverside, it is extremely useful, but for applets, its time is long gone.
This is what VMs are for. There are appliances (older Sun disk arrays for example) that not just require Java, but only work with one version of the JVM, and will just throw exceptions and crash if one uses the latest version.
So, to interface with the legacy controllers, a browser and that correct Java runtime go into a VM and when it is done being used, it gets shut down and rolled back.
The answer to "What, if anything, should we block" versus "What, if anything, should we allow" is "it varies":
Scenario 1: Receiving. Give the guy a Citrix or App-V console into a machine that can browse the Internet unfettered, but doesn't allow files to be transferred to the internal machine. Now the user has access to websites, there is something substantial keeping the actual machine from being compromised.
Scenario 2: Finance. Again, these machines are touching sensitive data, so they, by themselves, don't see the outside world, but the user can always use a VDI implement to browse the web, making the isolation a non-issue.
Scenario 3: General company (dev, QA, sales) use. The above in reverse. Allow traffic out, have a good IDS/IPS in place (this should be in place everywhere, but especially with this), and stick the real sensitive stuff behind a RDP firewall, or a "hop box". The user can manipulate the data, but malware on their machine will have a hard time (though not impossible) to grab the entire database for upload to a blackhat's site.
Scenario 4: Point of sale registers. These have no reason to be connected to the outside Internet, other than through a server for credit card validation.
Of course, these are generic, off-the-top-of-my-head scenarios, but there is no one size fits all solution, other than that it helps to have some type of VDI for separation of data.
The EMC Isilon is a cluster of FreeBSD nodes with completely customized filesystem on top. All the nodes are connected to each other by Infiniband, and redundancy is built into OneFS.
I'm visualizing this as someone adding FPGA cards to Isilon nodes, and installing SSDs instead of the usual HDDs in the array. Innovative, but this isn't revolutionary by any means.
Success might be model and even ROM specific. I did the manual install of the framework on a 5.x ROM with a HTC One M8 with default ROM... and it promptly bootlooped.
Am in the same boat. I had to roll back to 4.x just because I rather have XPrivacy than the latest gewgaws and UI.
The acid test of privacy is running Yik Yak. If you like a few posts, delete the app, and reinstall it, without it showing you your old yakarma score, then you did the job right, because that app does a lot of stuff in order to permanently ID a device.
Juice Defender is another app along these lines. It is mainly intended for dealing with prolonging battery life by turning off the data and Wi-Fi options, only turning them on at selected intervals to allow mail to be fetched.
Titanium Backup is good for disabling apps, even if they live in/system, and are not able to be turned off by normal means. This is a must have app, since it not just can back up, but can use reliable encryption, and back up the encrypted files to a cloud provider.
This isn't programming, but in IT, I worked at places where they would have auditors randomly go around and demand the certificate ID and status of everyone working in the data center. If the CCIE/RHCE/MCSE lapsed and the auditor found out, the auditor would call security and the employee would be fired on the spot for "failure to maintain acceptable training and knowledge."
Slashdot Mirror
Never tried, as I've always punted the OVF/OVA files manually, but don't think it would do well with managing cluster or datacenter objects. Even backing stores isn't a concept in VMWare workstation (as it just uses the OS filesystem for that.)
Thankfully, not much has to be done to spin up a new VM, less if one uses some top tier abstraction utility.
Those days are long since past. Most datacenters tend to have iLO networks, ability to remotely power up/down equipment, extensive monitoring, decent switches, so the only thing SiteOps has to do is plug the cables into the proper ports, and everything is done from remote. The days of walking around with a CD and/or an external hard drive to reimage a PC are long gone... long since replaced by PXE for hardware, or templates and provisioning servers for VMs.
Only problem with NoDak is that if it gets snowed in, some type of outage can take days to weeks to get fixed if the weather is bad, and with temperatures well into the negative 40s, it takes specialized equipment to fix things. Texas and Georgia have their problems, but generally, the worst one encounters are ice storms which make an area impassible for a few days, and those are relatively infrequent. The occasional snow is manageable.
Well, the absolute worst are twisters... but that's what insurance is for.
I tend to rotate between FF and Chrome for general Web browsing, although I wrap both with sandboxIE pointing towards a different drive volume [1], or I put the browser in a VM. This way, no matter what type of supercookies are saved, they get dumped. Of course, this doesn't help with browser fingerprinting, but there are other ways to deal with that.
Firefox can be well configured with add-ons to limit the scope of what can be done. No ads, Javascript, Flash, social media tokens, all easily selected per site. To boot, it keeps its security keys and passwords in a separate stash, which can help if some program decided to add its root key into Windows's key stash in order to MITM SSL transactions.
[1]: I've had malware nail the browser and totally barf on the filesystem, so having the sandbox on its own drive volume allows you to just format it for cleanup work.
I still don't get why VMWare dropped the client around ESX 5.0. The client definitely doesn't have the features of the Web client... but it worked quite well.
Looks like I might have to do with VMWare what I do with some older embedded appliances that require Java (and break on any new Java version), and that is to have a VM set up on a separate cluster (to protect against chicken/egg scenarios) whose sole purpose in life is to be for logging into vSphere.
That, and be able to do vSphere command line work, so the only tool that is needed would be SSH if it came down to it.
Sendmail.cf is extra credit these days?
IIRC, Windows 8 and newer have this as a feature. However, I wind up using WS 2012 R2, where if one uses the MMC panel, BitLocker will ask you to store or print a recovery key. You can turn on BitLocker manually with "manage-bde -on x: -free" so it encrypts, then add protectors (passwords, recovery keys) later on.
Best recovery protection I've found is to copy the recovery key text, toss it in an offline PW manager, check to see if you can unlock the volume with the key, and go from there.
Of course, in an enterprise setting, this is moot -- just have BitLocker stash the recovery keys in AD, or push a data recovery agent.
It may not be much assurance, but one of the head devs of BitLocker did state that there are no backdoors in it. Does that mean there are? Game theory might apply:
If there are none, life goes on.
If there is one, it will get discovered, BitLocker tossed out the window by every company in the world, replaced with something that is vetted like TrueCrypt or its descendants.
Plus there are levels of law enforcement. Interpol/FBI is one thing. The local HOA trying to be nosy and use a civil action to get into someone's machine because they think someone had five guests when the limit is four... not so much. If there were a backdoor, the hand wouldn't be tipped unless it was a high value target.
As for a recovering a MacBook's data, there are a number of variables involved. If someone (the previous employer) had access to an admin user, they could easily slip in a recovery key. Then, even though the key can't be used at boot time, the MacBook can be booted via target mode and the drive mounted on another Mac using diskutil.
If the MacBook was completely independent and wasn't compromised via the network, it seems quite dubious that someone's employer could seize their computer, take it to a local Mac store, and a magic button be pressed to decrypt it. If this were so, there would be a hue and cry from MacRumors to CNN about this.
Not to say this impossible, but it falls along the lines of improbable.
I hope this is the case, and I'm proven brain-dead wrong. MS hasn't really pulled any real "fast ones" recently. W10 looks like it will be the next Windows 7 or XP.
As for OS releases, MS's real interesting OS release will be Server 2016. I'm guessing MS is going to wait and see what bugs pop up with W10, get them fixed before WS2016 goes out the door (which is a wise move.)
WS2016 is (for me that is) the one to watch, especially the added virtualization and container capabilities. I wonder how many places will be using the Docker capabilities once that gets out onto servers.
I think everyone reading this is has been in that boat sometime or another. The only thing that might have helped was to run a wbadmin backup of your personal machine (at least the hard drive with the Windows partition) so you can boot OS media and reload the entire drive fairly quickly if you encounter any bumps.
I'll just be happy with -any- modern reactor technology. Right now, if I were to throw a car analogy out there, people whine and gripe about how unsafe and terrible Studebakers and Packards are, without realizing that nuclear technology has progressed 70 years since then.
New gen technology is a lot safer, intrinsically. Come a scram, rods fall down into the core, instead of being pushed horizontally. Gen IV designs are a lot better at getting the most out of every fuel rod, so waste is lessened.
The US can easily handle its power needs. Thorium reactors for base power, solar for peak, high capacity batteries for transportation, and Audi's synthetic diesel fuel for everything else. This is more of a "won't", a political will problem than an actual "can't".
In the past, there were last minute "gotchas" which MS tossed in right before a build went RTM. In the antediluvian past, it was removing direct MS-DOS access in Windows ME, with XP, it was the Secure Audio Path (which was a DRM stack which required all audio drivers to be signed, in order to prevent programs like TuneBite from existing.)
I wonder what is going to be tossed in at the last minute. Hopefully nothing too headache-forming.
This. This is how to fix the issue for the long term stability of the EU. Write off the debt, let Greece pick itself out of the mud financially by itself over the next ten years, then start doing business all over again. The money gained from doing this will more than make up for the lost debt.
Right now, there always needs to be the consideration of what happens if Greece gets too unstable. If people start starving and the government is unable to provide basic infrastructure needs, then Greece will never be useful to the EU, even in the timespan of decades. Even worse, if the people start revolting, Greece could have its government overthrown and a new rulership installed that could be extremely hostile to EU interests.
Even though it isn't the same conditions, what happened in Iran comes to mind. Once people realize they have no economic future, they can latch onto anyone who looking for political office, and is a brutal firebrand who can promise them the world. Germany in the 1930s also comes to mind as well about what happens when other countries are too heavy handed in an economy.
This. I can drive 10-20 minutes, or spend 2-3 hours dealing with the buses, and a half mile walk between bus stops.
If there were buses in my neck of the woods that has a usable route, and didn't have 1+ hour gaps on the schedule, I'd definitely use it.
In fact, when I lived on a university bus line, and my work was near the university, this was an idea. Hop the bus (which came every 5-15 minutes), spend about 30 minutes for the ride, and be done with it. My car sat unused for months.
I just wish the US had more usable public transportation systems. As the parent said, a 45 min commute in rush hour sucks, but a one hour layover at a bus stop, as well as dealing with buses which are the living room, bedroom, and bathroom for the city's homeless, makes trying to bus it not worth the bother.
The ironic thing is that before DES and PGP were common in the early 1990s, the most common encryption utility on UNIX was the crypt (1) command [1]. This is based on one, 256 element, rotor, rather than multiple rotors with just the alphabet on them.
[1]: This is different from crypt (3), the password hashing algorithm.
That's the problem. Java consists of a ton of moving parts which get lumped into one concept:
1: The Java language.
2: The Java bytecode.
3: The JVM/JRE.
4: The JDK.
5: The Web plugins.
The Java language is decent. It is arguably the modern day BASIC, where it is fairly easy to get a "hello world" program, and has decent functionality as a general purpose language.
The Java bytecode is also robust. It would be nice if it were more like .NET's IL, where one can use any language of choice, and the compiled output winds up being bytecode, separating the language from the compiled code... but it is what it is.
The JVM/JRE is a headache-maker. I've seen AIX systems with 10-15 different Java executables, all in various sundry directories. Similar with Windows, with some programs using their own JVM, and multiple JVMs present systemwide. Only real answer is to have a VM dedicated for handling interacting with a Java website (usually an older appliance) that has the right JVM in it.
The JDK is not really an issue, but it is lumped in with Java.
Finally the Web plugins. As is stated on /. and other places, the most common vector for intrusion are compromised browsers or browser plug-ins. This will continue to bite us until stronger isolation is put in place, similar to IE's low security mode, but with true filesystem isolation and separation of browser instances, so a compromised window/tab can't infect another.
Main solution with dealing with Java is virtualization or containers. Serverside, it is extremely useful, but for applets, its time is long gone.
This is what VMs are for. There are appliances (older Sun disk arrays for example) that not just require Java, but only work with one version of the JVM, and will just throw exceptions and crash if one uses the latest version.
So, to interface with the legacy controllers, a browser and that correct Java runtime go into a VM and when it is done being used, it gets shut down and rolled back.
The answer to "What, if anything, should we block" versus "What, if anything, should we allow" is "it varies":
Scenario 1: Receiving. Give the guy a Citrix or App-V console into a machine that can browse the Internet unfettered, but doesn't allow files to be transferred to the internal machine. Now the user has access to websites, there is something substantial keeping the actual machine from being compromised.
Scenario 2: Finance. Again, these machines are touching sensitive data, so they, by themselves, don't see the outside world, but the user can always use a VDI implement to browse the web, making the isolation a non-issue.
Scenario 3: General company (dev, QA, sales) use. The above in reverse. Allow traffic out, have a good IDS/IPS in place (this should be in place everywhere, but especially with this), and stick the real sensitive stuff behind a RDP firewall, or a "hop box". The user can manipulate the data, but malware on their machine will have a hard time (though not impossible) to grab the entire database for upload to a blackhat's site.
Scenario 4: Point of sale registers. These have no reason to be connected to the outside Internet, other than through a server for credit card validation.
Of course, these are generic, off-the-top-of-my-head scenarios, but there is no one size fits all solution, other than that it helps to have some type of VDI for separation of data.
The EMC Isilon is a cluster of FreeBSD nodes with completely customized filesystem on top. All the nodes are connected to each other by Infiniband, and redundancy is built into OneFS.
I'm visualizing this as someone adding FPGA cards to Isilon nodes, and installing SSDs instead of the usual HDDs in the array. Innovative, but this isn't revolutionary by any means.
Success might be model and even ROM specific. I did the manual install of the framework on a 5.x ROM with a HTC One M8 with default ROM... and it promptly bootlooped.
Am in the same boat. I had to roll back to 4.x just because I rather have XPrivacy than the latest gewgaws and UI.
The acid test of privacy is running Yik Yak. If you like a few posts, delete the app, and reinstall it, without it showing you your old yakarma score, then you did the job right, because that app does a lot of stuff in order to permanently ID a device.
Juice Defender is another app along these lines. It is mainly intended for dealing with prolonging battery life by turning off the data and Wi-Fi options, only turning them on at selected intervals to allow mail to be fetched.
Titanium Backup is good for disabling apps, even if they live in /system, and are not able to be turned off by normal means. This is a must have app, since it not just can back up, but can use reliable encryption, and back up the encrypted files to a cloud provider.
Disclaimer: Root is needed.
Xposed and XPrivacy have issues in Android 5.x, so it might be a while before the platform stablizes enough for that.
An alternative is the successor for LBE Privacy guard... provided you can read Chinese, and don't mind trusting the source.
This isn't programming, but in IT, I worked at places where they would have auditors randomly go around and demand the certificate ID and status of everyone working in the data center. If the CCIE/RHCE/MCSE lapsed and the auditor found out, the auditor would call security and the employee would be fired on the spot for "failure to maintain acceptable training and knowledge."