Tumblelog by Soup.io
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

June 12 2017

Ekta Nandwani: And the official coding period begins…

Hello there ! This is my first post about my GSoC project.

About Project

As the title says Sharing of shopping lists from Recipes to TODOist which is self explanatory.

Implementation

There would be addition of minute details as and when the steps gets implemented. The implementation is basically divided into two steps.

  1. Implement gnome-online-accounts Provider for TODOist. (Along with that taking care of the fact that Recipes being non-core app,if isn’t installed, this implementation doesn’t end up having TODOist account that serves no purpose)

  2.  Implement sending shopping list/s from Recipes to TODOist along with sync in the deletion of items

    Onto the implementation of step one. I am digging my way through gnome-online-accounts to write a TODOist provider. Stay tuned for more details! 😉

Stef Walter: Is Cockpit Secure?

Security is of your Linux systems vital. It’s not a binary thing though. Depending on your requirements you end up choosing a level of security that still allows you and your systems to accomplish what they need to do.

Here’s info about Cockpit’s security, to help you make those choices. You’ll find not only has Cockpit got a solid security story, but you can use it in all sorts of different ways depending on what kind of security your systems need.

Cockpit is a Linux session in your browser

Let start by stacking the deck against Cockpit. First off it’s important to remember that Cockpit is actually an alternative Linux session … along side X11, SSH and VT logins. It’s a session in the PAM, logind, TTY, SELinux and other senses. The logged in browser and the javascript code it is running can interact directly with the system as part of that session.

Try this out if you want. Log into Cockpit, and pop up the Javascript console by pressing Ctrl-Shift-J in your browser. Now type commands like the following:

> zz = cockpit.spawn(["ping", "-c4", "8.8.8.8"])
> proxy = cockpit.dbus("org.freedesktop.hostname1").proxy()
> proxy.KernelName

Pretty cool, huh. And that’s why Cockpit can be such a powerful and quick way to build Linux system admin interfaces.

But are browsers secure?

But can we trust browsers with your security? Firefox is about 15 million lines of code that all have to work together, and after looking at the list of security updates you gotta think about what that means for your security.

Any management system with a browser interface requires a secure browser. That includes Satellite, Tower, Foreman, Landscape, CloudForms, cPanel and more. If anything like this interacts with your systems, then security bugs in browsers have a direct effect on your system security.

Secondly take a look at any browser based tools that were involved in the creation or curation of the software installed on your system, including tools used by your Linux distribution.

If your security requirements are strict and you must avoid browsers at all costs, then be sure to audit all possible places that browsers were involved in what’s running on your systems. It’s harder than you think.

Unless your system is very isolated, it turns out that browsers are likely already highly involved in the security paths for your systems. Cockpit does not change this situation significantly.

Cockpit has no special privileges

Back to Cockpit. What does that session look like? Cockpit itself has no special privileges. The credentials of the logged in user start a login session, and Cockpit can perform exactly the tasks that the logged in user has access to. It has no more or less permissions.

You can examine anything about Cockpit security. Log into Cockpit, open the Terminal page and run commands like the following:

$ id
uid=1000(stef) gid=1000(stef) groups=1000(stef),10(wheel)
$ cat /etc/shadow
cat: /etc/shadow: Permission denied

If you logged in as a non-root user, you’ll find that Cockpit has no elevated privileges on the system.

Escalating privileges

So if Cockpit only has the priviliges of the authenticated user, how does it perform admin tasks. Well obviously one could log in as root, and the logged in session would have all capabilities and access to the system.

But logging in directly as root is a poor security practice. Cockpit supports escalating privileges via sudo and/or polkit. If, and only if, the logged in user has permission to escalate privileges.

On the login screen you’ll see a checkbox to enable privilege escalation:

Reuse my password for privileged tasks

This checkbox allows Cockpit to use your login password to escalate privileges via sudo and/or polkit when necessary to perform admin tasks. This is as if you log in with SSH and then used sudo -s or similar to perform some admin tasks. Try the following command once you’ve logged in with the checkbox:

$ pkexec bash
# id
# uid=0(root) gid=0(root) groups=0(root)

You can track the state of this privilege escalation in the upper right corner of Cockpit. Click this button to drop any escalated privileges:

Unlocked option

Now you can again, try the above pkexec command, and it should fail.

Principle of Least Privilege

A good security practice is to run services, processes or tools with the least amount of security privilege necessary to perform their task. To accomplish this, Cockpit is split up in multiple components, each of which runs with as little access to the system as possible.

On RHEL, Fedora, Ubuntu, Debian and any other distro that we distribute Cockpit for … we test and make sure that this privilege separation is in effect. Including correct SELinux policies, and unprivileged unix users.

Here’s some of the privelege separation described:

stef        9690  ...  Sl  06:08  0:00 cockpit-bridge

The cockpit-bridge is the part of Cockpit that runs in the login session. It is similar to a login shell, in that it runs with the privileges and security context of the logged in user. In the above case I logged in as the stef user. If you checked the Reuse my password for privileged tasks option on the login screen, you might also see this process running as root in which case pkexec or sudo was used (see above) to escalate privileges.

root        9947  ...  S   06:10  0:00 /usr/libexec/cockpit-session

The cockpit-session part of Cockpit is a small binary that performs authentication for the logged in user. It uses PAM or GSSAPI to perform that authentication. cockpit-session is installed setuid, in such a way that it can be launched by the unprivileged cockpit-ws user (see below) during user login. This process performs limited tasks, and has a restrictive SELinux cockpit_session_t context. Lastly is a reasonably short program written in plain C so it is easier to audit.

cockpit-ws 11295  ...  Ssl 06:14  0:00 /usr/libexec/cockpit-ws

This is the component that listens on the network. It hands off authentication information to the cockpit-session to perform a login and launch cockpit-bridge. The cockpit-ws binary runs as an unprivileged unix cockpit-ws user, with a restrictive SELinux cockpit_ws_t policy.

Security Policy within the browser

Cockpit runs javascript code from the system it’s logged into. Obviously that code is protected by the standard Same Origin Policy that web browsers adhere to.

But How does Cockpit protect against bugs in the code. How can we be sure that only the javascript code installed on the system is run, and bugs are not exploited to run code trojaned into logs or other data loaded by Cockpit?

Browsers have a security technology called Content Security Policy which is sorta like SELinux or Apparmor in your browser. The policy describes exactly where code can be loaded, what can be run, and what sorts of connections can be made by the browser.

In Cockpit’s case we send a strict Content-Security-Policy header that only allows code installed in Cockpit packages on the logged into system to be run. Although individual parts of Cockpit can override this default, it’s rarely done. The default security policy looks like this:

 Content-Security-Policy: default-src 'self' connect-src 'self' ws: wss:

A failure of Content Security Policy will look something like this in your browser’s javascript console:

Content Security Policy denial

Security of the network facing TCP port

Cockpit typically listens on TCP port 9090 on a host. This is the websm or “Web Systems Manager” network port. Opening a network facing port has security risks. Both the exposed surface area and stuff listening on that port, in this case cockpit-ws, are risky.

If this is an issue for your systems, you can use Cockpit over the SSH port already have open. But wait, how does that work? Browsers don’t natively speak the SSH protocol, and getting a browser to do so would be an impressive party trick.

To use Cockpit over SSH, use a bastion host model: Start cockpit-ws on port 9090 on a single host, perhaps even your localhost. Connect to that with your browser and use that first Cockpit instance to log into to Cockpit on other machines others over SSH. If you draw it up, it looks something like this:

Multi-host Transport

Atomic Host includes Cockpit by default, in this way. Atomic Host doesn’t include cockpit-ws or open port 9090 by default, but expects you to connect from another running Cockpit instance over port 22. There’s also the possibility to run cockpit-ws as a container to accomplish this.

When you’re trying this out in real life, specify an alternate server on the Cockpit login screen. The SSH protocol will be used to connect to it:

Login Alternate Server

Or you can add other machines to a local dashboard, and Cockpit will connect to them via SSH. Even usage of SSH key based authentication works great:

Obviously, when you use Cockpit over SSH, it’s not just a real Linux session, it’s also an SSH session in every way. Try it out.

In conclusion

I could go further about how Cockpit uses Kerberos to do single sign on or how it works with certificates or how you can even bring your own authentication tool to replace cockpit-session. and much, much more.

But suffice it to say, that Cockpit’s security is well thought out, layered and matches that of Linux in general.

Joe Shaw: Don’t defer Close() on writable files
Ruben Vermeersch: CoreOS Fest 2017
Julita Inca: Following a Python Tutorial – Part 1

June 11 2017

Kai Lüke: An Observation in UI Design
Carlos Garnacho: Next Tracker is 2.0.0
Jean-François Fortin Tam: Painting two old friends—Tintin vs Sephiroth

Christian Hergert: Library Documentation

Now that gtk-doc is getting updates and integration with Meson, I decided to give it another shot. So here is some work-in-progress documentation for libdazzle, template-glib, and jsonrpc-glib.

There is plenty of work to do, but this makes it easier for others to come along and help me do the hard part, the documentation.

I’m sort of impressed, in hindsight, at the staggering amount of things we’ve built around Builder in the last couple of years.

June 09 2017

Michael Meeks: 2017-06-09 Friday.
Frédéric Crozat: Synology PhotoStation password vulnerability
Julita Inca: Teaching Linux more than 1K students in 2017

Christian Hergert: This week in Builder

Given the success of this pattern of project-related updates in Gtk, maybe we can try to do this for Builder too. We’ve had lots of updates this past week in Builder and related projects.

  • Builder has switched to meson for building Builder. Autotools has been removed. This does NOT affect build systems supported by Builder.
  • Non-builder related widgets and utilities have moved into libdazzle. Roughly 50k fewer lines of code in Builder.
  • template-glib and jsonrpc-glib are now external projects. Our meson-based build system will automatically install them if necessary.
  • libdazzle’s DzlApplication now handles theme loading, menu merging, and icon loading. It also simplifies widget theming for non-Adwaita themes.
  • Builder’s panel engine was revamped and moved to libdazzle. Various CSS fallbacks were added, including Arc theme.
  • New releases (3.25.2) of gnome-builder, template-glib, jsonrpc-glib, and libdazzle.
  • Builder has switched to DzlSuggestionEntry for search. This design is not final by any means, so I expect further changes.
  • Shortcut engine development continues.
  • libdazzle’s fuzzy search has been vastly improved, while keeping overhead low.
  • Lots of widgets have been moved into libdazzle.
    • DzlThreeGrid — This is a three-column layout (with centered column) and rows.
    • Preferences ­— Copy the Builder style preferences in your app
    • Menu merging — Automatic menus.ui merging and management, handy for plugins.
    • StackList — Make your list boxes fly around
    • CPU graphs
    • Panels
    • MultiPaned — No more nested GtkPaned, deals with resizing, expanding, min and natural sizes appropriately.
    • RadioBox — Fancy joined buttons that act like radio boxes. Easily extendable for dynamic content.
    • Empty State ­— Your standard empty state helper
    • Progress Buttons — Both GNOME Software and Epiphany style animated download buttons.
    • Chromium and Firefox web-browser style auto-completion.
    • Lazy Tree Builders — These really simplify building large tree views with dynamic content.
    • Lots of utilities, data structures, and miscellaneous library glue.
  • A whole bunch of tests have been added to libdazzle. More are always needed.

If you’d like to help with the development of Builder or any of it’s associated libraries, come join us in #gnome-builder on irc.gnome.org.

June 08 2017

Lucie Charvat: GSoC: ToolTip Guidance
Matthias Clasen: Rawhide sightings
Adrien Plazas: Neo-Geo games on sale for GNOME Games

Daniel Espinosa: Vala 0.38 progress

Maintainers behind Vala compiler, have been busy this cycle.

Vala has a continuous integration machinery, so new features are added to staging branch before to land in master, in order to check some Vala projects can be compiled and their unit tests pass.

Expect more Vala improvements, fixes and backports to 0.34 and 0.36, so you can use them in your favorite distribution.

While 0.34 haven’t been officially declared as a long term support branch, it has received most fixes and backports, so stable releases, like Debian upcoming Strech, can provide reliable, stable and improved experience to developers targeting GNOME 3.22/Gtk+ 3.22 stable releases.

Vala’s bindings using GIR format are updated constantly and because them can be generated automatically from project’s sources, new API additions/changes land in master really fast. Is the case of GTK+ 4.0 unstable; allowing you to create testing/prototypes using latest hot GTK+’s new features, using Vala.

Highlights:

  • gobject-2.0: Add GLib.ParamSpecPointer
  • The CCode attribute ‘cname’ needs to be the canonical representation as it is expected in C. [Bug 731547]
  • gio-2.0: Use default ‘length = null’ for DataInputStream.read_line_utf8* [Bug 783351]
  • gvariant: Optimize (de)serialization of arrays with type-signature “ay” [Bug 772426]
  • Added –gresourcesdir switch, making easy to use gresg to autogenerate XML resource files in out of tree builds [Bug 783133]
  • Bindings updates
  • Gtk+ 4.0 bindings updates
  • codegen: Use *_free_full to free GLib.List, GLib.SList and GLib.Queue
  • Require and target GLib >= 2.40 [Bug 782005]
  • gdbus: Don’t leak nested HashTable on deserialization and make sure types derived from string are freed, e.g. ObjectPath [Bug 782719]
  • codegen: Fix finally blocks with async yields [Bug 741929]
  • compiler: Add –color=WHEN option following the format of other tools like diff and git-diff.
  • glib-2.0: Add quark() functions to errordomains
  • vala: Handle non-null in coalescing expression [Bug 611223]
  • glib-2.0: Add bindings for g_ptr_array_find/_find_with_equal_func()

Jeremy Bicha: GNOME Tweak Tool 3.25.2

Today, I released the first development snapshot (3.25.2) of what will be GNOME Tweak Tool 3.26. Many of the panels have received UI updates. Here are a few highlights.

Before this version, Tweak Tool didn’t report its own version number on its About dialog! Also, as far as I know, there was no visible place in the default GNOME install for you to see what version of GTK+ is on your system. Especially now that GNOME and GTK+ releases don’t share the same version numbers any more, I thought it was useful information to be in a tweak app.

Florian Müllner updated the layout of the GNOME Shell Extensions page:

Rui Matos added a new Disable While Typing tweak to the Touchpad section.

Alberto Fanjul added a Battery Percentage tweak for GNOME Shell’s top bar.

I added a Left/Right Placement tweak for the window buttons (minimize, maximize, close) . This screenshot shows a minimize and close button on the left.

I think it’s well known that Ubuntu’s window buttons have been on the left for years but GNOME has kept the window buttons on the right. In fact, the GNOME 3 default is a single close button (see the other screenshots). For Unity (Ubuntu’s default UI from 2011 until this year), it made sense for the buttons to be on the left because of how Unity’s menu bar worked (the right side was used by the “indicator” system status menus).

I don’t believe the Ubuntu Desktop team has decided yet which side the window buttons will be on or which buttons there will be. I’m ok with either side but I think I have a slight preference towards putting them on the right like Windows does. One reason I’m not too worried about the Ubuntu default is that it’s now very easy to switch them to the other side!

If Ubuntu includes a dock like the excellent Dash to Dock in the default install, I think it makes sense for Ubuntu to add a minimize button by default. My admittedly unusual opinion is that there’s no need for a maximize button.

  1. For one thing, GNOME is thoroughly tested with one window button; adding a second one shouldn’t be too big of a deal, but maybe adding a 3rd button might not work as well with the design of some apps.
  2. When I maximize an app, I either double-click the titlebar or drag the app to the top of the screen so a maximize button just isn’t needed.
  3. A dedicated maximize just doesn’t make as much sense when there is more than one possible maximization state. Besides traditional maximize, there is now left and right semi-maximize. There’s even a goal for GNOME 3.26 to support “quarter-tiling”.

Other Changes and Info

  • Ikey Doherty ported Tweak Tool from python2 to python3.
  • Florian Müllner switched the build system to meson. For an app like Tweak Tool, meson makes the build faster and simpler for developers to maintain.
  • For more details about what’s changed, see the log and the NEWS
  • GNOME Tweak Tool 3.26 will be released alongside GNOME 3.26 in mid-September.

Jeremy Bicha: Ubuntu Online Accounts and the Ubuntu GNOME Remix

A defining goal of the Ubuntu GNOME Remix is to bridge the gap between Ubuntu and GNOME. Shipping a pure GNOME flavor  that is part of Ubuntu is a huge challenge as Ubuntu has been patching GNOME for years. We’ve made a good amount of progress for 12.10 and things will be even better in 13.04.

On the other hand, the most frustrating regression in our goal that (to me) appeared out of nowhere this cycle is Ubuntu Online Accounts (UOA). UOA is an alternative to GNOME Online Accounts (GOA was released with GNOME 3.2 a year and a half ago). The first I heard of UOA was when reading the GNOME ftp-release list. What was this Ubuntu Online Accounts thing and why was it in GNOME but not in Ubuntu (until a week or so later)?

Apparently, it was actually discussed in private at UDS Orlando II a year ago. It’s another example of Canonical’s “develop in private” open source strategy….but that’s a blog post for another day.

Now for Ubuntu GNOME 12.10, we are now forced into shipping both GOA and UOA which provides a horrible user experience. The Ubuntu tool is required for Ubuntu’s Empathy package; the GNOME tool is required if we want online account integration with Boxes, Documents, and Evolution. Contacts is just broken (which is especially annoying since 12.10 is the first release where Contacts is included by default in the flagship Ubuntu release).

It’s a headache for GNOME app developers too. Because the two APIs are architectured fairly differently, it’s not clear whether other GNOME modules will accept UOA integration patches. And as Canonical doesn’t ship those apps by default, it’s not clear who’s going to write those patches. So as it stands, the duplicate Online Accounts bug is unlikely to be improved for 13.04 either.

I think part of the problem is that GNOME initially appeared to be rather restrictive on what accounts they were going to let into GOA; now the big problem I see is whether Canonical is willing to work with GNOME to merge these two implementations together or at least invest in cooperating to try to define a common API for app developers. Basically, Canonical was a huge part of creating this mess but what will they do to fix it?

Note the two Online Accounts entries

Debarshi Ray, the GOA maintainer has started a public dialog about the GOA/UOA split on his blog. Check it out!

June 07 2017

Jussi Pakkanen: Optimizing code: even the simplest things are unbelievably complex

In the previous post we looked at optimizing this simple function.

uint64_t result = 0;
for(size_t i=0; i<bufsize; i++) {
  if(buf[i] >= 128) {
    result += buf[i];
  }
}

We shall now do more measurements with real world hardware and compilers. The algorithms we use are the following:

  • simple: the above loop as-is
  • lookup: create a lookup table where entries less than 128 have value zero and the rest have the same value as the index
  • bit fiddling: convert the if into a branchless bitmask operation
  • partition: run std::partition on the data and only add the first half
  • zeroing: go over the data and set values not matching to zero, then add all
  • bucket: keep an array of 255 entries and count the number of times each number appears
  • multiply: convert if to a multiplication by 0 or 1, then add
  • parallel add: add several chars in a single packed 64 bit addition
Those interested in the actual implementations should look it up in the repo.

The hardware used is the following:

  • Raspberry Pi, Raspbian, GCC 4.9.2, Clang 3.5.0
  • Ubuntu zesty, GCC 6.3.0, Clang 4.0.0
  • Macbook Pro i5, XCode 8
  • Windows 10, Visual Studio 2017, run in VirtualBox
The test suite runs all available compilers with a selection of optimization types, CPU features (SSE, AVX, Neon etc) and measures the times taken.

The results


Let's start by looking at the simplest build setup.

This seems quite reasonable. Parallel addition is the fastest, others are roughly as fast and the two algoritms that reorder the input array are the slowest. For comparison Raspberry Pi looks like this:
Everything is much flatter as one would expect. Since everything is going smoothly, let's look at the first measurement again, except this time we sort the input data before evaluating. One would expect that the simple loop becomes faster because the branch predictor has an easier task, partitioning becomes faster and nothing becomes noticeably slower.
Well ... ummm ... one out of three ain't bad, I guess. At this point I should probably confess that I don't have a proper grasp on why these things are happening. Any speculation to follow might be completely wrong. The reason bucket slows down is the easier of these two to explain. Since the input is sorted, consecutive iterations of the loop attempt to write to the same memory address, which leads to contention. When the data was random, each iteration wrote to a random location which leads to fewer collisions.

The reason why the simple loop does not get faster may be caused by the processor evaluating both branches of the if clause in any case and thus having better branch prediction does not matter. On the other hand Visual Studio does this:

Bucket is slower for sorted as above, but the simple loop is an order of magnitude slower on unsorted data. Ideas on what could be the cause of that are welcome.

What is the fastest combination?

The fastest combination for each hardware platform is the following.
  • Ubuntu: bit fiddle, g++, release build, -msse, unsorted
  • Raspi: bit fiddle, g++, release build, -mfpu=neon, sorted
  • OSX: simple loop, Clang++, debugoptimized build, -msse4.2, sorted
  • VS2017: lut, debugoptimized build, unsorted
This is basically random. There does not seem to be any one algorithm that is consistently the fastest, every one of them is noticeably slower than others under some circumstances. Even weirder, things that you would expect to be straightforward and true are not. Here are some things to scratch your head over:
  • AVX instructions are never the fastest, and on an i7 the fastest is plain old SSE (for the record MMX was not tested)
  • With Clang, enabling Neon instructions makes everything a lot slower
  • On the Raspberry Pi doing a read only table lookup using Neon is slower than with regular instructions
  • On an i7 multiplication is sometimes faster than arithmetic shifting
Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl