Home Home > Security
Sign up | Login

Archive for the ‘Security’ Category

Manual encryption partition setup for stronger full disk encryption

May 26th, 2017 by

When installing openSUSE or SUSE Linux Enterprise, YaST is able to configure encrypted LVM using LUKS for full disk encryption. The default configuration is aes-xts-plain64 using a 256 bit master key. However, due to how the XTC mode splits the key into two halves, this reduces the effective key size used for AES to 128 Bits.

In order to use a 512 bit key for 256 effective AES, one needs to perform manual formatting prior to installation:
cryptsetup LuksFormat --key-size 512 /dev/sda1
However the installer suffers from boo#1030299 which prevents it from writing an entry to /etc/crypttab in this instance. This results in a system that is unable to boot after installation.

The work-around is as follows: Boot into the rescue system, open the crypto device and enter the installed system as a chroot:

cryptsetup luksOpen /dev/sda1 crypto
mount /dev/mapper/system-root /mnt
for X in proc dev sys; do mount -bind /$ /mnt/$X; done
chroot /mnt

(This example assumes /dev/sda1 to be the crypto device, and an LVM VG named system with a LV named root, and no separate /boot.)

Then in the chroot, edit /etc/crypttab to have the following line:

crypto /dev/sda1 none none

See man crypttab for additional settings and options. To finalize, regenerate the initrd and reboot


A future rewrite of the YaST storage abstraction layer is planned which should address this issue.

YaST development during Hack Week 15

March 7th, 2017 by

During this Hack Week, some of our team members invested quite some time working in YaST related projects. But, what’s even better, some people from outside the team worked also in YaST projects. Thank you guys!

So let’s summarize those projects and also some extra ones from our team members.

Let’s Encrypt made easy in openSUSE

Daniel Molkentin enjoyed his first Hack Week working together with Klaas Freitag to bring Let’s Encrypt integration to openSUSE. Although they didn’t had experience with YaST development, they followed the YaST tutorial and created a new brand yast-acme module. It’s still a work in progress, but it looks promising.

Managing certificates

You can get more details reading the Daniel Molkentin’s blog post about the project.

Removing perl-apparmor dependency

Goldwyn Rodrigues worked to remove the dependency of yast-apparmor on (now obsolete) perl-apparmor. There’s quite some work to do, but he’s heading in the right direction.

Find out more about the project in the Hack Week page and in Goldwyn’s fork.

gfxboot for grub2

Steffen Winterfeldt was working in gfxboot2, an attempt to provide a graphical user interface for grub2. Although it’s still a work in progress, it looks really good: module works for grub2-legacy and grub2-efi, basic font rendering is in place, language primitives are partly implemented, the integrated debugger already works…

You can find further information in the projects page.

YaST Integration Tests using Cucumber

The YaST team is always trying to improve their testing tools so Ladislav Slezák has been working in a proof of concept to use Cucumber to run YaST integration tests and the results are pretty impressive. The prototype is able to test YaST in an installed system, during installation and it can be used even for plain libyui applications outside YaST.

Test adding repository

Check out the details at project’s page and at Ladislav’s blog.

Keep working on libstorage-ng

If you follow YaST development, you know that the team is making good progress towards replacing the old libstorage. And even during Hack Week, libstorage-ng got some love from our hackers.

Arvin Schnell implemented support for more filesystems in libstorage-ng: ext2, ext3, ReiserFS, ISO 9660, UDF and basic support for NFS.

Iván López invested his first Hack Week improving yast2-storage-ng. Read this description to find out more information about the changes.

And last but not least, apart from helping Iván with his project, Ancor González worked in a new approach for yast2-storage-ng: instead of just extending the API offered by libstorage-ng, the idea is to wrap the library so the Ruby code using yast2-storage-ng does not have direct visibility on the libstorage-ng classes and methods.

More Ruby in YaST

Josef Reidinger is trying to reduce the amount of code in other languages different than Ruby. He successfully replaced the binary y2base with a Ruby version (not merged yet) and reduced the amount of Perl code in the yast2 package.

You can check the progress in yast-ruby-bindings#191 and yast-yast2#540 pull requests.

Support for Salt parametrizable formulas

YaST2 CM was born in 2016 as a proof of concept to somehow integrate AutoYaST with Software Configuration Management systems like Salt or Puppet.

During this Hack Week, Duncan Mac Vicar and Imobach González were working to implement support for Salt parametrizable formulas. You can find out more information in this post at Imobach’s blog.

Other non-YaST projects

Hack Week allows us to work in any project we want, so there’re also some non-YaST related projects that we would like to mention.

Improved QDirStat

QDirStat is a Qt-based tool which offers directory statistics. His author, Stefan Hundhammer,implemented some new features (like a better behavior when hovering over a tree map or improved logging) and fixed some bugs. Find out more details in the project’s README and the version 1.3 release notes.

He also wrote an article about how to use the application in headless systems (no X server, no Xlibs).

Current version is already available at software.opensuse.org so you could consider giving it a try.

Learning new things

Hack Week is a great opportunity to play with new stuff. With that idea in mind, Martin Vidner learned about Android development and wrote detailed instructions for starting with that: Getting Started in Android Development: Part 1: Building the First App, Part 2: Publishing the First App and Part 3: Reducing Bloat.

Knut Anderssen decided to try also some mobile development and enjoyed playing around with the Ionic.

And that’s all! After Hack Week, we’re back to SCRUM and we’re now working sprint 32. We’ll give you additional details in our next “Highlights of YaST development” report.

Stay tunned!

Official RPM package : OWASP ZAP

January 6th, 2017 by

The world is going through a security crisis, so I make the official packages available in openSUSE, SUSE Enterprise, CentOS, Fedora e RedHat.

Thank you, Mauro Risonho de Paula Assumção e Simon Bennetts.

Link for download: https://software.opensuse.org/download.html?project=home%3Acabelo&package=owasp-zap

Next: openSUSE hardening

September 15th, 2014 by


Running the rolling openSUSE Factory has been smooth so far, no problems since the last post.

I have been involved in submitting new packages (ftop, dstat, some perl modules), patching other’s existing packages (dnsmasq) and of course taking after packages that I maintain (btrfsprogs). With a very few exceptions I’ve got done everything I needed, the exceptions were my rather silly mistakes. The damage is only the first few seconds when one realizes that the submit request was ‘rejected’. Don’t get bored by it, grab a coffee or go fix it later. Need to say the rejects are backed by a reason or explanation what’s wrong and what should be fixed in the next attempt. Learn from that, take notes, read the docs again. Once this becomes common, the amount of basic mistakes is near to zero, the self-checks become a routine. This makes a happy contributor and the distro maintainers too.

I recommend to skim the factory snapshots announcements, look at the changes or scroll down to the newly added ones. One day you can see your contributions there, go for it.

Before something goes to the Factory distro, the packages are getting ready in the devel projects. I’ve asked for maintainership of filesystems and benchmark projects and did some fixing in packages I use or at least recognize. The state of the projects is not ‘all-green’, build failures exist, but without some motivation I’m not rushing to fix them.

If you are interested (as a user) in a package from those devel projects, feel free to bug me about it. I can help with fixing build failures or submitting to Factory.


All of the above is a routine. A routine of making the distro better on the core side. There’s never enough of it and it may become boring (oh it does) over time. Out of the many research projects and experimenting I do, I decided to focus on one that’s definetely related to openSUSE, is fun, is important, useful and is not there yet.

openSUSE hardening!

“No way, really? But there’s AppArmor and SElinux enabled and the compile-time hardening options.

Yeah. I won’t repeat the arguments why AppArmor and SElinux are insufficient, functionally or usability-wise. So what’s left? Grsecurity, of course. Sadly openSUSE lacks even the unofficial grsecurity-patched kernels unlike Arch, Debian or Gentoo. Sadly2, the patched kernels are unofficial and will remain at that state until grsec is upstream. I don’t dare to predict if/when this will happen.

I’m aware of only the NetSecL distribution based on openSUSE that offered the grsec kernels, but it’s discontinued.

My hardening efforts got the codename openSUSE-gardening and are hosted in my github repository of the same name. The wiki contains more comprehensive information. It’s still work in progress and does not cover all topics in detail but should be enough to get started.

Quite unexpectedly, spender found the repo and gave it a bit of publicity on twitter. Thanks man 🙂

My plan was to update all relevant packages, test the kernels a bit, update the wiki and then post about that here. Nah, I got the right kick to do it now.

Quick start is really simple, a pattern that installs all necessary packages for a desktop use:

One-click install for 13.1
One-click install for Factory

Note, you’ll probably need to run linux-pax-flags before the first reboot, it will apply PaX flag exceptions, some binaries may crash due to the protections (like window manager processes, browsers). Once the zypper plugin is properly installed, the flags get updated automatically.

Warning: the patched kernel has not been extensively tested, works for me, might not work for you.

To be continued …

And done…. new images available

June 12th, 2014 by


It took a bit but I am happy to report that all openSUSE 13.1 images in Amazon EC2, Google Compute Engine and Microsoft Azure public cloud environments have been refreshed. After the latest round of the GNU-TLS and OpenSSL fixes the security was, as usual, extremely efficient in providing fixed packages and these have been available in all cloud images via zypper up since last Friday. As of today the base images available in the public cloud frameworks contain the fixes by default.

In Amazon the new images are as follows:

  • ap-northeast-1: ami-79296078
  • ap-southeast-1: ami-84a7fbd6
  • ap-southeast-2: ami-41cbae7b
  • eu-west-1: ami-b56aa4c2
  • sa-east-1: ami-bffb54a2
  • us-east-1: ami-5e708d36
  • us-west-1: ami-16f2f553
  • us-west-2: ami-b7097487

In Google compute engine the image name is: opensuse-13-1-v20140609

The old image (opensuse131-v20140417) has been deprecated. To access the image you will need to add –image=opensuse-cloud/global/images/opensuse-13-1-v20140609 as the openSUSE images are not yet fully integrated into the GCE framework. Still working on that part with Google. This image also has upgrades to the google-cloud-sdk package and enable the bq (big-query) command. The gcloud command is still a bit rough around the edges, but the gcutil command should work as expected. Eventually gcutil is going to be deprecated by Google thus there is work to be done to fix the integration issues with the gcloud command. If anyone has time to work on that please send submit request to the google-cloud-sdk package in the Cloud:Tools project in OBS. Unfortunately Google still hasn’t posted the source anywhere for open collaboration 🙁 . They’ll get there eventually. I will try and push any changes upstream.

In Azure just search for openSUSE in the Gallery, it’s more of a point an click thing 😉

And that’s a wrap. Not certain we will be able to improve on the speed of such fire drill updates, but we’ll try to keep refreshing images as quickly as time allows when critical vulnerabilities in the core libraries get exposed.

Have a lot of fun….

mounting TrueCrypt volumes in GNU/Linux using cryptsetup

January 12th, 2014 by

cryptsetup as of 1.6, which shipped in openSUSE 13.1, is able to mount TrueCrypt volumes without the use of TrueCrypt code otherwise, which I previously noted is problematic due to it’s license, at least for inclusion in the openSUSE distribution.

Here, then, is how you mount it:

cryptsetup open --type tcrypt /var/run/media/username/volume_name encrypted_volume
mount /dev/mapper/encrypted_volume /mnt

For read only access, add --readonly and -o ro respectively. When done:

umount /mnt
cyrptsetup close encrypted_volume

See man 8 cryptsetup for all details and options.

Factory Progress 2011-07-01

July 1st, 2011 by

Here’s with some delay the next incarnation of Factory Progress. I’ve noticed the following changes that might interest people using and developing openSUSE Factory:

Package changes

Linux 3.0

Linux kernel 3.0 rc5 is currently on its way to factory and the header files (in package linux-glibc-devel) have already been updated for it. If your software reads the Linux kernel version, please check that it can cope with the two digits instead of the three of the new version. Best would be to not read the version at all.


Frederic has proposed a “Road to systemd for openSUSE 12.1″. Systemd is a replacement of the SysVinit scripts that we have been using and improving in the past with many new – including some controversial – ideas. Check his blog post for additional references about systemd. The majority of the distributions are moving to systemd as well and standarizing on it, will allow to share some more code and development in this area.

We’re now in phase 1 – which means: Get systemd running as an option. Once this is working satisfactory, we can switch the default (phase 2) and decide what to do with SysVinit support.


Securing the future of openSUSE

April 1st, 2011 by

As a valued member of the openSUSE community, we couldn’t wait to bring you the good news. This post is to announce the release of a new security-oriented resource  currently being generated for the openSUSE/Novell suite of products and submitted to National Institute of Standards and Technology(NIST) as a definitive resource from which to assess and report upon the machine state of computer systems. Well, maybe we haven’t thought of a great logo or slogan for it yet, but if you read on I think you’ll agree that no matter what we call it, it’s super!

Starting on Friday, April 01 2011, a record for each security announcement released through the opensuse-security-announce mailinglist will be maintained on a cumulative basis within the Amazon EC2 Cloud for general public review and use. Once an announcement has reached our email inbox, we will be automatically generating a specifically formatted intermediate XML source code object.

The email is parsed using custom-built PERL Modules and a data structure is populated. The following construct presents an example view of the Novell array structure:


Securing SSH (Secure Shell) from attacker

March 22nd, 2011 by

Secure Shell or SSH is a network protocol that allows exchange of data through secure channels between two network devices.

Particularly widely used on Linux and Unix-based system to access your shell, SSHwas designed as a substitute for Telnet and other insecure remote shells, which sentinformation, especially passwords, in the form of simple text that makes it easy to be intercepted. Encryption used by SSH provides confidentiality and integrity of dataover an insecure network like the Internet.

For the Security Server We From Attacks The attacker who usually Always Use SSHAs a door Early Entry Into System To us, of course, become an admin obligation todispel various Efforts That.

There are several ways which ordinary people do to secure SSH from a variety ofattacks which one of them is by editing the file / etc / ssh / sshd_config.

before doing the configuration in the file / etc / ssh / sshd_config make sure SSH isinstalled on your linux distribution, and for openSUSE that I use it already automatically installed.

#vim /etc/ssh/sshd_config

change options, as below :

LoginGraceTime 2m
PermitRootLogin no
MaxAuthTries 3

LoginGraceTime which option is used to give a time limit of user logins, so please change these options according to your wishes.

PermitRootLogin is no option to allow the root user can login to ssh or not to give yes or no value on the options tersebut.sebaiknya give no value, so that users can not loginas root into your ssh.

MaxAuthTries 3 to give the limit on the number of errors allowed when the user logs in,this is very useful to avoid attackers do brute force on the server anda.dimana usersonly allowed to make a mistake typing the password in accordance with that alreadyset on the options.

If you want only certain users who may log into your ssh add AllowUsers option at the end of the line followed by a distinguished user name in the allowed login.

otherwise, you can install software, denyhost, for your ssh security

NB:do not enable the root user, for ssh login

Similarly, a fairly simple tutorial .. hopefully this can be useful.

Best Regards
Saydul Akram
Email : idulk@opensuse.org

updated permissions handling in 11.4

November 24th, 2010 by

In addition to supporting file system capabilities (fate#307254) I’ve also updated the permissions handling in 11.4 slightly.

There have been complaints that every SuSEconfig run also calls SuSEconfig.permissions which leads to changed file permissions at unexpected times. Therefore I’ve modified SuSEconfig.permissions to only actually set permissions when called explicitly (ie SuSEconfig –module permissions). When called by a generic SuSEconfig run SuSEconfig.permissions now only shows files with wrong permissions but doesn’t actually fix them anymore.

Since packages that have files with special permission handling do call SuSEconfig.permissions explicitly via %run_permissions in %post the change above alone isn’t sufficient to avoid surprises. Therefore I’ve introduced the new macro %set_permissions. This macro expects file names as arguments. Only permissions of those files are adjusted then. To notify packagers of that new method an rpmlint check now issues an informal message if %run_permissions is used.