John Stultz wanted to allow specially privileged processes to migrate other processes between cgroup namespaces—essentially migrating processes from one virtual machine to another. This is risky, because one of the whole points of cgroups is to isolate a virtual system and prevent any potentially hostile processes within it from escaping.
John's patch, based on ideas from Michael Kerrisk, would allow this process migration if the controlling process had been granted CAP_SYS_RESOURCE capabilities.
John explained that this originally had been an Android feature created so that people wouldn't have to run their activity manager process with root privileges. John felt his approach was cleaner and more generic.
Kees Cook liked the patch, but Andy Lutomirski saw trouble up ahead. He explained:
Developments are afoot to make cgroups do more than resource control. For example, there's Landlock and there's Daniel's ingress/egress filter thing. Current cgroup controllers can mostly just DoS their controlled processes. These new controllers (or controller-like things) can exfiltrate data and change semantics.
Alexei Starovoitov asked if Andy knew a better approach, but Andy said he did not. He was only able to identify the problem, but had no solution to offer. He did, however, identify some constraints that any potential solution would need to adhere to. He said:
1. An insufficiently privileged process should not be able to move a victim into a dangerous cgroup.
2. An insufficiently privileged process should not be able to move itself into a dangerous cgroup and then use execve to gain privilege such that the execve'd program can be compromised.
3. An insufficiently privileged process should not be able to make an existing cgroup dangerous in a way that could compromise a victim in that cgroup.
4. An insufficiently privileged process should not be able to make a cgroup dangerous in a way that bypasses protections that would otherwise protect execve() as used by itself or some other process in that cgroup.
John didn't know where to go with those admonitions, and the project seemed to stall for a few weeks. Finally Andy suggested:
The cgroupfs interface is a bit unfortunate in that it doesn't really express the constraints. To safely migrate a task, ISTM you ought to have some form of privilege over the task and some form of privilege over the cgroup. cgroupfs only handles the latter.
CAP_CGROUP_MIGRATE ought to be okay. Or maybe cgroupfs needs to gain a concept of “dangerous” cgroups and further restrict them and CAP_SYS_RESOURCE should be fine for non-dangerous cgroups?
But, Tejun Heo objected that if CAP_SYS_RESOURCE was disqualified due to overlapping users, it would be better to use a different capability altogether. He suggested:
We can't do it properly on [cgroups] v1 because some controllers aren't properly hierarchical and delegation model isn't well defined. For example, nothing prevents a process from being pulled across different subtrees with the same delegation, but v2 can do it properly. All that's necessary is to make the CAP test OR'd to other perm checks instead of AND'ing so that the CAP just allows overriding restrictions expressed through delegation but it's normally possible to move processes around in one's own delegated subtree.
Tejun went on to explain:
Delegation is an explicit operation and reflected in the ownership of the subdirectories and cgroup interface files in them. The subhierarchy containment is achieved by requiring the user who's trying to migrate a process to have write perm on cgroup.procs on the common ancestor of the source and target in addition to the target.
In other words, it's a completely different approach from the one initially proposed by John.
The discussion ended inconclusively, with the main question remaining whether to use an existing capability or write a new one.
Typically, cgroup features are insane. There are often security issues affecting virtual systems that wouldn't affect the outer running system, forcing Linux to offer only a weird special-cased subset of normal features. And there are also bizarre use cases surrounding various feature enhancements, in which developers want to add functionality to cgroups that would not be desirable in regular Linux. It's all very here-be-dragons and full of magic. Migrating processes between virtual systems will probably be a lot like that.
Serge E. Hallyn pointed out a security issue with cgroups. He said:
Root in a user [namespace] cannot be trusted to write a traditional security.capability xattr. If it were allowed to do so, then any unprivileged user on the host could map his own uid to root in a namespace, write the xattr, and execute the file with privilege on the host.
The problem was that in the outer system, a user might legitimately do something like that, while on a virtualized system, it was a security hole.
Serge posted a patch to do crazy madness in order to simulate proper behavior on the virtual machine. The patch, he said, “allows a simple setxattr to work, allows tar/untar to work, and allows us to tar in one namespace and untar in another while preserving the capability, without risking leaking privilege into a parent namespace.”
He explained:
When a task in a user ns (which is privileged with CAP_SETFCAP toward that user_ns) asks to write v2 security.capability, the kernel will transparently rewrite the xattr as a v3 with the appropriate rootid. Subsequently, any task executing the file that has the noted kuid as its root uid, or which is in a descendant user_ns of such a user_ns, will run the file with capabilities.
If a task writes a v3 security.capability, then it can provide a uid (valid within its own user namespace, over which it has CAP_SETFCAP) for the xattr. The kernel will translate that to the absolute uid and write that to disk. After this, a task in the writer's namespace will not be able to use those capabilities, but a task in a namespace where the given uid is root will.
Eric W. Biederman gave a quick look and said the patch seemed strange but correct. He said he'd go over it thoroughly and report back. Meanwhile, Michael Kerrisk asked for some documentation, perhaps in the man pages for user_namespaces(7) or capabilities(7), and Serge wrote some up.
I don't very often play games. I know that seems odd, because I do often write about gaming. Honestly though, I very rarely actually take the time to play video games. Recently, however, there has been an exception to that rule.
One of my favorite online comics is The Oatmeal. The creator collaborated with another guy and came up with an incredibly fun card game called Exploding Kittens. I love the game. My teenage daughters love the game. Heck, I've even purchased another box so my college-aged daughter could play it with her roommates. Not only is the card game fun, but they also made a video game version that was on iOS-only for a long time.
Well, no more. Now you can get Exploding Kittens for $1.99 at the Google Play store. It supports playing with random weirdos on the internet (I could be one of those weirdos) and playing with a group of friends. I won't describe the game itself other than to say it's silly, hilarious and fun. Plus, there are lots of awesome graphics drawn by The Oatmeal. In fact, this game is so much fun for such a reasonable price, I'm giving it this month's Editors' Choice award even though it's not open source. Because truly, it's an incredibly fun game that you can play in five minutes while you're doing whatever you might be doing that would facilitate five minutes of quiet time on your cell phone.
Search for Exploding Kittens at the Google Play store, and start playing now!
I hate it when I paste something into a window, only to realize I'd copied something new into the clipboard. I usually end up with eight paragraphs pasted into a login box. To quote my college-aged daughter, the struggle is real.
Thankfully, it's easy to integrate a clipboard manager into OS X. Several options are available, but my favorite happens to be open source. If you head over to https://github.com/TermiT/Flycut, you'll find Flycut, which is a clipboard manager that quietly records all your clippings and allows you to paste whichever one you want at any given time. By default, if you want to use Flycut instead of the system clipboard, you press Command-Shift-V instead of just Command-V. A screen overlay lets you scroll through previous clippings, and you double-click on the one you want to paste.
Flycut is a very simple tool, but all the best ones usually are. If you've ever accidentally overwritten your clipboard, you owe it to yourself to download Flycut either from the GitHub page or the Mac App store.
Many chemistry software applications are available for doing scientific work on Linux. I've covered several here in previous issues of the magazine, and of them have their own peculiar specialties—areas where one may work better than another. So, depending on what your research entails, you may need to use multiple software packages to handle all of the work. This is where Gabedit will step in to help you out.
Gabedit provides a single unified interface to a multitude of chemistry packages available on your system. It should be available within the package management systems for most distributions. For example, on Debian-based systems, you can install it with the command:
sudo apt-get install gabedit
Once it's installed, start it with the gabedit command. The very first time you start Gabedit, you'll see a series of windows describing all the data directories that need to be created in order for Gabedit to run. The pane on the left-hand side shows a listing of all the chemistry programs you could use for your work. The central pane provides two tabs, one for input and one for results.
Figure 1. When you first start Gabedit, you'll get an empty project where you can begin your work.
To start working with Gabedit, you need to create a new input file for the software package you want to work with. The icon bar across the top of the window provide buttons for the various types of input files that Gabedit can use. Clicking on one of them will pop up a new window where you can enter parameters relevant for that type of input file. For example, clicking on the first button pops up a window where you can create a new input file for GAMESS.
Figure 2. When you create a new input file, a new window pops up where you can enter the initial parameters.
If you try to do this at the beginning of your work, you'll actually get an error. All of these programs depend on some set of atoms, defined as a geometry, in order to do their calculations, which means you need to create this geometry first. Clicking the Geometry menu entry will provide a list of different options for creating a new geometry. The first two are specialized options for Gaussian and Molpro. For this example, let's use the two options at the bottom of the list. The first option pops up a new window where you can select the type of geometry (XYZ, for example) and then create a table of atoms used within your geometry.
Figure 3. You need to create a new geometry that will be used in the calculations.
Right-clicking inside the table of the geometry editor provides a pop-up menu where you can add a new entry to the table. This allows you to select the element, location and charge for the new point in the geometry. This geometry exists within the memory space of the current project, which means it will be available for other functions within Gabedit.
Figure 4. You can add individual elements, setting their chemical properties, to your geometry.
The other available geometry function is the draw function. You can access it via the Geometry→Draw menu item. This pops up a new window where you can visualize your molecule and manipulate it before doing any calculations.
Figure 5. You can use the draw functionality to visualize the geometry of your collection of atoms.
Here, you can edit the existing geometry and move elements around, or you can add or remove elements to the molecule. You even can add entire functional units, such as benzene rings or alcohol groups.
Once you have an input file, you need to run it through the appropriate software package in order to get results. If the programs you wish to use are installed on your local machine and are in your search path, it should just work out of the box. If they were installed in some other location, you need to tell Gabedit where they are. Clicking the Settings→Preferences menu item will bring up a new window where you can set the commands needed to run the relevant programs.
Figure 6. You can set the specific commands for each of the available chemistry packages.
You then can run the program either by clicking the run button in the icon bar or clicking the Run→Run a Computation Chemistry program menu item. This will present a new window where you can set the parameters for this run.
Figure 7. You can set the parameters for either a local run or a remote run within the same window.
For a local run, you can set parameters including which program to use, what folder to run in and the filenames and commands to execute. If you select “Remote host” instead, you can choose the protocol to communicate over and which host to communicate with. You also can set the user name and password to use, along with the working directory on the remote machine. If you find that your initial choice of program isn't optimal, you can try another. By clicking the Tools→Open Babel menu item, you get a window that allows you to do a translation of input file from one file format to another. This way, you can reuse your previous work within a different software package.
Gabedit is not only useful in setting up a computational chemistry problem and running it, but it's also useful in analyzing the results afterward. The analysis functions are available under the Tools menu item. You can select to load a file for a basic XY-plot, and you can select the Tools→XY plotter menu item to bring up the plot window. Right-clicking the plot window brings up a menu where you can change the options of the plot as well as load data files to be plotted. There also is an option to do contour plots by clicking the Tools→Contours plotter menu item.
Figure 8. You can do contour plots of the results from a computation.
Additionally, there is a whole series of spectrum analyses that you can apply as well. You can do IR, Rahman, UV and ECD spectral analysis. For each of these options in the Tools menu, you can load an output file from a number of different file formats, including a special Gabedit file format.
Under the NMR spectrum entry of the Tools menu, you can select to load either a previously calculated results file or the NMR Spin-Spin Splitting Simulation.
Figure 9. You can do NMR spectrum simulations for your molecule of choice.
Here you can set several options, such as the lineshape and the scaling. If you right-click the plot window, you have the same options as in the other plot windows. You also can add more data sets, change the plot details or the overall color theme.
With Gabedit, you can use quite a few of the available chemistry packages from a unified user interface. When doing more complicated research, or doing discovery work, being able to use multiple packages definitely will make everything easier to handle. You also can expand the options within Gabedit by adding your own functional units or altering the molecular mechanics parameters to be used in your work. Hopefully, Gabedit can help move your research into new areas.
I'm often asked about what the latest trends in IT will mean for job hunters. It's interesting for me, because although I haven't actively looked for a job in years, I do create training that helps people get hired every day. So, I figured a few tips for the current job market would be a great way for me to answer lots of emails in one fell swoop. Here it goes.
1) DevOps is no longer magic.
For the past two years, if you could put “DevOps” on your résumé, you'd pretty much get hired on principle alone. Lately, DevOps has become a ubiquitous part of IT, and it isn't the special snowflake it used to be. Don't get me wrong; you still need to have DevOps skills on your résumé—just know that it won't get you hired on its own. Instead, mention what sorts of things you have done or can do utilizing DevOps.
2) Security is vital.
If you love security, the future looks bright for you. But even if specializing in security isn't what you want to do as a career, it's important to approach every aspect of technology with a security mindset. Twenty years ago, we worried about firewalls, but rarely considered attacks coming from inside our own networks. That was a poor attitude 20 years ago, and now it's technology suicide. Security isn't something you add, it's a way you plan.
3) Developers, developers, developers.
Steve Ballmer may have seemed like a crazy man when he shouted it on stage back in 2000, but now that DevOps is a part of everything we do, developer skills are as important as ever. Even the traditional system administrator or operations person will need to have at least rudimentary programming skills in order to function in our DevOps world. Plus, here's a secret: programming is actually kind of fun, especially when it can save you time on the job!
4) Don't forget your roots.
In the Pixar movie WALL-E, civilization has advanced to the point that everything is automated. It means life for people is extremely easy, but it also means they don't know how to do anything for themselves. With everything in the data center and the cloud being automated, it's easy to hire an entire team that knows nothing about the actual processes they're automating. That works great—until it doesn't. Make sure you're well versed in the underlying systems (almost always Linux), so when something goes wrong, you know how to fix it.
5) Be a softy!
Soft skills (communication skills, cooperation skills and so on) are something we all too often overlook in IT. But not only do soft skills help you in the interviewing process, they also help you in the current IT landscape where various disciplines are working closer than ever. Again, DevOps is much to blame for this blurring of department lines. Any employee who is able to communicate cross-discipline, especially one who is able to communicate with non-IT folks, is going to be invaluable to any organization. Take some communication classes. You might be the only nerd in the room, but you'll also likely have the best job opportunities!
Although they might not be so good for credit cards or floppy disks, magnets are one of those things that always have fascinated me. For the past few years, I've wanted to get a set of the round Zen Magnets to play with—they're sort of like an extra science-y version of LEGOs. Unfortunately, before I was able to purchase any, the US government banned their sale!
Recently, the folks at Zen Magnets won their long legal battle and are able to sell tiny, strong magnets again. The regular-size Zen Magnets aren't available yet, but thankfully, production once again can begin. In the meantime, I was able to order “micromagnets” from the same company. They work just like Zen Magnets, but are tinier. I decided to order a couple sets, because I'm impatient and also to support the company who fought the battle allowing magnets to be sold in the US once again.
These are what I made last night with my new micromagnets. I can hardly wait for the full-size ones!
To read about the legal battle, check out the blog here: zenmagnets.com/magnet-ban-cleared-game-on. And while you're there, feel free to pre-order some Zen Magnets. I sure did!
Remember that nobody will ever get ahead of you as long as he is kicking you in the seat of the pants.
—Walter Winchell
The great thing about a computer notebook is that no matter how much you stuff into it, it doesn't get bigger or heavier.
—Bill Gates
Security is a kind of death.
—Tennessee Williams
Above all things, never be afraid. The enemy who forces you to retreat is himself afraid of you at that very moment.
—Andre Maurois
There's only one thing I hate more than lying: skim milk. Which is water that's lying about being milk.
—Ron Swanson