Testing chrony seccomp support
by Miroslav Lichvar
In chrony 2.2-pre1 was added support for system call filtering with
the kernel seccomp facility. In chrony it's mainly useful to reduce
the damage from attackers who can execute arbitrary code, e.g. prevent
gaining the root privileges through a kernel vulnerability.
The rawhide chrony package is now compiled with the seccomp support,
but the filtering is not enabled by default. The trouble is it has to
cover all system calls needed in all possible configurations of chrony
and all libraries it depends on, which is difficult and it may even
change over time as the libraries are updated.
I'm interested to know if this works in other configurations than what
I tried, especially non-default NSS configurations, and get an idea if
this could be enabled by default at some point.
If you would like to help with the testing:
1. echo 'OPTIONS="-F -1"' > /etc/sysconfig/chronyd
2. systemctl restart chronyd
3. occasionally check if chronyd is still running
If you see in the log that the process was killed with status=31/SYS,
it's a problem in the seccomp support. Please let me know it has
crashed for you. Unfortunately, abrt doesn't seem to catch these
crashes, even when /proc/sys/fs/suid_dumpable is set to 2.
For F22 and F23 there is a COPR repo with packages built from the
current development code:
https://copr.fedoraproject.org/coprs/mlichvar/chrony/
Thanks,
--
Miroslav Lichvar
8 years, 3 months
Fedora 23 cloud image (and, for that matter, minimal anything) bloat
by Matthew Miller
Fedora-Cloud-Base-20141203-21.x86_64.qcow2: 151M
Fedora-Cloud-Base-23_Beta-20150915.x86_64.qcow2: 275M
In just one year — 82% more awesome?
I'd really like this to stay below 200MB as a competitive threshold.
Or, if we're going to be bigger than that, be bigger for REASONS, not
just accretion.
tl;dr: grub2 is a lot to blame, but there seem to be some new
questionable dep chains from systemd, and general dep growth across the
board.
Disk use at first boot:
[f21]$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 20G 359M 19G 2% /
[f23b]$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 20G 578M 19G 4% /
RPMs installed:
[f21]$ rpm -qa | wc -l
226
[f23b]$ rpm -qa | wc -l
264
Top 20 rpms by reported size:
$ rpm -qa --qf '%{size} %{name}\n'|sort -nr|head -20
120417342 glibc-common
42307839 kernel-core
25000497 python-libs
22438155 systemd
14623272 coreutils
14000291 glibc
11282056 ruby-libs # hey, at least we lost this
10845519 glib2
10593004 selinux-policy-targeted
9389116 cracklib-dicts # https://bugzilla.redhat.com/show_bug.cgi?id=865521
9078043 python-boto
8792531 util-linux
7084188 bash
6669884 gnupg2
5844544 yum
4893790 policycoreutils
3786564 file-libs
3540004 shadow-utils
3458312 groff-base # who doesn't love groff?
2997717 tar
$ rpm -qa --qf '%{size} %{name}\n'|sort -nr|head -20
125195206 glibc-common
86298752 linux-firmware # sadface, but hard
53291365 kernel-core
36004297 grub2-tools # this is ridiculous
28453336 python3-libs # 13% growth
27233273 systemd # 21% growth
16648994 grub2 # *sigh*
14486819 glibc
14287847 coreutils # this package got _smaller!_
11143743 glib2
11129880 selinux-policy-targeted
9389116 cracklib-dicts
9261499 python3-boto
9237998 util-linux
9224255 fedora-logos # this is also grub's fault.
7517574 gnupg2
7143418 bash
6574678 python3-pip # :(
5888883 hwdata # this is ALSO grub's fault
5423400 xkeyboard-config # really???? looks like a systemd dep chain
involving plymouth
Okay, let's look on disk:
[f21]$ sudo du -sh * 2>/dev/null|sort -h
[...]
36K home
40K root
228K run
21M boot
22M etc
34M var
276M usr
[f23b]$ sudo du -sh * 2>/dev/null|sort -h
[...]
40K root
264K run
16M etc
45M boot # ugh
171M var # oww
463M usr # oww oww oww
Breakdown:
- boot is mostly grub, but initramfs is also doubled
- var: DNF cache is full of stuff! 123M... oh, hey, that wasn't
there when we booted. `df -h /` is now up to 702M. Maybe multiple
repos would help here, or some other more clever design. Does
every cloud image in the world _really_ need to replicate
dependency data so I can `dnf install
/usr/share/minetest/builtin/mainmenu/init_simple.lua`?
- usr:
* linux-firmware is the biggest thing here
* python3 is another good chunk
* also kernel modules, but, eh, whatchagonnado
* oh, and of course, grub2.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8 years, 4 months
On running gui applications as root
by John Dulaney
Recently, I filed a bug (1274451) about running virt-manager on Wayland.
As it turns out that this is applicable to running gui applications as
root on Wayland in general, the scope was changed (see Cole's comments).
As Halfline points out, the decision needs to be made whether to allow
gui applications to be run as root. I figured I'd bring this up for
discussion in the hopes that a decision may be made whether or not to
allow this.
In the instance that the decision is made to not allow gui applications
root access, then we will also need to figure out a sane way to have
applications that require more than the usual set of user priviledges to
continue to work across multiple compositors and window managers that
may or may not have the necessary authentication agents built-in.
John.
8 years, 5 months
ansible in Fedora 23+ (python3)
by Dusty Mabe
Hey all,
Just wondering if anyone has started to feel any pain from trying to
use ansible with F23 systems. As part of the Fedora Cloud working
group it would be nice to ship a system that could be targeted by
ansible out of the box. Unfortunately, since ansible uses python 2.X
vs python 3 it doesn't really work.
A simple answer would be to "just install python", but I actually hit
several roadblocks because of python packages that are usually there
but have been replaced by their python 3 counterparts. As an example
for one ansible playbook like [1] I had to install these rpms in order
to get it to work:
python libselinux-python python-dnf python-docker-py
Unfortunately there isn't a catchall that is a workaround for this
problem because the libraries you need on the system depend on the
modules you will use.
Does anyone have a good solution for this? Obviously it would be nice
if ansible went to python3 but I think they have stated clearly that
they are sticking with python2 for backwards compat with systems that
still need 2.4.
-Dusty
[1] - https://github.com/dustymabe/vagrantdirs/blob/master/f22/playbook.yml
8 years, 5 months
Review swaps
by Jerry James
I need two packages reviews:
1. arb: https://bugzilla.redhat.com/show_bug.cgi?id=1272606
This is a FLINT add-on that newer versions of sagemath want.
2. gap-pkg-grape: https://bugzilla.redhat.com/show_bug.cgi?id=1273244
I finally figured out how to adapt this package so that it uses the
free bliss package, which we have in Fedora, instead of the non-free
nauty, which cannot be in Fedora. The changes have been submitted
upstream. After this, we can easily add the semigroups, gpd, and XMod
gap packages, and then we have to figure out what to do about the
FTBFS homology and singular packages before finally arriving at the
HAP package, which sagemath wants. Whew!
Let me know what I can review for you in exchange.
--
Jerry James
http://www.jamezone.org/
8 years, 5 months