[systemd-devel] Does systemd-nspawn support running systemd in a user namespace
We are seeing issues attempting to do this with docker/runc. Basic problem is /sys/fs/cgroup/systemd is owned by real root. Is there something we need to change in runc, to make this directory owned by UserNamespace-Root? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Issues with docker systemd cgroups integration
Expanding this out to systemd-devel mailing list. On 03/14/2016 01:04 PM, Mrunal Patel wrote: Hi, Lukas, We are using systemd cgroups support in docker for Fedora/RHEL and seeing some issues. Here is the flow of the code in docker/runc/libcontainer: 1. We create a Transient Unit setting some properties based on what the user passed or defaults. For e.g. /system.slice/docker-abcd.scope 2. We then manually join other cgroups subsystems such as devices by creating the directory /sys/fs/cgroup/devices/system.slice/docker-abcd.scope. This is done so we can support cgroups that aren't directly supported by systemd To see the code you can refer to https://github.com/projectatomic/docker/pull/71/files (In this PR, I made the change to always join all the subsystems after creating the scope to help with first issue below). There are two classes of issues that are cropping up (especially under load): 1. Sometimes a cgroup isn't joined even though it is passed as a property while creating a Transient Unit. For e.g. CPUShares are specified, however the transient unit doesn't seem to join the cpu,cpuacct subsystem. 2. cpu.proc file itself goes missing especitally with the devices subsystemd even thought we mkdir the directory and write to the file. It is as if the file gets deleted by some other process. What can we do to fix these issues? Thanks, Mrunal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I want to run systemd inside of a locked down base docker container
On 02/10/2016 05:21 PM, Lennart Poettering wrote: > On Wed, 10.02.16 16:43, Daniel J Walsh (dwa...@redhat.com) wrote: > >>>>> I don't see why one would want to mask systemd-logind.service. If you >>>>> permit logins and PAM at all, you really need that. >>>> If I wanted to add a login program I could enable/unmask these. >>>> No one runs docker containers as login services, that would require >>>> getty. >>> Well, "machinectl shell", "cron" and all those things do PAM... In >>> fact the fact that "machinectl shell" goes through PAM and registers >>> with logind through that is one of the major benefits over naked >>> "nsenter". >> I wonder if any of these work correctly inside of a docker container? >> >> Can these be customized or do they require systemd as pid 1 inside of >> the container. Docker has a "docker exec" > No, "machinectl shell" requires PID 1 in the container to be systemd. > > Unlike "nsenter" (and docker exec, as I presume), "machinectl shell" > will not try to take a process from the host and patch around in its > process attributes until it appears to be a process from within the > container (by joining namespaces, cgroups, uids, gids, selinux labels, > audit creds, …). It will instead allocate a pty in the container and > then use ask systemd inside the container using the "transient units" > API to spawn a shell on it. It then does nothing else than forward > data between this pty and the tty it was invoked from. > > This way the only processes you see in the container have actually > been started by systemd inside the container. They are properly > tracked and maintained like any other process invoked in the container > by the systemd instance that is running it. They inherit the process > attributes from PID 1 in the container, and the PPID reported for them > will actually be 1 as it should. – They are not these weird alien > processes like nsenter creates that are half-way part of the host > system and half-way member of the container, for which PPID returns 0 > in the container, because they actually don't have a parent process > inside of the container. > > Long story short: "machinectl shell" should work fine even with docker > containers – as long as systemd runs as PID 1 in them. > >>> I added this to the TODO list now. >> Sounds fine with me. I went back to the original container and I can >> remove all of the other modifications, I can live with the warnings at the >> beginning and remove the /etc/fstab. We just need to get this into more >> people hands to see what happens and what breaks. > Quite frankly, I don't understand why /etc/fstab is populated at all > on Fedora by default. It should only exists if there are actual > external file systems configured in it, and otherwise just not exist. > >> This is what I am seeing now with just /etc/fstab removed. >> >> Welcome to Fedora 23 (Twenty Three)! >> >> Set hostname to <654f7872d331>. >> dev-hugepages.mount: Cannot add dependency job, ignoring: Unit >> dev-hugepages.mount is masked. >> sys-fs-fuse-connections.mount: Cannot add dependency job, ignoring: Unit >> sys-fs-fuse-connections.mount is masked. >> systemd-remount-fs.service: Cannot add dependency job, ignoring: Unit >> systemd-remount-fs.service is masked. >> systemd-logind.service: Cannot add dependency job, ignoring: Unit >> systemd-logind.service is masked. >> getty.target: Cannot add dependency job, ignoring: Unit getty.target >> is masked. > Again, there should be no need to mask dev-hugepages.mount and > getty.target at all. And if you drop /etc/fstab there's no need to > mask systemd-remount-fs.target either. Please unmask those three > units! > > As soon as my patch to add the ConditionCapability= check to > sys-fs-fuse-connections.mount you should also be able to unmask that > unit and get a clean boot. > > Lennart > I am now masking nothing, just removing /etc/fstab. We will probably need to back port the dev-hugepages.mount fix to rhel7 at some point. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] I want to run systemd inside of a locked down base docker container
On Fedora I see a few services starting up and failing when I run systemd, I have been able to disable these by executing. RUN systemctl disable sysinit.target remote-fs.target systemd-remount-fs;\ systemctl mask systemd-firstboot initrd-udevadm-cleanup-db.service systemd-udev-settle.service systemd-udev-trigger.service systemd-udevd.service systemd-udevd-control.socket systemd-udevd-kernel.socket; \ rm -f /lib/systemd/system/multi-user.target.wants/systemd* /lib/systemd/system/multi-user.target.wants/getty*;\ sed -i 's/^enable/disable/g' /lib/systemd/system-preset/* Could someone look at these and tell me if I went too far. I would like to get these commands as the default for systemd in the base RHEL/Fedora and Centos containers. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I want to run systemd inside of a locked down base docker container
On 02/10/2016 11:16 AM, Lennart Poettering wrote: > On Wed, 10.02.16 10:56, Daniel J Walsh (dwa...@redhat.com) wrote: > >> On Fedora I see a few services starting up and failing when I run >> systemd, I have been able to disable these >> by executing. >> >> RUN systemctl disable sysinit.target remote-fs.target >> systemd-remount-fs;\ > sysinit.target and systemd-remount-fs.service are static units; they > cannot be enabled via "systemctl enable" or disabled via "systemctl > disable". That part should be a NOP and should not have any effect; > you can drop it. > > remote-fs.target has no value either, unless there actually are NFS > mounts listed in /etc/fstab. I am pretty sure there aren't any for in > your container, are there? Hence, this really sounds like something > you can drop too, without any change in behaviour. I was seeing failed mounts inside the container until I removed these. I can remove these lines to see if the failed mounts come back. But there should be nothing in the container that does a mount, unless someone put bogus stuff in the Fedora base container. This is what the dockerfile looks like that I am building and testing with systemd. ``` Cat Dockerfile FROMfedora:23 MAINTAINER Dan Walsh ENV container docker RUN dnf -y install httpd; dnf clean all; systemctl enable httpd; systemctl disable dnf* dnf-makecache.timer RUN systemctl disable sysinit.target remote-fs.target systemd-remount-fs;\ systemctl mask systemd-firstboot initrd-udevadm-cleanup-db.service systemd-udev-settle.service systemd-udev-trigger.service systemd-udevd.service systemd-udevd-control.socket systemd-udevd-kernel.socket; \ rm -f /lib/systemd/system/multi-user.target.wants/systemd* /lib/systemd/system/multi-user.target.wants/getty*;\ sed -i 's/^enable/disable/g' /lib/systemd/system-preset/* EXPOSE 80 CMD [ "/sbin/init" ] ``` >> systemctl mask systemd-firstboot initrd-udevadm-cleanup-db.service >> systemd-udev-settle.service systemd-udev-trigger.service >> systemd-udevd.service systemd-udevd-control.socket >> systemd-udevd-kernel.socket; \ > The systemd-firstboot service should have no effect unless you > actually boot with an empty /etc (or more accuratily: unless you > actually boot with an /etc that lacks /etc/machine-id) . Note that it > carries a condition ConditionFirstBoot=yes which makes sure that it > isn't even executed in normal cases. I see in the logs systemd complaining about no systemd-firstboot command. > Masking all the udev stuff is pretty pointless too. These services are > conditioned out in containers too anyway. There's really no need to > mask them out. More specifically, they contain > ConditionPathIsReadWrite=/sys, i.e. are skipped if /sys is read-only, > which is the way how container managers should set up /sys (it's a big > security hole to allow containers write access to /sys). My > recommendation would be to make sure you container manager implements > these recommendations: I am just seeing mentions of udev inside of the container, What I don't want is messages inside of the journal or bootup that look like systemd is trying to run firstboot, udev etc. > https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/ > > If your container manager follows these guidelines (of which the /sys > being read-only thing is one), then there should be no special hacks > necessary in systemd, as it should just work, and detect the slight > semantica changes of containers correctly and avoid them cleanly. > >> rm -f /lib/systemd/system/multi-user.target.wants/systemd* >> /lib/systemd/system/multi-user.target.wants/getty*;\ > What's the rationale for this? First of all, the getty stuff appears > entirely unnecessary as getty@.service (which is the only thing > generally linked from gettys.target these days) contains > ConditionPathExists=/dev/tty0 which means it's already skipped when > run on systems lacking a VC (such as containers). Again, I am seeing getty@ failures inside of the container. > And the other services you are removing here: what's the point? they > aren't really optional, that's why they are linked from /usr/lib, > rather than subject to systemctl enable/disable... > >> sed -i 's/^enable/disable/g' /lib/systemd/system-preset/* > Why would this matter? We don't want excess services running inside of a docker container. I only want systemd/journald and any services that I enable in the container. Not something pulled in because the installer thinks this is a VM or a Host OS. > >> Could someone look at these and tell me if I went too far. I would like to >> get these commands as the default for systemd in the base >> RHEL/Fedora and Centos containers
Re: [systemd-devel] I want to run systemd inside of a locked down base docker container
On 02/10/2016 11:16 AM, Lennart Poettering wrote: > On Wed, 10.02.16 10:56, Daniel J Walsh (dwa...@redhat.com) wrote: > >> On Fedora I see a few services starting up and failing when I run >> systemd, I have been able to disable these >> by executing. >> >> RUN systemctl disable sysinit.target remote-fs.target >> systemd-remount-fs;\ > sysinit.target and systemd-remount-fs.service are static units; they > cannot be enabled via "systemctl enable" or disabled via "systemctl > disable". That part should be a NOP and should not have any effect; > you can drop it. > > remote-fs.target has no value either, unless there actually are NFS > mounts listed in /etc/fstab. I am pretty sure there aren't any for in > your container, are there? Hence, this really sounds like something > you can drop too, without any change in behaviour. > >> systemctl mask systemd-firstboot initrd-udevadm-cleanup-db.service >> systemd-udev-settle.service systemd-udev-trigger.service >> systemd-udevd.service systemd-udevd-control.socket >> systemd-udevd-kernel.socket; \ > The systemd-firstboot service should have no effect unless you > actually boot with an empty /etc (or more accuratily: unless you > actually boot with an /etc that lacks /etc/machine-id) . Note that it > carries a condition ConditionFirstBoot=yes which makes sure that it > isn't even executed in normal cases. > > Masking all the udev stuff is pretty pointless too. These services are > conditioned out in containers too anyway. There's really no need to > mask them out. More specifically, they contain > ConditionPathIsReadWrite=/sys, i.e. are skipped if /sys is read-only, > which is the way how container managers should set up /sys (it's a big > security hole to allow containers write access to /sys). My > recommendation would be to make sure you container manager implements > these recommendations: > > https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/ > > If your container manager follows these guidelines (of which the /sys > being read-only thing is one), then there should be no special hacks > necessary in systemd, as it should just work, and detect the slight > semantica changes of containers correctly and avoid them cleanly. > >> rm -f /lib/systemd/system/multi-user.target.wants/systemd* >> /lib/systemd/system/multi-user.target.wants/getty*;\ > What's the rationale for this? First of all, the getty stuff appears > entirely unnecessary as getty@.service (which is the only thing > generally linked from gettys.target these days) contains > ConditionPathExists=/dev/tty0 which means it's already skipped when > run on systems lacking a VC (such as containers). > > And the other services you are removing here: what's the point? they > aren't really optional, that's why they are linked from /usr/lib, > rather than subject to systemctl enable/disable... > >> sed -i 's/^enable/disable/g' /lib/systemd/system-preset/* > Why would this matter? > >> Could someone look at these and tell me if I went too far. I would like to >> get these commands as the default for systemd in the base >> RHEL/Fedora and Centos containers. > I don't follow at all. > > None of this is necessary. systemd works fine in containers as long as > the container manager follows these guidelines: > > https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/ > > nspawn implements all of this, and docker really should too... > > Lennart > BTW With the latest code/hooks we now have /sys as readonly /tmp and /run on tmpfs. /etc/machine-id created to match containerid. /var/log/journald/UUID mounted from the host so that journalctl -M UUID will work. Docker containers registered with machinectl. These are the processes run after launching the systemd based container. system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29042 ? 00:00:00 systemd system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29076 ? 00:00:00 systemd-journal system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29093 ? 00:00:00 dbus-daemon system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29094 ? 00:00:00 httpd system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29099 ? 00:00:00 httpd system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29100 ? 00:00:00 httpd system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29102 ? 00:00:00 httpd system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29104 ? 00:00:00 httpd system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29107 ? 00:00:00 httpd ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I want to run systemd inside of a locked down base docker container
On 02/10/2016 01:14 PM, Lennart Poettering wrote: > On Wed, 10.02.16 11:36, Daniel J Walsh (dwa...@redhat.com) wrote: > >>>> systemctl mask systemd-firstboot initrd-udevadm-cleanup-db.service >>>> systemd-udev-settle.service systemd-udev-trigger.service >>>> systemd-udevd.service systemd-udevd-control.socket >>>> systemd-udevd-kernel.socket; \ >>> The systemd-firstboot service should have no effect unless you >>> actually boot with an empty /etc (or more accuratily: unless you >>> actually boot with an /etc that lacks /etc/machine-id) . Note that it >>> carries a condition ConditionFirstBoot=yes which makes sure that it >>> isn't even executed in normal cases. >> I see in the logs systemd complaining about no systemd-firstboot >> command. > Well, what have you installed in the container? Is the > systemd-firstboot binary there? If not, why not? If this has been > split out of the core package, then the service unit for it should > have been split out too, hence there shouldn't be any error about this. > >>> Masking all the udev stuff is pretty pointless too. These services are >>> conditioned out in containers too anyway. There's really no need to >>> mask them out. More specifically, they contain >>> ConditionPathIsReadWrite=/sys, i.e. are skipped if /sys is read-only, >>> which is the way how container managers should set up /sys (it's a big >>> security hole to allow containers write access to /sys). My >>> recommendation would be to make sure you container manager implements >>> these recommendations: >> I am just seeing mentions of udev inside of the container, What I don't >> want is messages >> inside of the journal or bootup that look like systemd is trying to run >> firstboot, udev etc. > Sure, that's precisely what the ConditionXYZ= constructs are for: to > skip stuff silently that is not necessary in some cases. > > And by default systemd comes with all the the conditions in place so > that a vanilla systemd image should work fine that implements the > container interface. > >>> https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/ >>> >>> If your container manager follows these guidelines (of which the /sys >>> being read-only thing is one), then there should be no special hacks >>> necessary in systemd, as it should just work, and detect the slight >>> semantica changes of containers correctly and avoid them cleanly. >>> >>>> rm -f /lib/systemd/system/multi-user.target.wants/systemd* >>>> /lib/systemd/system/multi-user.target.wants/getty*;\ >>> What's the rationale for this? First of all, the getty stuff appears >>> entirely unnecessary as getty@.service (which is the only thing >>> generally linked from gettys.target these days) contains >>> ConditionPathExists=/dev/tty0 which means it's already skipped when >>> run on systems lacking a VC (such as containers). >> Again, I am seeing getty@ failures inside of the container. > That would suggest that there's a /dev/tty0 in the container? That > looks really wrong... A container has no virtual console hence there > should be no /dev/tty0. > On Linux /dev/tty0 is a special device node that is part of the > kernel's VC subsystem, and points to the VC currently in the > foreground. It has no place in virtualized systems such as containers. > What is docker mounting as /dev into the container? Does it just bind > mount the host /dev? That's really nasty, as that will expose host > devices and device node ownership to the containers. They really > shouldn't do that and instead mount their own tmpfs to /tmp and just > create the device nodes for /dev/null, /dev/random and so on, but > nothing else. They don't, they create their own /dev inside the container with locked down devices. ls -lZ /dev/ total 0 crw---. 1 root root system_u:object_r:svirt_sandbox_file_t:s0:c15,c706 136, 3 Feb 10 20:42 console lrwxrwxrwx. 1 root root system_u:object_r:svirt_sandbox_file_t:s0:c15,c706 13 Feb 10 20:42 fd -> /proc/self/fd crw-rw-rw-. 1 root root system_u:object_r:svirt_sandbox_file_t:s0:c15,c706 1, 7 Feb 10 20:42 full c-. 1 root root system_u:object_r:svirt_sandbox_file_t:s0:c15,c706 10, 229 Feb 10 20:42 fuse lrwxrwxrwx. 1 root root system_u:object_r:svirt_sandbox_file_t:s0:c15,c706 11 Feb 10 20:42 kcore -> /proc/kcore drwxrwxrwt. 2 root root system_u:object_r:svirt_sandbox_file_t:s0:c15,c706 40 Feb 10 20:42 mqueue crw-rw-rw-. 1 root root system_u:object_r:svirt_sandbox_file_t:s0:c15,c706 1, 3 Feb 10 20:42 null lrwxrwxrwx. 1 root root
Re: [systemd-devel] I want to run systemd inside of a locked down base docker container
On 02/10/2016 01:41 PM, Lennart Poettering wrote: > On Wed, 10.02.16 10:22, Ranjib Dey (dey.ran...@gmail.com) wrote: > >> Docker(ls -alh) >> >> crw--- 1 root root 136, 9 Feb 10 18:20 console >> lrwxrwxrwx 1 root root 13 Feb 10 18:20 fd -> /proc/self/fd >> crw-rw-rw- 1 root root 1, 7 Feb 10 18:20 full >> c- 1 root root 10, 229 Feb 10 18:20 fuse >> lrwxrwxrwx 1 root root 11 Feb 10 18:20 kcore -> /proc/kcore >> drwxrwxrwt 2 root root 40 Oct 30 08:01 mqueue >> crw-rw-rw- 1 root root 1, 3 Feb 10 18:20 null >> lrwxrwxrwx 1 root root8 Feb 10 18:20 ptmx -> pts/ptmx >> drwxr-xr-x 2 root root0 Feb 10 18:20 pts >> crw-rw-rw- 1 root root 1, 8 Feb 10 18:20 random >> drwxrwxrwt 2 root root 40 Feb 10 18:20 shm >> lrwxrwxrwx 1 root root 15 Feb 10 18:20 stderr -> /proc/self/fd/2 >> lrwxrwxrwx 1 root root 15 Feb 10 18:20 stdin -> /proc/self/fd/0 >> lrwxrwxrwx 1 root root 15 Feb 10 18:20 stdout -> /proc/self/fd/1 >> crw-rw-rw- 1 root root 5, 0 Feb 10 18:20 tty >> crw-rw-rw- 1 root root 1, 9 Feb 10 18:20 urandom >> crw-rw-rw- 1 root root 1, 5 Feb 10 18:20 zero > This looks pretty OK actually. With this setup (i.e. where /dev/tty0 > does not exist) it seems entirely unnnecessary to mask the getty > services or anything, as they contain a condition (as mentioned) that > skips them if this device node does not exist. > >> LXC (ls -alh /dev) >> crw-rw 1 root tty 136, 18 Feb 10 07:15 console >> lrwxrwxrwx 1 root root 11 Feb 10 07:15 core -> /proc/kcore >> lrwxrwxrwx 1 root root 13 Feb 10 07:15 fd -> /proc/self/fd >> crw-rw-rw- 1 nobody nogroup 1, 7 Feb 9 08:32 full >> srw-rw-rw- 1 root root 0 Feb 10 07:15 log >> drwxrwxrwt 2 nobody nogroup 40 Feb 10 07:15 mqueue >> drwxr-xr-x 2 root root 40 Feb 10 07:15 net >> crw-rw-rw- 1 nobody nogroup 1, 3 Feb 9 08:32 null >> lrwxrwxrwx 1 root root 13 Feb 10 07:15 ptmx -> /dev/pts/ptmx >> drwxr-xr-x 2 nobody nogroup 0 Feb 10 07:15 pts >> lrwxrwxrwx 1 root root 4 Feb 10 07:15 ram -> ram1 >> crw-rw-rw- 1 nobody nogroup 1, 8 Feb 9 08:32 random >> lrwxrwxrwx 1 root root 8 Feb 10 07:15 shm -> /run/shm > this looks wrong... > >> lrwxrwxrwx 1 root root 4 Feb 10 07:15 stderr -> fd/2 >> lrwxrwxrwx 1 root root 4 Feb 10 07:15 stdin -> fd/0 >> lrwxrwxrwx 1 root root 4 Feb 10 07:15 stdout -> fd/1 >> crw-rw-rw- 1 nobody nogroup 5, 0 Feb 10 18:17 tty >> crw-rw 1 root tty 136, 0 Feb 10 07:15 tty1 >> crw-rw 1 root tty 136, 1 Feb 10 07:15 tty2 >> crw-rw 1 root tty 136, 2 Feb 10 07:15 tty3 >> crw-rw 1 root tty 136, 3 Feb 10 07:15 tty4 > Urks. This looks super wrong. A container has no VC subsystem, and > these devices really shouldn't exist there. /dev/tty1, /dev/tty2 and > so on are the interface to the Linux kernel VC subsystem, and nothing else. > >> drwxr-xr-x 3 root root 60 Feb 10 07:15 .udev > Wut? where does this come from? the last time udev used that directory > was 4 years ago or so... > > Lennart > Not sure how up2date lxc tools are... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Trying to get journalctl -M UUID to work with docker containers
I have patches into docker to allow it to register with machinectl and run systemd inside of the container without --privileges. I also set it up so that the /var/log/journald/UUID on the host is mounted inside of the container, so that journald inside of the container writes to this location on the host. Then I use journalctl -M UUID on the host to look at the host journal. When I run the first container it works great. I see the container, but when I run the second container, I end up seeing the first countainers journal again. If I strace journalctl -M uuid it looks like it is reading all of the journals under /var/log/journalctl rather then just the one for UUID. Am I doing something wrong when I set this up? How is this supposed to work? Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Trying to get journalctl -M UUID to work with docker containers
On 02/08/2016 08:18 AM, Mantas Mikulėnas wrote: > On Mon, Feb 8, 2016 at 3:09 PM, Daniel J Walsh <dwa...@redhat.com > <mailto:dwa...@redhat.com>> wrote: > > I have patches into docker to allow it to register with machinectl and > run systemd inside of the container without --privileges. I also > set it > up so that the /var/log/journald/UUID on the host is mounted inside of > the container, so that journald inside of the container writes to this > location on the host. > > Then I use journalctl -M UUID on the host to look at the host journal. > When I run the first container it works great. I see the > container, but > when I run the second container, I end up seeing the first countainers > journal again. If I strace journalctl -M uuid it looks like it is > reading all of the journals under /var/log/journalctl rather then just > the one for UUID. > > Am I doing something wrong when I set this up? How is this > supposed to > work? > > > If I remember correctly, -M adds a filter for _MACHINE_ID and > _BOOT_ID? Try `SYSTEMD_LOG_LEVEL=debug journalctl -M ` to > verify. Maybe your containers actually have identical '/etc/machine-id's? > > -- > Mantas Mikulėnas <graw...@gmail.com <mailto:graw...@gmail.com>> docker ps -a CONTAINER IDIMAGE COMMAND CREATED STATUS PORTS NAMES 69730c6f4b85httpd "/sbin/init"7 minutes ago Up 7 minutes80/tcp httpd c8174de954b6httpd "/sbin/init"22 hours ago Up 7 minutes80/tcp httpd1 # machinectl MACHINE CLASS SERVICE 69730c6f4b85ea61f5b9ddb9fb68cf7b container docker c8174de954b6e3037926dfa8b15cc854 container docker # docker exec httpd cat /etc/machine-id 69730c6f4b85ea61f5b9ddb9fb68cf7b # docker exec httpd1 cat /etc/machine-id c8174de954b6e3037926dfa8b15cc854 No the /etc/machine-id is different, if I enter the container I see differences. # docker exec httpd journalctl | head -1 -- Logs begin at Mon 2016-02-08 14:10:37 UTC, end at Mon 2016-02-08 14:10:38 UTC. -- # docker exec httpd1 journalctl | head -1 -- Logs begin at Sun 2016-02-07 15:36:19 UTC, end at Mon 2016-02-08 14:10:49 UTC. -- # journalctl -M 69730c6f4b85ea61f5b9ddb9fb68cf7b | head -1 -- Logs begin at Sun 2016-02-07 09:59:39 EST, end at Mon 2016-02-08 09:18:20 EST. -- # journalctl -M c8174de954b6e3037926dfa8b15cc854 | head -1 -- Logs begin at Sun 2016-02-07 09:59:39 EST, end at Mon 2016-02-08 09:18:40 EST. -- Where should I go for the output of this? SYSTEMD_LOG_LEVEL=debug journalctl -M Is there a way for me to see the settings of _MACHINE_ID and _BOOT_ID? Also how can I see the actual path to the file journalctl is reading? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Does systemd launch gdb on an application that crashes now?
I am seeing gdb run in the SELinux type of a few different crashed domains. I am trying to figure out how this is happening, so we can figure out a secure solution. I know that kde has some kind of hack to handle this, and abrt does it but it does it under the abrt_t process not in the same context as the crashed application. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SElinux in container
On 08/23/2015 08:10 AM, arnaud gaboury wrote: Here is my setup: Host: Archlinux systemd 224-1 Container: Fedora 22 systemd 219 The container is a server and has vocation to be one day deployed on a dediacted server for production. In this way, I would like to set SElinux (default in Fedora). Unfortunately, doing it in Arch host is not a trivial affair and as host is a desktop, I would like to avoid. For now, SElinux is enabled in the Kernel with disables at boot with selinux=0. Is there any way to enable and configure SElinux only in the container? Looking at capabilities(7) did not give me any hints. As a side note, CAP_SYS_MODULE does not work for container. I guess it is due to systemd 219 on the container ? Thank you. You would have to write a policy for this. You could write a policy where everything is an unconfined domain, but the containers run confined. You would write something where the kernel, systemd ... all run as os_t, then allow docker or other domain to transition the container domain. container_t. But this would not give you fine grained control within the container. It also would probably require a lot of policy writing. But would seem to be a good university project... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] I am adding RegisterMachine to docker.
When container stops machinectl still shows it registered? Do I need to Unregister the machine? I though systemd would notice the pid died and remove the machine. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 219/Fedora22: NFS mounts do not set SELINUX label to nfs_t: errno=-22
On 05/26/2015 09:46 AM, Lennart Poettering wrote: On Sun, 24.05.15 15:01, Anthony Alba (ascanio.al...@gmail.com) wrote: Hi, On Fedora 22, systemd 219, NFS mounts no longer acquire a default label nfs_t. mount 192.168.1.6:/var/exports/1 1 -orootcontext=system_u:object_r:nfs_t mount.nfs: an incorrect mount option was specified [ 8316.276744] SELinux: security_context_to_sid(system_u:object_r:nfs_t) failed for (dev 0:51, type nfs4) errno=-22 To my surprise, it seems to acquire labels from the NFS server (Fedora 22/nfs4) - how is this possible? But..it breaks libvirtd/kvm: it sees the right label if this were a local filesystem but audit2allow complains: ls -lZ guestfs/centos7.img -rw-r--r--. 1 qemu qemu system_u:object_r:virt_image_t:s0 22987538432 May 24 14:56 guestfs/centos7.img ## for a image in /var/lib/libvirt this is the correct label. ## I do not know how it figured that from the NFS server SELinux is preventing qemu-system-x86 from read access on the file centos7.img (on NFS share). On Fedora 21, the files acquire the label nfs_t and setsebool -P virt_use_nfs=on This is unlikely to be related to systemd, we don't really do anything special with NFS and especially not its selinux support. We simply invoke util-linux' mount command, which in turn calls mount.nfs of the nfs-utils package. Please contact the nfs-utils guys, thank you, Lennart nfs_t should be by default for labels. The example you have was not using a complete label. mount 192.168.1.6:/var/exports/1 1 -orootcontext=system_u:object_r:nfs_t mount.nfs: an incorrect mount option was specified [ 8316.276744] SELinux: security_context_to_sid(system_u:object_r:nfs_t) failed for (dev 0:51, type nfs4) errno=-22 The label should be system_u:object_r:nfs_t:s0 not system_u:object_r:nfs_t Nfs does now support labeling if you use a RHEL7 or Fedora based server and client. But it should still default to nfs_t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Docker vs PrivateTmp
Yes I was trying to get a comment from Alex, since he did the original
patch.
On 01/23/2015 12:26 PM, Lennart Poettering wrote:
On Fri, 23.01.15 11:31, Daniel J Walsh (dwa...@redhat.com) wrote:
You just sent a full quote without any comment of yours?
On 01/22/2015 10:02 PM, Lennart Poettering wrote:
On Sat, 17.01.15 23:02, Lars Kellogg-Stedman (l...@redhat.com) wrote:
See the `devicemapper` mountpoint created by Docker for the container:
# grep devicemapper/mnt /proc/mounts
/dev/mapper/docker-253:6-98310-e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62
/var/lib/docker/devicemapper/mnt/e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62
ext4
rw,context=system_u:object_r:svirt_sandbox_file_t:s0:c261,c1018,relatime,discard,stripe=16,data=ordered
0 0
I am not sure why docker makes these mounts visible in the host
namespace at all. This smells like a bug.
Watch Docker fail to destroy the container because it is unable to remove
the mountpoint directory:
Jan 17 22:43:03 pk115wp-lkellogg docker-1.4.1-dev[18239]:
time=2015-01-17T22:43:03-05:00 level=error msg=Handler for DELETE
/containers/{name:.*} returned error: Cannot destroy container
e68df3f45d61:
Driver devicemapper failed to remove root filesystem
e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62:
Device is
Busy
This smells as if Docker incorrectly sets the mount propagation bits
on its own mounts.
It would be good checking /proc/self/mountinfo inside and outside of
docker's own namespace, and checking how the propagation bits are set
for the individual mounts. It's a bit hard to read, but the
interesting bits are in the 7th column of that file.
In general: docker should do the equivalent of mount --make-rslave /
as first thing after opening its mount namespace, so that from that
point on mounts and especiall *un*mounts propagate from the host into
the container, but not vice versa.
If they do not invoke that, then the propagation will stay at
shared, which means the mounts will appear in the host and vice
versa, which is certainly undesired.
Also, they should not use mount --make-rprivate /, as that means
anything the host mounted will stay mounted in the container forever,
which is a problem.
Also, they really need to make this recursive, so that all mount
points they have access too are detached from the host!
Lennart
Lennart
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Docker vs PrivateTmp
On 01/22/2015 10:02 PM, Lennart Poettering wrote:
On Sat, 17.01.15 23:02, Lars Kellogg-Stedman (l...@redhat.com) wrote:
See the `devicemapper` mountpoint created by Docker for the container:
# grep devicemapper/mnt /proc/mounts
/dev/mapper/docker-253:6-98310-e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62
/var/lib/docker/devicemapper/mnt/e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62
ext4
rw,context=system_u:object_r:svirt_sandbox_file_t:s0:c261,c1018,relatime,discard,stripe=16,data=ordered
0 0
I am not sure why docker makes these mounts visible in the host
namespace at all. This smells like a bug.
Watch Docker fail to destroy the container because it is unable to remove
the mountpoint directory:
Jan 17 22:43:03 pk115wp-lkellogg docker-1.4.1-dev[18239]:
time=2015-01-17T22:43:03-05:00 level=error msg=Handler for DELETE
/containers/{name:.*} returned error: Cannot destroy container
e68df3f45d61:
Driver devicemapper failed to remove root filesystem
e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62: Device
is
Busy
This smells as if Docker incorrectly sets the mount propagation bits
on its own mounts.
It would be good checking /proc/self/mountinfo inside and outside of
docker's own namespace, and checking how the propagation bits are set
for the individual mounts. It's a bit hard to read, but the
interesting bits are in the 7th column of that file.
In general: docker should do the equivalent of mount --make-rslave /
as first thing after opening its mount namespace, so that from that
point on mounts and especiall *un*mounts propagate from the host into
the container, but not vice versa.
If they do not invoke that, then the propagation will stay at
shared, which means the mounts will appear in the host and vice
versa, which is certainly undesired.
Also, they should not use mount --make-rprivate /, as that means
anything the host mounted will stay mounted in the container forever,
which is a problem.
Also, they really need to make this recursive, so that all mount
points they have access too are detached from the host!
Lennart
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Docker vs PrivateTmp
On 01/19/2015 12:27 AM, Lars Kellogg-Stedman wrote: On Sun, Jan 18, 2015 at 11:38:12PM -0500, Lars Kellogg-Stedman wrote: I think we actually want MountFlags=slave, which will permit mounts from the global namespace to propagate into the service namespace without permitting propagation in the other direction. It seems like this would the Least Surprising behavior. ...which would be the default if docker.service were itself using PrivateTmp=true, because from systemd.exec: Note that the file system namespace related options (PrivateTmp=, PrivateDevices=, ProtectSystem=, ProtectHome=, ReadOnlyDirectories=, InaccessibleDirectories= and ReadWriteDirectories=) require that mount and unmount propagation from the unit's file system namespace is disabled, and hence downgrade shared to slave. So either explicitly setting MountFlags=slave, or setting PrivateTmp=true if that doesn't cause any issues of which I am not aware. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Vincent what do you think about MountFlags=slave? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] I am trying to hook up docker and systemd.
I have a working version of docker which runs systemd/journald within the container and sets up the /var/log/journal/UUID inside the container to match the version outside. I also have registered the container with machinectl. Everything seems to work fine except that when I execute journalctl -M UUID I get a message saying no logs available. I then attempted the same thing with systemd-nspawn, and again I get no logs availabel. If I send a SIGUSR1 to the journal process it finally writes its logs and the journalctl on the outside sees it. Is there a way to get the logs to continuously be written, so jounralctl -M UUID will be able to monitor the logs, without having to send the SIGUSR1? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should systemd-logind provide a DM-independent mechanism for handling guest accounts?
It would be fairly easy to setup pam_namespace for the guest user to provide a temporary /tmp and ~/. Now, just like we do for xguest. Then you could setup the login account to use no password and the guest_u user and allow users onto the system. This would get you most of the things you want. The problems would be in having multiple users get access to the machine at the same time. For this you need something that generates a UID on the fly for the user. I would expect a fairly simple pam module could be done for this. One problem with this though would be a user might log in as guest user but endup getting the guest134 user account. This means you would want some kind of sssd interaction, so a user executing id or ls -lZ ~/ Would see all of his files and processes running as guest. Taking advantages of other namespaces to setup additional containment might also be interesting especially the pid namespace. On 11/10/2014 04:36 PM, Lennart Poettering wrote: On Mon, 10.11.14 16:41, Laércio de Sousa (laercioso...@sme-mogidascruzes.sp.gov.br) wrote: Hi there! Currently there are few alternatives for implementing guest accounts in Linux systems. I know only two: an AppArmor-based approach implemented in LightDM, and a SELinux-based approach implemented in Fedora's package xguest that works with GDM. There's no option for console guest login (should it be needed?). I was thinking if systemd-logind could handle itself guest accounts in the future, making it available for use by any display manager (and even console logins, who knows?). What do you think about it? I figure this pays into the whole concept of dynamic users, which we really want to have eventually, to deal with dynamic allocation of UIDs for user namespacing in container managers, for allocating per-seat users for gdm login screens, and then also for your usecase, i.e. to implement guest users that go away entirely on logout. So yeah, it's definitely something we want, and I figure it should be added to the systemd project in some way. Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Expected behavior when systemd cannot load SELinux policy
On 11/07/2014 11:09 AM, Lennart Poettering wrote: On Fri, 07.11.14 11:30, Jan Synáček (jsyna...@redhat.com) wrote: Hello, currently, when SELINUX=enforcing and SELINUXTYPE=invalid value are set in /etc/selinux/config, systemd refuses to boot with Failed to load SELinux policy. Freezing. Is this really what should happen? If SELINUX is set to permissive or disabled, though, systemd happily continues booting. I think that that's what should happen when SELINUX is set to enforcing as well. Plus a big warning in the log, or maybe even on the console, of course. What do you think? Well, if we are in enforcing mode then this means that everything that is not OK needs to fail, and this includes the policy being corrupted or missing really. Enforcing mode is really this super secure mode where we'd rather hang the machine then possibly allow things to go through that might not be let through if the policy would be order... Lennart Yes think of super secure systems. If you had a machine that contained TopSecret information, then booting without the policy in effect would potentially lead to compromised information. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/4] mount-setup: introduce mount_setup_run_dirs()
On 10/08/2014 07:40 AM, Lennart Poettering wrote: On Tue, 07.10.14 14:14, Michal Sekletar (msekl...@redhat.com) wrote: Hence, if a container manager mounts everything properly, then mount_setup() should be a NOP anyway... In theory yes, but in fact not having /run mounted as tmpfs is default in the docker container. I have no strong opinion on whether this is sensible or not, however I think that systemd can be made more resilient and handle such cases. Sorry, but no. /run should be pre-mounted, and if it isn't we need the rights to mount it. We will not boot up a system without /run. That's part of the API for programs, and we will not avoid it. Please ask Docker to premount /run. All distros need /run anyway these days, Debian does, Ubuntu does, Fedora does. Now systemd will try to mount /run on tmpfs, such attempt will fail because of missing capability and then systemd will just hang. Well, just sticking the head in the sand won't help. If we don't have /run mounted, then things will break later on. We cannot ignore that. Sorry, Lennart We have a patch for this. In the past docker has bocked/removed the patch because there is no concept of systemd-tmpfs inside a container to pre-populate /run. So images came with content in their /run. Alex wrote a patch to scan the /run on the image and create the content in a tmpfs /run. I will attempt to push this patch again to docker. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User sessions: limit the ability to migrate cgroups
On 08/13/2014 12:11 PM, Alban Crequy wrote: On Wed, 13 Aug 2014 16:37:17 +0200 Lennart Poettering lenn...@poettering.net wrote: On Thu, 07.08.14 15:19, Alban Crequy (alban.cre...@collabora.co.uk) wrote: Hi, Should unprivileged processes be allowed to change cgroup? Well, they shouldn#t do it. But I think it's OK as long as this is only done within the specific user's hierarchies. As I understand it, it is not possible to block processes to leave a cgroup, but only to block processes to enter a cgroup. Correct. In the following example, session-c4.scope/tasks belongs to root:root with -rw-r--r-- and user@1000.service/tasks belongs to user:user with -rw-r--r--. Yes, this is because systemd --user needs to be able to manage its own cgroup subtree, so we have to open this up for the user@1000.service service, but keep it restricted otherwise... It makes sense. So processes can freely move from session-c4.scope to user@1000.service. But not in the other direction. Correct. $ systemd-cgls Working Directory /sys/fs/cgroup/systemd/user.slice/user-1000.slice: ├─session-c4.scope │ ├─713 sshd: user [priv] │ ├─722 sshd: user@pts/2 │ ├─723 -bash │ ├─732 systemd-cgls │ └─733 pager ├─user@1000.service │ ├─406 /lib/systemd/systemd --user With user sessions managed by systemd, will it be possible to restrict unprivileged users from migrating to other cgroups? Unlikely. Access control on Unix is generally bound to user IDs, not processes, and we really shouldn't start here with departing from that... I tested SELinux and AppArmor to restrict /sys/fs/cgroup/. SELinux didn't help because the cgroup file system does not support extended attributes such as security.selinux, but AppArmor was able to block an application from changing cgroup. Alban ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel You could mount the cgroup with a label that the intended domain could not write. Similarly you could just prevent the domain from writing to cgroupfs_t. Which is the default label of the cgroup file system. No confined/Few domains right now should be allowed to write to cgroupfs_t. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Blog on running systemd within a docker container.
On 05/02/2014 11:54 AM, Lennart Poettering wrote: On Wed, 30.04.14 14:21, Daniel J Walsh (dwa...@redhat.com) wrote: http://rhatdan.wordpress.com/2014/04/30/running-systemd-within-a-docker-container/ There are a couple of things in the story that I'd like to correct: 1) udev isn't actually started when systemd detects that /sys is read-only. See: http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/ The idea here is that docker should mount /sys read-only (already for for security purposes it should do that). When that's done udev is not started, and that requires no explicit work by you. I's conditionalized via ConditionPathIsWritable=/sys. There is a pull request to mount /proc and /sys as readonly that looks like it is going upstream soon. The readonly mount will only happen in non-priv containers. Once we have the ability to add SYS_ADMIN capability to a non-priv container, I should be able to run systemd inside a container and this should work. 2) systemd doesn't even start getty logins (plural!). If it detects it runs inside a container it will actually start exactly one, on /dev/console. We can improve systemd to find out a way how to even disable that. For example, we could build on $container_ttys (see the url above), and maybe intrdouce $container_headless=1 or so, which when set will result in systemd to not start any getty at all. I think this would be good, since we plan on using nsenter to join containers, don't think we want getty/login running there by default. 3) THis is similar for all the other .wants/ links you remove. I think we really should avoid doing this. Instead, it sounds better to make sure systemd automatically figures out when to start specific services and when to not do that. As it turns out we did this for quite a few of the services in there already. For example, systemd-binfmt is already skipped if /proc/sys is not writable anyway... And so on. So instead of doing blanket removals, please let us know which ones you see running that you'd rather not see running, and we can figure out a way how to conditionaliuze them upstream so that unmodified systemd just works for you... Once we have a better docker, and I can run systemd in a non priv container, I will attempt this again, and see what processes get started without the cleanups in the .wants directories. I too would like to get rid of these. To say this explicitly: we are really interested in making sure that systemd runs out-of-the-box in containers, and docker is just one implementation of that. Lennart Great, and I want to make systemd the default tool for running multiple services within a docker container. I like it for running a single service also, since it is so simple. I would like to talk to you guys about getting the journal information out of the container. IE with this model we loose STDOUT/STDERR and /dev/log entries showing up in the hosts journal. We can bind mount /dev/log into the container, but we still loose STDOUT/STDERR ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Blog on running systemd within a docker container.
On 05/01/2014 09:28 AM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Apr 30, 2014 at 02:21:44PM -0400, Daniel J Walsh wrote: http://rhatdan.wordpress.com/2014/04/30/running-systemd-within-a-docker-container/ Interesting. The part where you remove all the links in .wants directories seems ugly. Would it be feasible to use a custom target instead of multi-user.target? Things removed this way will come back if e.g. systemd rpm is updated inside of the image. Judicious use of systemctl mask and setting a custom preset of 'disable *' should also help. Zbyszek Well I want people to be able to yum install httpd; systemctl enable httpd.service Which I believe requires the multi-user.target to work correctly. If you have better systemctl mask commands, I would love to use them instead. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Blog on running systemd within a docker container.
http://rhatdan.wordpress.com/2014/04/30/running-systemd-within-a-docker-container/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pcre in daemons
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/26/2014 03:05 PM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Feb 26, 2014 at 08:54:34PM +0100, Thomas H.P. Andersen wrote: The todo says: something pulls in pcre as shared object dependency into our daemons such as hostnamed Normal buiild: ldd ./systemd-hostnamed linux-vdso.so.1 = (0x7fff247bc000) libselinux.so.1 = /lib64/libselinux.so.1 (0x7f7ec47f7000) librt.so.1 = /lib64/librt.so.1 (0x7f7ec45ef000) libdl.so.2 = /lib64/libdl.so.2 (0x7f7ec43ea000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f7ec41cd000) libc.so.6 = /lib64/libc.so.6 (0x7f7ec3e0e000) /lib64/ld-linux-x86-64.so.2 (0x7f7ec4a2f000) libpcre.so.1 = /lib64/libpcre.so.1 (0x7f7ec3ba7000) liblzma.so.5 = /lib64/liblzma.so.5 (0x7f7ec3982000) It's a selinux problem (or not, if it actually uses pcre's). ldd /lib64/libselinux.so.1 linux-vdso.so.1 = (0x7fff58bfe000) libpcre.so.1 = /lib64/libpcre.so.1 (0x00380340) liblzma.so.5 = /lib64/liblzma.so.5 (0x0035d680) libdl.so.2 = /lib64/libdl.so.2 (0x0035d2c0) libc.so.6 = /lib64/libc.so.6 (0x0035d200) /lib64/ld-linux-x86-64.so.2 (0x0035d180) libpthread.so.0 = /lib64/libpthread.so.0 (0x0035d280) Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel libselinux and systemd take advantage of pcre for speeding up the handling of reading in the labeling file. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMOWzAACgkQrlYvE4MpobMP1QCgt0EMALHGgrb9Z+cG11RvQvx3 U5EAoIl0M0oYdjA+3PmOJE1sn9NDo66v =ukVz -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2014 02:27 PM, Eric Paris wrote: I like it, if it's reasonable/possible On Thu, Feb 20, 2014 at 2:26 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 20.02.14 13:50, Eric Paris (epa...@parisplace.org) wrote: Not really. If it doesn't exist on the final root fs and I put enforcing=1 on the command line, I expect the box to panic/fail/die/whatever OK, then maybe check !in_initrd() || access(/etc/selinux/, F_OK) = 0? Lennart -- Lennart Poettering, Red Hat ___ Selinux mailing list seli...@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing help to selinux-requ...@tycho.nsa.gov. You mean !in_initrd() || access(selinux_path(), F_OK) = 0? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMGW1AACgkQrlYvE4MpobOeUgCg3YoRWatuabfOsAGLD4p09QVo PYMAn3hDTBy4ePCPy/jORYlE+KGotSxE =kkZx -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] Add SELinuxContext configuration item
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/07/2014 08:22 AM, Michael Scherer wrote: Le jeudi 06 février 2014 à 12:21 -0800, David Timothy Strauss a écrit : In order to maximize consistency with newly committed options in systemd-nspawn, would it make sense to allow independent configuration of the process and file labels instead? The file label are decided by selinux policy based on the path and/or process domain, from what I seen. In the case of systemd-nspawn, it is done by using a specific option of mount, and only for tmpfs/devpts. So I am not sure if this can be done, and i fail to see a usecase for that ( except having container described in .service, which could be nice but maybe too much ) Yes the goal with the file system labels is for tmpfs file systems created/mounted within the systemd-nspawn. If you are using a chrooted OS, then its labeling should be done outside the command. I wanted to also allow this to be generic so other labeling tools like SMACK could also be used. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlL6Q8AACgkQrlYvE4MpobNf8ACcC+B/5yvbOnOPiRoDQYiokGT+ xe0AmwR7qdFnJ/aqzTMfL0lcPYCUGYs2 =Pk3g -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/1] Allow systemd to run without assigning container to machine.slice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/30/2014 07:09 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Jan 30, 2014 at 04:29:14PM -0500, Dan Walsh wrote: If I want to run a container as a service, it would be nice if it used the service cgroup configuration Your patch will break the integration with machienctl, etc. Would instead assigning the slice with --slice be enough? Zbyszek My goal is if I run systemd-nspawn within a systemd unit file, perhaps as a plugin to docker, I want to allow the system administrator to just add MemoryLimit=500m To the unit file and have it effect the processes within the container. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLrpMEACgkQrlYvE4MpobMe5wCfaRR70wrnY2bU+SgzCFLlSeSO CSEAn1t+TDnEkj0VeMp6HTSK/QoK2xO+ =SDyW -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/1] Allow systemd to run without assigning container to machine.slice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/31/2014 10:45 AM, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Jan 31, 2014 at 10:00:12AM -0500, Daniel J Walsh wrote: My plan is not to have the user no they are running systemd-nspawn Imaging the user is creating a httpd container unit file using docker, described in this document. http://welldefinedbehaviour.wordpress.com/2014/01/30/adventures-with-containerization-fedora-docker-and-httpd/ [Unit] Description=example.com Container After=docker.service [Service] Type=simple ExecStart=/usr/bin/docker run -v /srv/example.com:/srv httpd-test1 Restart=on-failure Currently docker uses lxc tools under the covers to launch the container, we want to add a plugin to use systemd-nspawn. docker - systemd-nspawn - container But we want the docker, systemd-nspawn and the container all affected by any Cgroup entries in the unit file. So I want the container to run as a service slice not a machine slice. And if you specify --slice=system-something.slice, doesn't this do the job? Zbyszek How would the docker command know what slice to assign it to? Why not just eliminate systemd-nspawn doing anything with slices if I pass the service flag or some other flag. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLrxnoACgkQrlYvE4MpobO1mgCglDP9B5DadqucUEyxAgSeBVYf G3sAoIBuzpooNd5K+cBQ8ks22pxp6az5 =qw4r -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/1] Allow systemd to run without assigning container to machine.slice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/31/2014 11:20 AM, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Jan 31, 2014 at 10:51:22AM -0500, Daniel J Walsh wrote: Currently docker uses lxc tools under the covers to launch the container, we want to add a plugin to use systemd-nspawn. docker - systemd-nspawn - container But we want the docker, systemd-nspawn and the container all affected by any Cgroup entries in the unit file. So I want the container to run as a service slice not a machine slice. And if you specify --slice=system-something.slice, doesn't this do the job? How would the docker command know what slice to assign it to? Why not just eliminate systemd-nspawn doing anything with slices if I pass the service flag or some other flag. It's not possible to disable slices, nspawn will always end up in some slice. The docker command already needs to know about systemd-nspawn to launch it. So it can just give the --slice option. If you want this to be part of the /system slice, than anything like --slice=system-container-id.slice will be fine. And the limits can be set on the slice as wanted. Note that the slice unit doesn't have to exist, it will be created when referenced. Zbyszek I know it has to be in a slice, I just want it to stay in the same slice that the docker command is in. If I could run --slice=current that would be fine. If I create the httpd_container.service, it will create the service-httpd_container.slice and docker will run there. I want systemd-nspawn and more importantly the container processes to stay in httpd_containe.slice. I guess I could get docker to check which slice it is in, if that was possible, but I see no reason why we can not stop doing slice stuff in systemd-nspawn, if a user wants it to run within his current slice. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLr0HsACgkQrlYvE4MpobMi+wCfY9LD7CzEOYVIrj79i1+i2T/p HVEAoL7jmMNXod6lOULx7AHkTbih9c5i =Vq2a -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/1] Allow systemd to run without assigning container to machine.slice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/31/2014 09:51 AM, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Jan 31, 2014 at 08:27:29AM -0500, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/30/2014 07:09 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Jan 30, 2014 at 04:29:14PM -0500, Dan Walsh wrote: If I want to run a container as a service, it would be nice if it used the service cgroup configuration Your patch will break the integration with machienctl, etc. Would instead assigning the slice with --slice be enough? Zbyszek My goal is if I run systemd-nspawn within a systemd unit file, perhaps as a plugin to docker, I want to allow the system administrator to just add MemoryLimit=500m You can set the limit on the service, or on the slice. On the service: # /etc/systemd/system/systemd-nspawn@container.d/limits.conf [Service] MemoryLimit=500M On the slice: # /etc/systemd/system/systemd-nspawn@container.d/slice.conf [Service] Slice=system-container.slice # /etc/systemd/system/system-container.slice # (note that the path here makes this slice part of /system not /machine [Slice] MemoryLimit=500M You can alternatively specify the slice with --slice argument to nspawn. Zbyszek My plan is not to have the user no they are running systemd-nspawn Imaging the user is creating a httpd container unit file using docker, described in this document. http://welldefinedbehaviour.wordpress.com/2014/01/30/adventures-with-containerization-fedora-docker-and-httpd/ [Unit] Description=example.com Container After=docker.service [Service] Type=simple ExecStart=/usr/bin/docker run -v /srv/example.com:/srv httpd-test1 Restart=on-failure Currently docker uses lxc tools under the covers to launch the container, we want to add a plugin to use systemd-nspawn. docker - systemd-nspawn - container But we want the docker, systemd-nspawn and the container all affected by any Cgroup entries in the unit file. So I want the container to run as a service slice not a machine slice. The user will never execute systemd-nspawn in this case. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLrunwACgkQrlYvE4MpobOacACeMMWBJZjJXiHKEhT+Dp8xB4tl viEAn0pMcKsQriVNSrpltlW2gtG+VhH3 =uJiv -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/03/2014 12:35 PM, Michael Scherer wrote:
Le vendredi 03 janvier 2014 à 11:48 -0500, Daniel J Walsh a écrit :
On 01/03/2014 09:16 AM, Michael Scherer wrote:
Well thinking about this again, I think still to the single label. Lets
not break the field up into multiple labels.
And not make it SELinux specific. Maybe the field could be
SecurityLabel:
That would allow smack to also use the field and any other LSM that used
a labeling system.
I fail to follow you. The current code use setexecon, and this is quite
selinux specific. What would be the equivalent for apparmor, for smack and
others ?
No idea, I only do SELinux...
But as Kay Pointed out, there is some similar code in udev for this.
Udev uses: SECLABEL{selinux}=foo SECLABEL{smack}=bar
I think we should be able to distinguish the LSM-module-specific label type
somehow in the key or value.
Kay
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLKsRYACgkQrlYvE4MpobOZaACfZTo4JI3dYFhZ9bXKTVkQrQy0
nB4AoLS6FYmmiasReuREK+oedjWn/jI5
=K5oJ
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2014 09:16 AM, Michael Scherer wrote: Le vendredi 03 janvier 2014 à 12:23 +, Jóhann B. Guðmundsson a écrit : On 01/03/2014 10:56 AM, Michael Scherer wrote: Le vendredi 03 janvier 2014 à 00:58 +, Jóhann B. Guðmundsson a écrit : On 12/28/2013 01:30 PM, Lennart Poettering wrote: On Fri, 27.12.13 23:26,m...@zarb.org (m...@zarb.org) wrote: From: Michael Schererm...@zarb.org This permit to let system administrators decide of the domain of a service. This can be used with templated units to have each service in a différent domain ( for example, a per customer database, using MLS or anything ), or can be used to force a non selinux enabled system (jvm, erlang, etc) to start in a different domain for each service. Hmm, so far (as I understood it) the SELinux guys always wanted to make sure that label configuration stays in the the selinux database and nowhere else. Right and if you add this you need to add something for the other security solutions as well ( apparmor etc ). I do not see why we need to equally support all MAC frameworks for each change we do. Because people will start to expect being able to configure that there. So they can as well start to fill bug report and start to contribute code for this. We didn't added detection of all security framework for ConditionSecurity at the first patch, it was added later as people expressed interest ( hence the lack of tomoyo ), so I expect the same to be done for security frameworks. Also, having done my homework, IMA do not have the concept of domain, apparmor has profiles, and I have no idea for smack, so I prefer to defer integration to people who know, based on their use cases. And while I am familiar enough with apparmor to create a equivalent setting ( and plan to do ), I have no idea on how to translate the concept for smack, ima and tomoyo. In fact, the mere fact that tomoyo is not handled at all already show that we do treat all security framework as equal. How do you suppose we deal with man pages if selinux is not installed but still refer to this. In the same way we do for all #ifdef feature. For example, for PAMName, the documentation is always present. Wont users also need to check if selinux is enabled or not in the unit file? I would rather do it in the C code, no need to have everybody asking for it. Should systemd warn users if selinux is not installed,enabled and fail or? It all depend. Either we are consistent with the other settings ( ie, setting a syscall filter will fail if not supported on the kernel ), and so fail, or we decide that selinux is special and we should silently ignore failure if it cannot be applied. I choose the first one for the first patch, but adding a conditional would be trivial if we decide to silently ignore if the setting cannot be applied. The main issue being of course that people who disable selinux do not always properly disable it ( ie using permissive rather than selinux=0 ). This introduces yet another place for administrators to look at while debugging problems so the question to ask here is. Is adding this ability to unit files the right way to solve what's trying to be solved here? As Dan said, yes. I would prefer if app writers do not start hard coding SELinux contexts into the unit file I hardly call that solid yes and this is what will start taking place if this is introduced into the unit files. Then what about : I like this patch, and I have seen people saying we have this capability in RHEL7 :^( We should separate the concern about people in distribution/upstream using it if offered and the rest of the world. Distribution policy is a matter of the distribution. If Fedora wish to forbid this unless there is a good use case, that's up to Fedora to do it, and to have it integrated into rpmlint or anything. I must also say that I didn't really see a rush from application developers to add selinux support or anything, and that people can already distribute policy along their application, with all support problem this could create for distributions. So we already have the problem, adding the setting in systemd wouldn't change much. However, as said, there is some case where the approach of making the transition based on the executed filename is not sufficient. For example, the erlang vm, the jvm, etc, because each software will run in the same domain, in different processes, because that's always the same jvm being used. See the bug I mentioned before. Now, if you have a more precise feedback and/or a better proposal, Add this to the daemon startup itself ( the confile or the code ) and or use runcon in an exec start pre section to set this up. Runcon cannot be used in ExecStartPre, that's like su. So you have to run it in ExecStart, and this make things harder for sysadmins, and
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/28/2013 11:47 AM, Michael Scherer wrote: Le samedi 28 décembre 2013 à 14:30 +0100, Lennart Poettering a écrit : On Fri, 27.12.13 23:26, m...@zarb.org (m...@zarb.org) wrote: From: Michael Scherer m...@zarb.org This permit to let system administrators decide of the domain of a service. This can be used with templated units to have each service in a différent domain ( for example, a per customer database, using MLS or anything ), or can be used to force a non selinux enabled system (jvm, erlang, etc) to start in a different domain for each service. Hmm, so far (as I understood it) the SELinux guys always wanted to make sure that label configuration stays in the the selinux database and nowhere else. Yep, I know and they are right, we shouldn't put configuration everywhere in the system. But there is a few cases where the selinux policy cannot express what we want ( or at least, I do not know how to do it ). First case is doing something like openshift, with 1 different domain per user. Since the transitions are mostly handled in kernel space ( except for specific case like sepostgresql ), it kinda restrict what we can do in term of smart transition. In the case of openshift, this use a specific pam module (pam_openshift) and specific plugins in the code, because the policy is a bit too static to handle that. So using templated units, we could do for example : SELinuxContext=staff_u:staff_r:%s_t:s0-s0:c0.c1023 or similar tricks. Or just handle things manually, with static SELinuxContext ( or include, or anything ). The second case is caused by a limitation of the current way of doing transition. My main motivation is to solve https://bugzilla.redhat.com/show_bug.cgi?id=969757 , because right now, we cannot ask to erlang to run in a different domain unless if we write 1 shell wrapper per erlang application just to trigger the transition, or until we make erlang selinux-aware, like postgresql is. So rather than duplicate shell wrappers or adding code everywhere, I was thinking doing it in systemd directly would be beneficial for everybody by reducing needed changes to the only stuff that matter, having the context we want to switch to. I do not expect SELinuxContext to be used by upstream units, and I guess that a distribution can decide to have them being unused by policy if that's a issue. It should also be noted that upstart do support a similar configuration for apparmor, https://code.launchpad.net/~mdeslaur/upstart/apparmor-support/+merge/164169 And I was pondering on adding it as well to systemd, since some systemd consumers are using apparmor, and because feature parity is IMHO important if we want to let people use systemd on Ubuntu. I'd like Dan Walsh's opinion whether this addition fits into what the SELinux guys want or not. Dan? Patch looks fine though. I like this patch, and I have seen people saying we have this capability in RHEL7 :^( Currently people in a sysvinit scripts are using runcon for similar features. And as someone described handling of java, mono, erlang type scripts where the command is not easy to differentiate. We also allow people to do something similar with sudo. ROLE=unconfined_r TYPE=unconfined_t. I would prefer if app writers do not start hard coding SELinux contexts into the unit files, but allowing administrators or third parties like openshift to override I do not have a problem with it. It could allow a administrator to say run this script as unconfined_t, which may or may not cause other problems. We might want to allow more granularity on this then just context.Since we allow sudo to specify role and type and we allow runcon to specify all fields of SELinux. BTW Use dwa...@redhat.com for my email, not my private (Not so private) home email. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLFlCoACgkQrlYvE4MpobMVZgCghr6UOCybitcKKqV5HKISjKDc EhoAn36vppR/4zrjhBeyypzlWqawDxdn =3jEw -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: fix selinux check for transient units
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2013 05:45 PM, Michal Sekletar wrote:
On Mon, Nov 18, 2013 at 04:19:20PM -0500, Daniel J Walsh wrote: On
11/16/2013 08:10 AM, Lennart Poettering wrote:
On Thu, 14.11.13 15:43, Daniel J Walsh (dwa...@redhat.com) wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 11/14/2013 12:50 PM, Harald Hoyer wrote:
On 11/05/2013 11:12 PM, Daniel J Walsh wrote:
On 11/05/2013 12:22 PM, Lennart Poettering wrote:
Ok lets add a check that checks for start on a service labeled
with the remote process label, then we can add rules like
allow systemd_logind_t self:service start
Or we can make it simpler and have the local end check against
the init_t process.
allow systemd_logind_t init_t:service start;
Which is probably a better solution, if we have no way of
differentiating the services.
Machineid usually runs as init_t now.
systemd-run runs as the label of the process that executes it,
Usually unconfined_t, and sysadm_t.
has any solution been found for this?
seems like one is needed for
https://bugzilla.redhat.com/show_bug.cgi?id=1008864
I guess the question I have is do you expect a patch from me? Or
are you guys working on it? I would go with the checking based on
process label.
I am hoping for a patch for this!
Thanks,
Lennart
This patch adds a new call for SELINUX_SNAPSHOT_ACCESS_CHECK, because I
believe this error will happen when a snapshot is created. Also now pass
in system when doing a system check, if it is doing a service check and
does not pass in a unit file we will default the target to the label that
systemd is running with.
Hi,
Maybe I am missing something but isn't this about transient units in
general, i.e. what about StartTransient()? What is going to change in
this case after applying this patch? tclass will be system since in
SELINUX_ACCESS_CHECK you now pass system as path and you will set
tclass in else branch to system which is afaik same as before.
In the current code, passing a unit_file of NULL (StartTransients has a NULL
UnitFile) will indicate that it should do a system check. My patch is
intended to change this so a NULL UnitFile will indicate that systemd should
check the access between the calling process label and the current process
label for a service access. Where as the SELINUX_ACCESS_CHECK will now pass
a system flag to the function to make it do a system check.
On the side note, you forgot to define SELINUX_SNAPSHOT_ACCESS_CHECK as
do {} while (false) in case if we don't HAVE_SELINUX.
It might be the case that I completely misunderstood what's this about,
in such case ignore this email.
Michal
Thanks added SELINUX_SNAPSHOT_ACCESS_CHECK as do {} while (false) in case if
we don't HAVE_SELINUX.
Updated patch.
snip
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKLbaEACgkQrlYvE4MpobPMMACeNeyrC3OBhx99DZ+JzOtV1ykZ
PvMAoJfiYBoJRBFgh2+FyOV+tNTuojNU
=9I5G
-END PGP SIGNATURE-
From b372b48016f5c015b34db9f53b7a54a64a5a84e8 Mon Sep 17 00:00:00 2001
From: Dan Walsh dwa...@redhat.com
Date: Mon, 18 Nov 2013 15:52:37 -0500
Subject: [PATCH] Fix SELinux check for snapshot and transitent unit creation.
SELinux does not have a path to check for a snapshot or transient
unit files service creation. Currently systemd does a bogus check.
If we don't have a unit file for a snapshot or transient unit we i
should check if the remote process label, has the required access
for a service with the SELinux label that systemd is running with.
Add SELINUX_SNAPSHOT_ACCESS_CHECK for non SELinux environments
---
src/core/dbus-manager.c | 2 +-
src/core/selinux-access.c | 9 +
src/core/selinux-access.h | 13 +
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 747bcfc..a60a568 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -1112,7 +1112,7 @@ static DBusHandlerResult bus_manager_message_handler(DBusConnection *connection,
dbus_bool_t cleanup;
Snapshot *s;
-SELINUX_ACCESS_CHECK(connection, message, start);
+SELINUX_SNAPSHOT_ACCESS_CHECK(connection, message, start);
if (!dbus_message_get_args(
message,
diff --git a/src/core/selinux-access.c b/src/core/selinux-access.c
index c7e951c..af34b9e 100644
--- a/src/core/selinux-access.c
+++ b/src/core/selinux-access.c
@@ -374,8 +374,9 @@ int selinux_access_check(
goto finish;
}
-if (path) {
-tclass = service;
+
+tclass = service;
+if (path strneq(path,system, strlen(system))) {
/* get the file context of the unit file */
r = getfilecon(path, fcon);
if (r 0
Re: [systemd-devel] [PATCH] selinux: fix selinux check for transient units
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/16/2013 08:10 AM, Lennart Poettering wrote:
On Thu, 14.11.13 15:43, Daniel J Walsh (dwa...@redhat.com) wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 11/14/2013 12:50 PM, Harald Hoyer wrote:
On 11/05/2013 11:12 PM, Daniel J Walsh wrote:
On 11/05/2013 12:22 PM, Lennart Poettering wrote:
Ok lets add a check that checks for start on a service labeled with
the remote process label, then we can add rules like
allow systemd_logind_t self:service start
Or we can make it simpler and have the local end check against the
init_t process.
allow systemd_logind_t init_t:service start;
Which is probably a better solution, if we have no way of
differentiating the services.
Machineid usually runs as init_t now.
systemd-run runs as the label of the process that executes it,
Usually unconfined_t, and sysadm_t.
has any solution been found for this?
seems like one is needed for
https://bugzilla.redhat.com/show_bug.cgi?id=1008864
I guess the question I have is do you expect a patch from me? Or are you
guys working on it? I would go with the checking based on process
label.
I am hoping for a patch for this!
Thanks,
Lennart
This patch adds a new call for SELINUX_SNAPSHOT_ACCESS_CHECK, because I
believe this error will happen when a snapshot is created. Also now pass in
system
when doing a system check, if it is doing a service check and does not pass in
a unit file we will default the target to the label that systemd is running
with.
How does this patch look?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKKhFgACgkQrlYvE4MpobNd1ACbBrwtl5T/CEhCttI9QZ3IZbes
k8UAoODr9J6D0CoyZfpdpvILU7QpxOD2
=0zYK
-END PGP SIGNATURE-
From d8e5784f64a68580f136b99cd5e3fd173586312f Mon Sep 17 00:00:00 2001
From: Dan Walsh dwa...@redhat.com
Date: Mon, 18 Nov 2013 15:52:37 -0500
Subject: [PATCH] Fix SELinux check for snapshot creation.
SELinux does not have a path to check for a snapshot servic creation.
This ends up giving us a bogus check.
On snapshot creation we should check if the remote process type, has the ability to start a service with the type that systemd is running with.
---
src/core/dbus-manager.c | 2 +-
src/core/selinux-access.c | 9 +
src/core/selinux-access.h | 12
3 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 747bcfc..a60a568 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -1112,7 +1112,7 @@ static DBusHandlerResult bus_manager_message_handler(DBusConnection *connection,
dbus_bool_t cleanup;
Snapshot *s;
-SELINUX_ACCESS_CHECK(connection, message, start);
+SELINUX_SNAPSHOT_ACCESS_CHECK(connection, message, start);
if (!dbus_message_get_args(
message,
diff --git a/src/core/selinux-access.c b/src/core/selinux-access.c
index c7e951c..af34b9e 100644
--- a/src/core/selinux-access.c
+++ b/src/core/selinux-access.c
@@ -374,8 +374,9 @@ int selinux_access_check(
goto finish;
}
-if (path) {
-tclass = service;
+
+tclass = service;
+if (path strneq(path,system, strlen(system))) {
/* get the file context of the unit file */
r = getfilecon(path, fcon);
if (r 0) {
@@ -384,9 +385,9 @@ int selinux_access_check(
log_error(Failed to get security context on %s: %m,path);
goto finish;
}
-
} else {
-tclass = system;
+if (path)
+tclass = system;
r = getcon(fcon);
if (r 0) {
dbus_set_error(error, DBUS_ERROR_ACCESS_DENIED, Failed to get current context.);
diff --git a/src/core/selinux-access.h b/src/core/selinux-access.h
index 2d7ac64..53bb9b0 100644
--- a/src/core/selinux-access.h
+++ b/src/core/selinux-access.h
@@ -36,6 +36,18 @@ int selinux_access_check(DBusConnection *connection, DBusMessage *message, const
DBusConnection *_c = (connection); \
DBusMessage *_m = (message);\
dbus_error_init(_error); \
+_r = selinux_access_check(_c, _m, system, (permission), _error); \
+if (_r 0) \
+return bus_send_error_reply(_c, _m, _error, _r); \
+} while (false)
+
+#define SELINUX_SNAPSHOT_ACCESS_CHECK(connection, message, permission) \
+do {\
+DBusError _error
Re: [systemd-devel] [PATCH] selinux: fix selinux check for transient units
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/14/2013 12:50 PM, Harald Hoyer wrote: On 11/05/2013 11:12 PM, Daniel J Walsh wrote: On 11/05/2013 12:22 PM, Lennart Poettering wrote: Ok lets add a check that checks for start on a service labeled with the remote process label, then we can add rules like allow systemd_logind_t self:service start Or we can make it simpler and have the local end check against the init_t process. allow systemd_logind_t init_t:service start; Which is probably a better solution, if we have no way of differentiating the services. Machineid usually runs as init_t now. systemd-run runs as the label of the process that executes it, Usually unconfined_t, and sysadm_t. has any solution been found for this? seems like one is needed for https://bugzilla.redhat.com/show_bug.cgi?id=1008864 I guess the question I have is do you expect a patch from me? Or are you guys working on it? I would go with the checking based on process label. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKFNdUACgkQrlYvE4MpobNuXACg1eKUvMGKMv5zuwKHDvj44K+F L6gAn3sQtD0QvGUUmJWRGRSolZTdOqN0 =pYrx -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: fix selinux check for transient units
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/04/2013 02:05 PM, Lennart Poettering wrote:
On Mon, 04.11.13 17:06, Lennart Poettering (lenn...@poettering.net) wrote:
On Thu, 31.10.13 15:51, Vaclav Pavlin (vpav...@redhat.com) wrote:
From: Václav Pavlín vpav...@redhat.com
Sorry, I don't understand what this patch is doing. Please explain in a
commit message!
Hmm, so, here's another idea. The transient units are created by a client
process. We could easily determine the label of that client process.
Wouldn't it a better approach to calculate the label of the transient units
somehow from the client process' label? This way wouldn't need any
additional systemd-specific infrastructure in libselinux.
Dan, could that work?
Lennart
I suppose it would. The only label we have the the clients is the process
label.
What process types create these runtime objects and what do they request to do
with them?
Currently systemd asks for permissions on system class and service class, where
class system
{
ipc_info
syslog_read
syslog_mod
syslog_console
module_request
halt
reboot
status
undefined
enable
disable
reload
}
class service
{
start
stop
status
reload
kill
load
enable
disable
}
Do we have to add a rule like
allow sysadm_t networkmanager_t:service start;
Were networkmanager_t is a process type?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJ3/gsACgkQrlYvE4MpobPWbQCfWElx/pR6cOjQKM1Ad0cE/eU1
cAcAoJ1k49KbB143/NJH/DEfl0aRLhnn
=eao5
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] FYI setroubleshoot has better integration with journald in F20
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://danwalsh.livejournal.com/65777.html I think we need a systemctl status -verbose httpd -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlH7vtoACgkQrlYvE4MpobO1CwCguI7lgjY5nTOixl+F00quSEf3 IXwAnRvz3n0EQxmtTYbe2o1lwyR3WC0O =rqqR -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] FYI setroubleshoot has better integration with journald in F20
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/02/2013 11:49 AM, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Aug 02, 2013 at 04:36:15PM +0200, Tomasz Torcz wrote: On Fri, Aug 02, 2013 at 10:14:50AM -0400, Daniel J Walsh wrote: http://danwalsh.livejournal.com/65777.html I think we need a systemctl status -verbose httpd --full is not enough? journalctl has recently learned to output properly indented multiline messages... SELinux hints look like perfect fit for existing ”-x” switch. Not really, because setroubleshoot crafts a specific message for each AVC. It *could* be done, by outputting separate structured messages from each of the setroubleshoot plugins, and adding the message template from each plugin to the catalog, so that then journalctl could fill them in. But that would tie setroubleshoot very closely to journalctl, and I'm not sure what the gain would be. Zbyszek Well I am looking for the user to see the entire multi-line message when running systemctl status UNITFILE Since this is where we want them to look first. Maybe have a comment at the bottom of systemctl status UNITFILE, that says run systemctl status --full UNITFILE to see full message. In the future when we eliminate the setroubleshoot.xml file and fully use the journal as our backing store, we can talk about that. The biggest thing would be for setroubleshoot to know if it saw the message before. Basically have a signature that it could look up. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlH7/1oACgkQrlYvE4MpobO99ACdEyHvkUbJ+WCSF/5JMi8haFkl zpQAnjRuv23cZtrLUtbLUJWcrwDIt/ua =Wyqu -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] We are working on trying to scale up to 1000 containers.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 One concern we have is what will happen to systemd if we start 1000 services at boot. systemctl start httpd_sandbox.target For example. Is there anything we can do to throttle the start of so many unit files. Or would systemd do something itself. This will probably cause libvirt problems also. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHAXGkACgkQrlYvE4MpobNXfgCgkT3Sd9XgV387b5GDLuGyweIO K0oAn16rai7GjT9NVI6MK7534qnLRf13 =zmnm -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/17/2013 04:50 PM, Lennart Poettering wrote: On Mon, 17.06.13 22:12, Tom Gundersen (t...@jklm.no) wrote: The only case, where this scheme would fail, is if you backup and restore a system to a different partitioning scheme. I agree with Lennart that we don't want this scheme, but rather something predictable. How about Colin's suggestion of putting hwdb.bin (and similar files that cannot always be in /var/cache) in /etc/cache? Or if anyone have the stomach for a huge fight, try to convince everyone of the usefulness of /cache? Well, this is about very few files only. AFAICS only systemd/udev, kmod, ld.so need binary caches around this early during boot. It sounds a bit like overkill to introduce an entirely new root level hierarchy for that. Note that beyond caches there are a number of non-text-files in /etc. For example /etc/localtime, /etc/selinux/targeted/policy/policy.27, /etc/pki/*.db, /etc/aliases.db, /etc/ld.so.cache, /etc/prelink.cache and so on. I am not convinced that text file vs. binary file is the best check to decide whether something belongs in /etc or not. Lennart One of these days I plan on getting the policy file out of /etc and into /usr/lib/selinux, But any customizations by the admin or other packages would end up putting content into /etc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG/fLgACgkQrlYvE4MpobPmQQCfeKqc3i3+JxaNMPFOxccPLesi q/EAniJUO5bYv+Ei9B5YPJpgZdtt3GoF =R+DF -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Any movement on adding a pid indicator for setroubleshoot to add to the journal entry.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Really would like to be able to track an alert back to the causing pid. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGI7dgACgkQrlYvE4MpobMxgACgpFVhYWfQiy5fABCzKLzzYqUb /swAoONAcKkF74MV9LpQZNGjrcRCIZvj =VYzt -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Any movement on adding a pid indicator for setroubleshoot to add to the journal entry.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2013 08:22 AM, Kay Sievers wrote: On Tue, May 7, 2013 at 2:04 PM, Daniel J Walsh dwa...@redhat.com wrote: Really would like to be able to track an alert back to the causing pid. You mean the: * introduce generic AUGMENT_PID=, AUGMENT_DEVICE= fields item in the TODO list, right? A facility that one process can submit information really belonging to another one, to the journal. In your case the setroubleshoot PID logs something about the apache service, and if we query the status of apache we get that setroubleshoot logs along with the logs that originated from apache, right? How do we handle the trust here? Allow that augmentation only for privileged processes? Kay Yes I would only allow priv processes to do this, I guess eventually we could add an SELinux check to this and maybe a capability check like, CAP_SYSLOG? But for now, just check that the UID==0 of the process doing an AUGMENT_PID. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGI9PwACgkQrlYvE4MpobMqVwCeIf5WDUy/HX1Ft2o8GFlZYaza t/wAmgPTn+EX6h8PYGcR9tYuZjRjVeI2 =WW6I -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Secure Linux Containers. I have masked down the systemd starting most daemons within containers.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2013 09:08 AM, Lennart Poettering wrote: On Thu, 14.02.13 07:16, Daniel J Walsh (dwa...@redhat.com) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Welcome to Fedora 19 (Rawhide)! Set hostname to lincoln3. /dev/mapper/control: mknod failed: Operation not permitted Failure to communicate with kernel device-mapper driver. Check that device-mapper is available in the kernel. [ OK ] Listening on Delayed Shutdown Socket. [ OK ] Reached target Swap. [ OK ] Reached target Local File Systems. [ OK ] Listening on Journal Socket. Starting Recreate Volatile Files and Directories... Starting Journal Service... [ OK ] Started Journal Service. [ OK ] Started Recreate Volatile Files and Directories. [ OK ] Reached target System Initialization. [ OK ] Listening on D-Bus System Message Bus Socket. [ OK ] Reached target Sockets. [ OK ] Reached target Basic System. Starting The Apache HTTP Server... [ OK ] Started The Apache HTTP Server. [ OK ] Reached target Sandbox multi-user target. Failed to issue method call: Unit chronyd.service is not loaded. As you can see, it looks like systemd is attempting to start some lvm stuff and crond. Any ideas on where this stuff is being started? I want neither to run within the container. Is this still relevant? LVM is probably invoked from the fedora units for it. You might be able to mask them. Or you might be able to convince the LVM folks to conditionalize them somehow, for example via ConditionVirtualization=!container or ConditionCapabilities=CAP_MKNOD or so. The crond unit you should be able to simply disable. Lennart Well I still have the LVM Problem /dev/mapper/control: mknod failed: Operation not permitted Failure to communicate with kernel device-mapper driver. Check that device-mapper is available in the kernel. Default target could not be isolated, starting instead: Operation refused, unit may not be isolated. Everything else seems to be working fine now. # systemctl list-units UNIT LOAD ACTIVE SUB DESCRIPTION - -.mountloaded active mounted / boot.mount loaded active mounted /boot dev-ptmx.mount loaded active mounted /dev/ptmx etc-fstab.mountloaded active mounted /etc/fstab etc-hostname.mount loaded active mounted /etc/hostname etc-httpd.mountloaded active mounted /etc/httpd etc-libvirt\x2dsandbox-scratch.mount loaded active mounted /etc/libvirt-sandbox/scratch etc-machine\x2did.mountloaded active mounted /etc/machine-id etc-rc.d.mount loaded active mounted /etc/rc.d etc-systemd-system.mount loaded active mounted /etc/systemd/system home.mount loaded active mounted /home proc-meminfo.mount loaded active mounted /proc/meminfo root.mount loaded active mounted /root run-libvirt-lxc-dan1.mount loaded active mounted /run/libvirt/lxc/dan1 run-user-3267-gvfs.mount loaded active mounted /run/user/3267/gvfs tmp.mount loaded active mounted Temporary Directory usr-lib-syste...naconda.target.wants.mount loaded active mounted /usr/lib/systemd/system/anaconda.target.wa usr-lib-syste...m-basic.target.wants.mount loaded active mounted /usr/lib/systemd/system/basic.target.wants usr-lib-syste...l\x2dfs.target.wants.mount loaded active mounted /usr/lib/systemd/system/local-fs.target.wa usr-lib-syste...x2duser.target.wants.mount loaded active mounted /usr/lib/systemd/system/multi-user.target. usr-lib-syste...sockets.target.wants.mount loaded active mounted /usr/lib/systemd/system/sockets.target.wan usr-lib-syste...sysinit.target.wants.mount loaded active mounted /usr/lib/systemd/system/sysinit.target.wan var-lib-nfs-rpc_pipefs.mount loaded active mounted RPC Pipe File System var.mount loaded active mounted /var dbus.service loaded active running D-Bus System Message Bus httpd.service loaded active running The Apache HTTP Server systemd-journald.service loaded active running Journal Service systemd-logind.service loaded active running Login Service systemd-tmpfiles-setup.service loaded active exitedRecreate Volatile Files and Directories dbus.socketloaded active running D-Bus System Message Bus Socket systemd-journald.socketloaded active running Journal Socket systemd-shutdownd.socket loaded active listening Delayed Shutdown Socket dev-dm
[systemd-devel] Secure Linux Containers. I have masked down the systemd starting most daemons within containers.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Welcome to Fedora 19 (Rawhide)! Set hostname to lincoln3. /dev/mapper/control: mknod failed: Operation not permitted Failure to communicate with kernel device-mapper driver. Check that device-mapper is available in the kernel. [ OK ] Listening on Delayed Shutdown Socket. [ OK ] Reached target Swap. [ OK ] Reached target Local File Systems. [ OK ] Listening on Journal Socket. Starting Recreate Volatile Files and Directories... Starting Journal Service... [ OK ] Started Journal Service. [ OK ] Started Recreate Volatile Files and Directories. [ OK ] Reached target System Initialization. [ OK ] Listening on D-Bus System Message Bus Socket. [ OK ] Reached target Sockets. [ OK ] Reached target Basic System. Starting The Apache HTTP Server... [ OK ] Started The Apache HTTP Server. [ OK ] Reached target Sandbox multi-user target. Failed to issue method call: Unit chronyd.service is not loaded. As you can see, it looks like systemd is attempting to start some lvm stuff and crond. Any ideas on where this stuff is being started? I want neither to run within the container. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEc1YkACgkQrlYvE4MpobMGQwCfT/jvY0w4QzdNl/ppCwmCtIDk HSAAoInIj7gwN88KJEEy1AHVOtaC7Qsg =mtsv -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Simple question.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/26/2013 08:07 PM, David Strauss wrote: On Fri, Jan 25, 2013 at 12:42 PM, Mantas Mikulėnas graw...@gmail.com wrote: That some users may want to take advantage of modern Linux features and run httpd without *ever* giving it full root privileges – which it needs for precisely two things, bind() and setuid(). That's another reason why socket activation is great for server environments. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel I am trying to implement the OpenShift model using Secure Linux Containers. Each Gear/User in an OpenShift environment has an apache service listening on port 8080 (I believe) on a localhost IPAddress. The host machine also has an apache service running on port 80, When packets come into the host the apache service sends them to the correct gear/apache server. Currently this is done by using some complicated scripting and limited file system namespace separation. I am interested if we could prototype this environment using a full Linux Container environment, where each one of the gears lives in a separate container, with its own systemd, and apache service, running as the users UID. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEJHVIACgkQrlYvE4MpobPwLQCeOXFm4Su19hjrdglWmOXMzA7a u64AoIHSBufUuld8Pj467Zv1rkA3YJYC =ZIZo -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux-access: Delete debugging message logged as an error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/24/2013 10:47 PM, Lennart Poettering wrote: On Thu, 24.01.13 17:47, Colin Walters (walt...@verbum.org) wrote: I don't see why this should be logged at all, so let's delete it. Applied. I also removed a couple of other messages that appear a bit too much to me. Lennart I agree those should be deleted. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlECiDMACgkQrlYvE4MpobNSpgCgrfOB5oonk6FtPBFRIakQeBh7 FvcAn36Fr4ZAiMkfA3LnQnh74PiEq1jT =ZCMu -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Simple question.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 How would I write a unit file to run an apache service as the user dwalsh (3267) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlECthIACgkQrlYvE4MpobNjEQCffDaCsrGq13sqNtJ+FKTLzMvy 3twAn0ST0oF8g8XG7ZQefjRhHwJzlAnN =2qMt -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setroubleshoot integration.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/2013 11:55 AM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jan 09, 2013 at 05:44:02PM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jan 09, 2013 at 11:00:36AM -0500, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 One of my goals with setroubleshoot analysys is to get it integrated into the journald system. In Fedora I am adding systemd.journal.send(siginfo.format_text()) Which will put the setroubleshoot info into the journal, but what I really need is to add a key for the process id that created the journal entry. We had talked about this a while ago with the goal of allowing something like systemctl httpd status SELinux is blocking httpd read access on /var/www/index.html setroubleshoot ... run restorecon /var/www/index.html The only way for systemd to know the setroubleshoot analysys is for httpd is to include the pid when setroubleshoot writes the journal. Hi, the way that finding messages pertaining to a certain service works currently is encoded in src/share/logs-show.c, function show_journal_by_unit: - journald adds _SYSTEMD_UNIT=... when it can to messages generated by the services themselves - systemd (PID 1) writes messages about services with UNIT=... and journalds tags them with _PID=1 - COREDUMP writes messages with COREDUMP_UNIT=... I think it would be realitively to extend show_journal_by_unit() to check ^relatively easy for messages with _SYSTEMD_UNIT=setroubleshootd.service (or whatever) and UNIT=... Would this work for you? This would require setroubleshootd to find out the unit name on its own. Actually, this might be for the better, since by the time that journald gets the message, the PID might be long gone, and setroubleshootd has more knowledge. A second part would be support for multiline messages. This is another story. Zbyszek Well I got two problems, then. How does setroubleshoot figure out which unit file is associated with a pid? (From python). And if the pid is not associated with a unit file but with a User or something else (systemd itself), what should I do? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDtqVkACgkQrlYvE4MpobNIggCeMZKTjZJJnWEaU3nGi89HZmJK SdEAoKhh/x2T+f2uOydgjCMBxHz3oYoq =gtQC -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setroubleshoot integration.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/2013 01:42 PM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jan 09, 2013 at 12:31:05PM -0500, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/2013 11:55 AM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jan 09, 2013 at 05:44:02PM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jan 09, 2013 at 11:00:36AM -0500, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 One of my goals with setroubleshoot analysys is to get it integrated into the journald system. In Fedora I am adding systemd.journal.send(siginfo.format_text()) Which will put the setroubleshoot info into the journal, but what I really need is to add a key for the process id that created the journal entry. We had talked about this a while ago with the goal of allowing something like systemctl httpd status SELinux is blocking httpd read access on /var/www/index.html setroubleshoot ... run restorecon /var/www/index.html The only way for systemd to know the setroubleshoot analysys is for httpd is to include the pid when setroubleshoot writes the journal. Hi, the way that finding messages pertaining to a certain service works currently is encoded in src/share/logs-show.c, function show_journal_by_unit: - journald adds _SYSTEMD_UNIT=... when it can to messages generated by the services themselves - systemd (PID 1) writes messages about services with UNIT=... and journalds tags them with _PID=1 - COREDUMP writes messages with COREDUMP_UNIT=... I think it would be realitively to extend show_journal_by_unit() to check ^relatively easy for messages with _SYSTEMD_UNIT=setroubleshootd.service (or whatever) and UNIT=... Would this work for you? This would require setroubleshootd to Probably SYSTEMD_UNIT would be better here. find out the unit name on its own. Actually, this might be for the better, since by the time that journald gets the message, the PID might be long gone, and setroubleshootd has more knowledge. A second part would be support for multiline messages. This is another story. Zbyszek Well I got two problems, then. How does setroubleshoot figure out which unit file is associated with a pid? (From python). We could either expose the C functions (sd_pid_get_session is already public, and it would be nice to add a Python interface, shortened_cgroup_path could be easily made public, cg_pid_get_unit is not public yet either), or create a rewrite in Python and put it in the systemd-python package, or even do nothing and let each user rewrite it. I think option two would be easiest, but maybe option one is worth pursuing. Option two would be a bit more work, but might help keep things synchronized in the future. Yeah, it seems best, since the combined work required to rewrite sd_pid_get_session, shortened_cgroup_path, and cg_pid_get_unit is pretty big. And if the pid is not associated with a unit file but with a User or something else (systemd itself), what should I do? I think just duplicate journald logic: add SYSTEMD_SESSION, SYSTEMD_OWNER_UID if possible, or nothing. Zbyszek Sounds good, but is this something I should open a bugzilla for? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDtvOYACgkQrlYvE4MpobMsJgCgiP8/7031ZK+3+xeoK1hY5dOw jkEAnRMa+JPe4J292ejRADWKCUB8M5tF =hdWy -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setroubleshoot integration.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/2013 02:49 PM, Lennart Poettering wrote: On Wed, 09.01.13 17:44, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: systemctl httpd status SELinux is blocking httpd read access on /var/www/index.html setroubleshoot ... run restorecon /var/www/index.html The only way for systemd to know the setroubleshoot analysys is for httpd is to include the pid when setroubleshoot writes the journal. Hi, the way that finding messages pertaining to a certain service works currently is encoded in src/share/logs-show.c, function show_journal_by_unit: - journald adds _SYSTEMD_UNIT=... when it can to messages generated by the services themselves - systemd (PID 1) writes messages about services with UNIT=... and journalds tags them with _PID=1 - COREDUMP writes messages with COREDUMP_UNIT=... I think it would be realitively to extend show_journal_by_unit() to check for messages with _SYSTEMD_UNIT=setroubleshootd.service (or whatever) and UNIT=... Would this work for you? This would require setroubleshootd to find out the unit name on its own. Actually, this might be for the better, since by the time that journald gets the message, the PID might be long gone, and setroubleshootd has more knowledge. Oh, uhm, I was envisioning a much simpler, more generic solution for this. Something as simple as this: We'd define a new special field OBJECT_PID. If this is included in a message, and that message comes from a privileged service, then journald will automatically add in OBJECT_EXE, OBJECT_UID, OBJECT_COMM, OBJECT_UNIT ... from /proc. That way, all setroubleshoot would have to do is add this one property to its messages, and systemd would do the rest. In fact, not only setroubleshoot could make use of that. For example, PolicyKit might too. Much like setroubleshoot it needs to log messages about specific processes (in this case clients), and could benefit from implicit augmentation of the message by journald. Eventually we might want to add the same for OBJECT_DEVICE or so, in case device managers want to logs things about devices or so. Implementation of this scheme on the systemd side should be fairly simple, but even more so on the setroubleshoot side. Does this make sense? Lennart I like the idea, (Less work for me. ) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDty9QACgkQrlYvE4MpobNyxgCgx+Yr84oc4w4BSeENar/9Sp60 nOkAn0tzQ1G2fkh+UFp1MIZkdh6rhIWt =wPGg -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setroubleshoot integration.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/2013 04:52 PM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jan 09, 2013 at 02:58:12PM -0500, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/2013 02:49 PM, Lennart Poettering wrote: On Wed, 09.01.13 17:44, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: systemctl httpd status SELinux is blocking httpd read access on /var/www/index.html setroubleshoot ... run restorecon /var/www/index.html The only way for systemd to know the setroubleshoot analysys is for httpd is to include the pid when setroubleshoot writes the journal. Hi, the way that finding messages pertaining to a certain service works currently is encoded in src/share/logs-show.c, function show_journal_by_unit: - journald adds _SYSTEMD_UNIT=... when it can to messages generated by the services themselves - systemd (PID 1) writes messages about services with UNIT=... and journalds tags them with _PID=1 - COREDUMP writes messages with COREDUMP_UNIT=... I think it would be realitively to extend show_journal_by_unit() to check for messages with _SYSTEMD_UNIT=setroubleshootd.service (or whatever) and UNIT=... Would this work for you? This would require setroubleshootd to find out the unit name on its own. Actually, this might be for the better, since by the time that journald gets the message, the PID might be long gone, and setroubleshootd has more knowledge. Oh, uhm, I was envisioning a much simpler, more generic solution for this. Something as simple as this: We'd define a new special field OBJECT_PID. If this is included in a message, and that message comes from a privileged service, then journald will automatically add in OBJECT_EXE, OBJECT_UID, OBJECT_COMM, OBJECT_UNIT ... from /proc. OK, that would work too. How is a privileged service defined? Zbyszek UID=0 for now I would guess, until I hack into it with SELinux... That way, all setroubleshoot would have to do is add this one property to its messages, and systemd would do the rest. In fact, not only setroubleshoot could make use of that. For example, PolicyKit might too. Much like setroubleshoot it needs to log messages about specific processes (in this case clients), and could benefit from implicit augmentation of the message by journald. Eventually we might want to add the same for OBJECT_DEVICE or so, in case device managers want to logs things about devices or so. Implementation of this scheme on the systemd side should be fairly simple, but even more so on the setroubleshoot side. Does this make sense? Lennart I like the idea, (Less work for me. ) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDt6RYACgkQrlYvE4MpobPgggCdG7oEeE709xl9qG7PzoEzChwi UZIAoL4CQkLOFpsM8Y1szdGHA5uWOeF8 =X7fb -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] I added the uuid to match a container to /var/log/journal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ls -l /var/log/journal/ total 12 drwxr-xr-x. 2 root root 12288 Nov 16 08:47 1b16d5a8cec649e7ba7d9f9f6ef8f393 lrwxrwxrwx. 1 root root52 Nov 13 15:24 1f9684eeed2d43d3bfee702a89f849d6 - /var/lib/libvirt/filesystems/apache1/var/log/journal lrwxrwxrwx. 1 root root48 Nov 13 15:29 99f38a5c9bfd46bab46cc8e2685bee65 - /var/lib/libvirt/filesystems/dan/var/log/journal How would I go about viewing the log file in journalctl? Also in talks about containers, a discussion came up about using syslog to off load container logs to a centralized server. Is there a way to collect the data from journald/containers into the host systems syslog? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCmS8QACgkQrlYvE4MpobPR3wCfcidpc7OJf8pJHNv8fwumeFSH 4ZQAn3jBn/9w9bAU5+cJlGzYNQ1aBLLo =tfYR -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The only problem I see is that now sysV init scripts are firing off within the container. (iSCSI daemon). What can I do to stop this within the container? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCmTG4ACgkQrlYvE4MpobNS8ACgqJU1ADDnId43Roa2H1x0c81c p1gAnjn1glOuV4vfHsmWl7IyN6yNyCOB =dgtw -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/16/2012 02:56 PM, Lennart Poettering wrote: On Fri, 16.11.12 09:23, Daniel J Walsh (dwa...@redhat.com) wrote: The only problem I see is that now sysV init scripts are firing off within the container. (iSCSI daemon). What can I do to stop this within the container? Services such as the iscsi daemon which one can sort in the driver category should never run in containers I believe. To automaticalky execution of these services in containers you can use ConditionVirtualization (as Colin already suggested). ConditionVirtualization=!container should do the job. (See systemd.unit(5) for details). That said, iscsid on Fedora currently is still a sysv script, which is a bit disappointing, and there's hence no place to add ConditionVirtualization=. My recommendation would be to get the iscsi folks to convert it into a systemd unit file, they should do that anyway soon. But as a temporary work-around you could just mask the unit in your container. Just add a symlink to /dev/null for /etc/systemd/system/iscsi.service and it will mask the sysv service and make it entirely unavailable. See this for details: http://0pointer.de/blog/projects/three-levels-of-off.html That said, manually masking things in the container in your script really is hacky, and I am pretty sure the better way is to get iscsid fixed to become a native systemd unit file that usese ConditionVirtualization to disable itself in a container. Lennart Isn't there a way to shut off systemV init scripts altogether, it just so happens that we hit one on my machine. But in the field a customer could have an init script and then setup containers and systemd will attempt to start it. I want a way to say don't run SysV Init scripts altogether. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCmnNgACgkQrlYvE4MpobNKyQCcCIVQS/FuvOg3wWYi6AvgFMAw mI4AnA14UHY47GUd1uQROjDXmlv1TmDT =Ew3x -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] SELinux patch still broken, in that we are not checking the correct source context.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This patch does the dbus calls correctly.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlB3NOUACgkQrlYvE4MpobOFCACgvMzYDOUYb+THKlSZF2+RcSfD
8R8AnRgG1DMDW0XkH/raf+W4ctXLdL6L
=zUUU
-END PGP SIGNATURE-
diff --git a/src/core/selinux-access.c b/src/core/selinux-access.c
index d9c3f9b..974e9fe 100644
--- a/src/core/selinux-access.c
+++ b/src/core/selinux-access.c
@@ -59,7 +59,11 @@ static int bus_get_selinux_security_context(
DBusError *error) {
_cleanup_dbus_message_unref_ DBusMessage *m = NULL, *reply = NULL;
+ DBusMessageIter iter, sub;
+ char *bytes;
+ int nbytes;
+log_debug(GetConnectionSELinuxSecurityContext);
m = dbus_message_new_method_call(
DBUS_SERVICE_DBUS,
DBUS_PATH_DBUS,
@@ -85,11 +89,21 @@ static int bus_get_selinux_security_context(
if (dbus_set_error_from_message(error, reply))
return -EIO;
-if (!dbus_message_get_args(
-reply, error,
-DBUS_TYPE_STRING, scon,
-DBUS_TYPE_INVALID))
-return -EIO;
+if (!dbus_message_iter_init (reply, iter))
+ return -EIO;
+
+if (dbus_message_iter_get_arg_type (iter) != DBUS_TYPE_ARRAY)
+ return -EIO;
+
+ dbus_message_iter_recurse (iter, sub);
+ dbus_message_iter_get_fixed_array (sub, bytes, nbytes);
+
+ *scon = calloc(1, nbytes + 1);
+ if (!*scon)
+return -ENOMEM;
+ strncpy(*scon, bytes, nbytes);
+
+log_debug(GetConnectionSELinuxSecurityContext %s (pid %ld), *scon, (long) bus_get_unix_process_id(connection, name, error));
return 0;
}
@@ -293,14 +307,17 @@ static int get_calling_context(
*/
sender = dbus_message_get_sender(message);
if (sender) {
+log_error(SELinux Got Sender %s, sender);
+
r = bus_get_selinux_security_context(connection, sender, scon, error);
if (r = 0)
return r;
-log_debug(bus_get_selinux_security_context failed %m);
-dbus_error_free(error);
+log_error(bus_get_selinux_security_context failed %m);
+return r;
}
+log_debug(SELinux No Sender);
if (!dbus_connection_get_unix_fd(connection, fd)) {
log_error(bus_connection_get_unix_fd failed %m);
return -EINVAL;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] selabel_lookup_raw can return ENOENT and be a non failure mode.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEUEARECAAYFAlB3NV8ACgkQrlYvE4MpobP7wwCY6mI+73m3XXJk2xtrjTloWoIG
VgCgo7xK8/EuGzBdKs7lXAWYYRi923M=
=nqZY
-END PGP SIGNATURE-
diff --git a/src/shared/label.c b/src/shared/label.c
index 2062fc3..d353da5 100644
--- a/src/shared/label.c
+++ b/src/shared/label.c
@@ -186,7 +186,7 @@ int label_context_set(const char *path, mode_t mode) {
return 0;
r = selabel_lookup_raw(label_hnd, filecon, path, mode);
-if (r 0)
+if (r 0 errno != ENOENT)
r = -errno;
else if (r == 0) {
r = setfscreatecon(filecon);
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Latest SELinux patch off of 760c85c0bdf02d68589971b869f61038e7893d75
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBls7MACgkQrlYvE4MpobPaUgCg4rejxmHdP7jkO38+KR/31ONL
lGYAn36W0Hi80AX1UCfXyLyBJDW8C3AO
=UTqj
-END PGP SIGNATURE-
diff --git a/src/core/selinux-access.c b/src/core/selinux-access.c
index 5edb09a..732fcbf 100644
--- a/src/core/selinux-access.c
+++ b/src/core/selinux-access.c
@@ -252,9 +252,22 @@ static int audit_callback(void *auditdata, security_class_t cls,
{
struct auditstruct *audit = (struct auditstruct *) auditdata;
snprintf(msgbuf, msgbufsize,
- name=\%s\ cmdline=\%s\ auid=%d uid=%d gid=%d,
- audit-path, audit-cmdline, audit-loginuid,
+ auid=%d uid=%d gid=%d,
+ audit-loginuid,
audit-uid, audit-gid);
+
+if (audit-path) {
+ strncat(msgbuf, path=\, msgbufsize);
+ strncat(msgbuf, audit-path, msgbufsize);
+ strncat(msgbuf,\, msgbufsize);
+}
+
+if (audit-cmdline) {
+ strncat(msgbuf, cmdline=\, msgbufsize);
+ strncat(msgbuf, audit-cmdline, msgbufsize);
+ strncat(msgbuf,\, msgbufsize);
+}
+
return 0;
}
@@ -295,7 +308,7 @@ static int access_init(void) {
int r = -1;
if (avc_open(NULL, 0)) {
-log_full(LOG_ERR, avc_open failed: %m\n);
+log_error(avc_open failed: %m);
return -errno;
}
@@ -329,13 +342,12 @@ static int selinux_init(Manager *m, DBusError *error) {
/* if not first time is not set, then initialize access */
r = access_init();
if (r 0) {
-dbus_set_error(error, DBUS_ERROR_ACCESS_DENIED, Unable to initialize SELinux.);
-
+dbus_set_error(error, DBUS_ERROR_ACCESS_DENIED, Failed to initialize SELinux.);
return r;
}
-first_time = 0;
}
+first_time = 0;
return 0;
}
@@ -392,6 +404,7 @@ static int get_calling_context(
const char *sender;
int r;
+int fd;
/*
If sender exists then
@@ -401,17 +414,22 @@ static int get_calling_context(
sender = dbus_message_get_sender(message);
if (sender) {
r = bus_get_selinux_security_context(connection, sender, scon, error);
-if (r 0)
-return -EINVAL;
-} else {
-int fd;
-r = dbus_connection_get_unix_fd(connection, fd);
-if (! r)
-return -EINVAL;
+if (r == 0)
+return 0;
-r = getpeercon(fd, scon);
-if (r 0)
-return -errno;
+log_debug(bus_get_selinux_security_context failed %m);
+}
+
+r = dbus_connection_get_unix_fd(connection, fd);
+if (! r) {
+log_error(bus_connection_get_unix_fd failed %m);
+return -EINVAL;
+}
+
+r = getpeercon(fd, scon);
+if (r 0) {
+log_error(getpeercon failed %m);
+return -errno;
}
return 0;
@@ -461,15 +479,18 @@ static int selinux_access_check(DBusConnection *connection, DBusMessage *message
audit.path = path;
r = get_calling_context(connection, message, scon, error);
-if (r != 0)
+if (r != 0) {
+log_error(Failed to get caller's security context on: %m);
goto finish;
-
+}
if (path) {
tclass = service;
/* get the file context of the unit file */
r = getfilecon(path, fcon);
if (r 0) {
-log_full(LOG_ERR, Failed to get security context on: %s %m\n,path);
+dbus_set_error(error, DBUS_ERROR_ACCESS_DENIED, Failed to get file context on %s., path);
+r = -errno;
+log_error(Failed to get security context on: %s %m,path);
goto finish;
}
@@ -477,7 +498,9 @@ static int selinux_access_check(DBusConnection *connection, DBusMessage *message
tclass = system;
r = getcon(fcon);
if (r 0) {
-dbus_set_error(error, DBUS_ERROR_ACCESS_DENIED, Unable to get current context, SELinux policy denies access.);
+dbus_set_error(error, DBUS_ERROR_ACCESS_DENIED, Failed to get current context.);
+r = -errno;
+log_error(Failed to get current process context on: %m);
goto finish;
}
}
@@ -488,16 +511,12 @@ static int selinux_access_check(DBusConnection *connection,
Re: [systemd-devel] Latest SELinux patch off of 760c85c0bdf02d68589971b869f61038e7893d75
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Another attempt with potential buffer overflow bug fixed.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBlw1oACgkQrlYvE4MpobMLFwCfduUwrF8RRyOHGwVFxsQZZwzM
JysAoKEpmEqbUTh85Cc/7gKiYyZZy0CY
=Hsk7
-END PGP SIGNATURE-
diff --git a/src/core/selinux-access.c b/src/core/selinux-access.c
index 5edb09a..79909be 100644
--- a/src/core/selinux-access.c
+++ b/src/core/selinux-access.c
@@ -252,9 +252,15 @@ static int audit_callback(void *auditdata, security_class_t cls,
{
struct auditstruct *audit = (struct auditstruct *) auditdata;
snprintf(msgbuf, msgbufsize,
- name=\%s\ cmdline=\%s\ auid=%d uid=%d gid=%d,
- audit-path, audit-cmdline, audit-loginuid,
- audit-uid, audit-gid);
+ auid=%d uid=%d gid=%d%s%s%s%s%s%s,
+ audit-loginuid,
+ audit-uid, audit-gid,
+ (audit-path ? path=\ : ),
+ (audit-path ?: ),
+ (audit-path ? \ : ),
+ (audit-cmdline ? cmdline=\ : ),
+ (audit-cmdline ?: ),
+ (audit-cmdline ? \ : ));
return 0;
}
@@ -295,7 +301,7 @@ static int access_init(void) {
int r = -1;
if (avc_open(NULL, 0)) {
-log_full(LOG_ERR, avc_open failed: %m\n);
+log_error(avc_open failed: %m);
return -errno;
}
@@ -329,13 +335,12 @@ static int selinux_init(Manager *m, DBusError *error) {
/* if not first time is not set, then initialize access */
r = access_init();
if (r 0) {
-dbus_set_error(error, DBUS_ERROR_ACCESS_DENIED, Unable to initialize SELinux.);
-
+dbus_set_error(error, DBUS_ERROR_ACCESS_DENIED, Failed to initialize SELinux.);
return r;
}
-first_time = 0;
}
+first_time = 0;
return 0;
}
@@ -392,6 +397,7 @@ static int get_calling_context(
const char *sender;
int r;
+int fd;
/*
If sender exists then
@@ -401,17 +407,22 @@ static int get_calling_context(
sender = dbus_message_get_sender(message);
if (sender) {
r = bus_get_selinux_security_context(connection, sender, scon, error);
-if (r 0)
-return -EINVAL;
-} else {
-int fd;
-r = dbus_connection_get_unix_fd(connection, fd);
-if (! r)
-return -EINVAL;
+if (r == 0)
+return 0;
-r = getpeercon(fd, scon);
-if (r 0)
-return -errno;
+log_debug(bus_get_selinux_security_context failed %m);
+}
+
+r = dbus_connection_get_unix_fd(connection, fd);
+if (! r) {
+log_error(bus_connection_get_unix_fd failed %m);
+return -EINVAL;
+}
+
+r = getpeercon(fd, scon);
+if (r 0) {
+log_error(getpeercon failed %m);
+return -errno;
}
return 0;
@@ -461,15 +472,18 @@ static int selinux_access_check(DBusConnection *connection, DBusMessage *message
audit.path = path;
r = get_calling_context(connection, message, scon, error);
-if (r != 0)
+if (r != 0) {
+log_error(Failed to get caller's security context on: %m);
goto finish;
-
+}
if (path) {
tclass = service;
/* get the file context of the unit file */
r = getfilecon(path, fcon);
if (r 0) {
-log_full(LOG_ERR, Failed to get security context on: %s %m\n,path);
+dbus_set_error(error, DBUS_ERROR_ACCESS_DENIED, Failed to get file context on %s., path);
+r = -errno;
+log_error(Failed to get security context on: %s %m,path);
goto finish;
}
@@ -477,7 +491,9 @@ static int selinux_access_check(DBusConnection *connection, DBusMessage *message
tclass = system;
r = getcon(fcon);
if (r 0) {
-dbus_set_error(error, DBUS_ERROR_ACCESS_DENIED, Unable to get current context, SELinux policy denies access.);
+dbus_set_error(error, DBUS_ERROR_ACCESS_DENIED, Failed to get current context.);
+r = -errno;
+log_error(Failed to get current process context on: %m);
goto finish;
}
}
@@ -488,16 +504,12 @@ static int
[systemd-devel] New SELinux Patch to fix gettys not starting and poweroff/reboot commands from userspace working.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lots of new debugging/Error messages, to figure out what was failing.
Fix audit messages to not add cmdline of path if it does not exist.
Fix handling of initilization of selinux libraries.
Use log_error instead of log_full(LOG_ERROR
If bus_get_selinux_security_context fails, try to get the PID of the remote
connection and use this to get security context.
Set r -errno when the error happens, not on exit.
Use selinux_getenforce() rather then relying on global, since the global is
not always up2date.
Call multiple dbus_message_get_args to try to get name field. One with three
params, one with two and one with one. dbus-manager needs to be cleaned up,
and then we could change SELinux patch to take either a unit file or just a
path.
Stop returning errors, if SELinux can not complete checks. We can probably
turn this back on, but I wanted to make sure systemd would work in the field
before tightening this up.
You also need an updated SELINux policy to make this work.
selinux-policy-3.11.1-24.fc18.noarch
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBhECMACgkQrlYvE4MpobOv1ACfdXIAZ0WVim8I3wRAK2IlsLcB
150An0e8+Uv/EkPZWzrtytURUIOvwvDC
=uv/J
-END PGP SIGNATURE-
diff --git a/src/core/selinux-access.c b/src/core/selinux-access.c
index 8513634..9587065 100644
--- a/src/core/selinux-access.c
+++ b/src/core/selinux-access.c
@@ -252,9 +252,22 @@ static int audit_callback(void *auditdata, security_class_t cls,
{
struct auditstruct *audit = (struct auditstruct *) auditdata;
snprintf(msgbuf, msgbufsize,
- name=\%s\ cmdline=\%s\ auid=%d uid=%d gid=%d,
- audit-path, audit-cmdline, audit-loginuid,
+ auid=%d uid=%d gid=%d,
+ audit-loginuid,
audit-uid, audit-gid);
+
+if (audit-path) {
+ strncat(msgbuf, path=\, msgbufsize);
+ strncat(msgbuf, audit-path, msgbufsize);
+ strncat(msgbuf,\, msgbufsize);
+}
+
+if (audit-cmdline) {
+ strncat(msgbuf, cmdline=\, msgbufsize);
+ strncat(msgbuf, audit-cmdline, msgbufsize);
+ strncat(msgbuf,\, msgbufsize);
+}
+
return 0;
}
@@ -295,7 +308,7 @@ static int access_init(void) {
int r = -1;
if (avc_open(NULL, 0)) {
-log_full(LOG_ERR, avc_open failed: %m\n);
+log_error(avc_open failed: %m);
return -errno;
}
@@ -329,13 +342,13 @@ static int selinux_init(Manager *m, DBusError *error) {
/* if not first time is not set, then initialize access */
r = access_init();
if (r 0) {
-dbus_set_error(error, BUS_ERROR_ACCESS_DENIED, Unable to initialize SELinux.);
+dbus_set_error(error, BUS_ERROR_ACCESS_DENIED, Failed to initialize SELinux.);
return r;
}
-first_time = 0;
}
+first_time = 0;
return 0;
}
@@ -392,6 +405,7 @@ static int get_calling_context(
const char *sender;
int r;
+int fd;
/*
If sender exists then
@@ -401,17 +415,22 @@ static int get_calling_context(
sender = dbus_message_get_sender(message);
if (sender) {
r = bus_get_selinux_security_context(connection, sender, scon, error);
-if (r 0)
-return -EINVAL;
-} else {
-int fd;
-r = dbus_connection_get_unix_fd(connection, fd);
-if (! r)
-return -EINVAL;
+if (r == 0)
+return 0;
-r = getpeercon(fd, scon);
-if (r 0)
-return -errno;
+log_debug(bus_get_selinux_security_context failed %m);
+}
+
+r = dbus_connection_get_unix_fd(connection, fd);
+if (! r) {
+log_error(bus_connection_get_unix_fd failed %m);
+return -EINVAL;
+}
+
+r = getpeercon(fd, scon);
+if (r 0) {
+log_error(getpeercon failed %m);
+return -errno;
}
return 0;
@@ -461,15 +480,18 @@ static int selinux_access_check(DBusConnection *connection, DBusMessage *message
audit.path = path;
r = get_calling_context(connection, message, scon, error);
-if (r != 0)
+if (r != 0) {
+log_error(Failed to get caller's security context on: %m);
goto finish;
-
+}
if (path) {
tclass = service;
/* get the file context of the unit file */
r = getfilecon(path, fcon);
if (r 0) {
-log_full(LOG_ERR, Failed to get security
[systemd-devel] No TTY and inability to shutdown/reboot from user session
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seems to be SELinux patch is causing systemd-logind not to be able to send dbus message to systemd. In the logs I see this message Sep 21 16:57:39 celtics systemd-logind[874]: System is powering down. Sep 21 16:57:39 celtics systemd-logind[874]: Failed to issue method call: Resource temporarily unavailable Which looks like the dbus call is failing. I believe this is the same problem. I have to run but will continue to work on this on Monday. Any ideas on what could cause it? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBc1ucACgkQrlYvE4MpobOgZQCgtOIVhfSwF6hcMuogizP+KR34 4sEAn1CGXefCBWCWr2zLUrggzuHfKrxX =CxxD -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Latest SELinux Access Patch.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This patch adds the ability to look at the calling process that is trying to
do dbus calls into systemd, then it checks with the SELinux policy to see if
the calling process is allowed to do the activity.
The basic idea is we want to allow NetworkManager_t to be able to start and
stop ntpd.service, but not necessarly mysqld.service.
Similarly we want to allow a root admin webadm_t that can only manage the
apache environment. systemctl enable httpd.service, systemctl disable
iptables.service bad.
To make this code cleaner, we really need to refactor the dbus-manager.c code.
This has just become a huge if-then-else blob, which makes doing the correct
check difficult.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBJBi8ACgkQrlYvE4MpobOzTwCdEUikbvRWUCwOb83KlVF0Nuy5
lRAAnjZZNuc19Z+aNxm3k3nwD4p/JYco
=yops
-END PGP SIGNATURE-
diff --git a/Makefile.am b/Makefile.am
index ae775c8..654bf67 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -944,6 +944,8 @@ libsystemd_core_la_SOURCES = \
src/core/dbus-path.h \
src/core/cgroup.c \
src/core/cgroup.h \
+ src/core/selinux-access.c \
+ src/core/selinux-access.h \
src/core/selinux-setup.c \
src/core/selinux-setup.h \
src/core/ima-setup.c \
diff --git a/src/core/bus-errors.h b/src/core/bus-errors.h
index 04c1b28..dca7824 100644
--- a/src/core/bus-errors.h
+++ b/src/core/bus-errors.h
@@ -43,6 +43,7 @@
#define BUS_ERROR_TRANSACTION_ORDER_IS_CYCLIC org.freedesktop.systemd1.TransactionOrderIsCyclic
#define BUS_ERROR_SHUTTING_DOWN org.freedesktop.systemd1.ShuttingDown
#define BUS_ERROR_NO_SUCH_PROCESS org.freedesktop.systemd1.NoSuchProcess
+#define BUS_ERROR_ACCESS_DENIED org.freedesktop.systemd1.AccessDenied
static inline const char *bus_error(const DBusError *e, int r) {
if (e e-message)
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index c341d36..9df02e6 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -30,6 +30,7 @@
#include build.h
#include dbus-common.h
#include install.h
+#include selinux-access.h
#include watchdog.h
#include hwclock.h
#include path-util.h
@@ -564,6 +565,9 @@ static DBusHandlerResult bus_manager_message_handler(DBusConnection *connection,
dbus_error_init(error);
member = dbus_message_get_member(message);
+r = selinux_manager_access_check(connection, message, m, error);
+if (r)
+return bus_send_error_reply(connection, message, error, r);
if (dbus_message_is_method_call(message, org.freedesktop.systemd1.Manager, GetUnit)) {
const char *name;
diff --git a/src/core/dbus-unit.c b/src/core/dbus-unit.c
index ad817d7..3008ea8 100644
--- a/src/core/dbus-unit.c
+++ b/src/core/dbus-unit.c
@@ -26,6 +26,7 @@
#include dbus-unit.h
#include bus-errors.h
#include dbus-common.h
+#include selinux-access.h
const char bus_unit_interface[] _introspect_(Unit) = BUS_UNIT_INTERFACE;
@@ -411,9 +412,19 @@ static DBusHandlerResult bus_unit_message_dispatch(Unit *u, DBusConnection *conn
JobType job_type = _JOB_TYPE_INVALID;
char *path = NULL;
bool reload_if_possible = false;
+int r;
dbus_error_init(error);
+r = selinux_unit_access_check(
+connection,
+message,
+m,
+(u-fragment_path ? u-fragment_path: u-source_path),
+error);
+if (r)
+return bus_send_error_reply(connection, message, error, r);
+
if (dbus_message_is_method_call(message, org.freedesktop.systemd1.Unit, Start))
job_type = JOB_START;
else if (dbus_message_is_method_call(message, org.freedesktop.systemd1.Unit, Stop))
@@ -434,7 +445,6 @@ static DBusHandlerResult bus_unit_message_dispatch(Unit *u, DBusConnection *conn
const char *swho;
int32_t signo;
KillWho who;
-int r;
if (!dbus_message_get_args(
message,
@@ -479,7 +489,6 @@ static DBusHandlerResult bus_unit_message_dispatch(Unit *u, DBusConnection *conn
const char *smode;
JobMode mode;
Job *j;
-int r;
if ((job_type == JOB_START u-refuse_manual_start) ||
(job_type == JOB_STOP u-refuse_manual_stop) ||
diff --git a/src/core/selinux-access.c b/src/core/selinux-access.c
new file mode 100644
index 000..30eab68
--- /dev/null
+++ b/src/core/selinux-access.c
@@ -0,0 +1,710 @@
+
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+ This file is part of systemd.
+
+ Copyright 2012 Dan Walsh
+
+ systemd is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by
+ the
Re: [systemd-devel] Not sure if I am doing something wrong or if this is a bug.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/2012 03:45 PM, Lennart Poettering wrote: On Mon, 30.07.12 17:13, Daniel J Walsh (dwa...@redhat.com) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In containers we are blocking systemd from creating containers. If I try to run httpd within a container it asks for PrivateTmp and SELinux stops systemd from setting up the PrivateTmp. In order to get around this, I decided to try to create a unit file based off of the httpd unit file. cat /etc/systemd/system/sandbox.target.wants/httpd.service Files in .wants/ directory should be symlinks (since they just are used to express deps, not the actual services). Hence you want to place this service file in /etc/systemd/system/httpd.service and then make /etc/systemd/system/sandbox.target.wants/httpd.service a symlink to it. And then use systemctl daemon-reload to actviate these changes. And use systemctl show httpd.service to check whether your changes were properly applied. Lennart Yes I figured this all out last week. It now seems to work pretty well. Hopefull new versions of libvirt and libvirt-sandbox get pushed into Rawhide this week, so we can get people playing with this. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAfzEsACgkQrlYvE4MpobN8UgCfX6PYDgalQvTas57pIMk9l/Jl 7sgAnApiyv/NzY1m8N/PaNjUaYl8XAMz =x1Tu -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Not sure if I am doing something wrong or if this is a bug.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2012 10:08 PM, Mathieu Bridon wrote: On Mon, 2012-07-30 at 21:49 +, Jóhann B. Guðmundsson wrote: On 07/30/2012 09:13 PM, Daniel J Walsh wrote: Is this failing to see the /etc/systemd/system/httpd.service file? Or is the include failing? Include might failing since there is currently no way to replace existing entry with another one. You can easily confirm or deny if that's the case by simply copy the existing unit and set PrivateTmp to false You can also run systemctl show httpd.service It should show you both the full path to the unit file (so you can make sure that the one in /etc is used) as well as the value of PrivateTmp. I'm sure you did, but just to be extra cautious: did you daemon-reload after adding the file in /etc? Ok I think it is working. Thanks for the hints on commands, I did not know show would tell you the config. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAZlTsACgkQrlYvE4MpobOpXACcDpGnuANaXhRjvvGxok/51RwB CUUAoMYO/cN8i51uYY8+N75EOB0A1yGY =ZFTE -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Not sure if I am doing something wrong or if this is a bug.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In containers we are blocking systemd from creating containers. If I try to run httpd within a container it asks for PrivateTmp and SELinux stops systemd from setting up the PrivateTmp. In order to get around this, I decided to try to create a unit file based off of the httpd unit file. cat /etc/systemd/system/sandbox.target.wants/httpd.service .include /usr/lib/systemd/system/httpd.service [Service] PrivateTmp=false But running this within a container still blows up # systemctl start httpd.service Job failed. See system journal and 'systemctl status' for details. sh-4.2# systemctl status httpd.service httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled) Active: failed (Result: exit-code) since Mon, 30 Jul 2012 17:12:37 -0400; 15s ago Process: 152 ExecStop=/usr/sbin/httpd $OPTIONS -k graceful-stop (code=exited, status=226/NAMESPACE) Process: 153 ExecStart=/usr/sbin/httpd $OPTIONS (code=exited, status=226/NAMESPACE) Main PID: 131 (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/libvirtd.service/system/httpd.service Jul 30 17:12:37 apache2 httpd[153]: Failed at step NAMESPACE spawning /usr/...ed sh-4.2# Is this failing to see the /etc/systemd/system/httpd.service file? Or is the include failing? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAW+RQACgkQrlYvE4MpobNqHwCgkj7qJJFn6t1G2cDworfpfWjq 4REAoJZ6kZeqCTu2QBZ5nj2//oAVqqdI =du44 -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Looking for comments on this patch.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The goal of this patch is to add the ability for systemd to verify that
SELinux policy allows the calling process to do the specified action.
Start/Stop/Service
This is expanded upon in this Feature Page Article.
https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl
I am having a hard time testing this, and any suggestions welcomed.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAO+00ACgkQrlYvE4MpobPrvQCgsb0XurnGVF31LzO3cvYDYMpl
7+MAoKgFCOOFJAvuMHq19tAg7eE2/Q9n
=c5/D
-END PGP SIGNATURE-
diff --git a/Makefile.am b/Makefile.am
index 27666ea..3d44ab0 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -943,6 +943,8 @@ libsystemd_core_la_SOURCES = \
src/core/dbus-path.h \
src/core/cgroup.c \
src/core/cgroup.h \
+ src/core/selinux-access.c \
+ src/core/selinux-access.h \
src/core/selinux-setup.c \
src/core/selinux-setup.h \
src/core/ima-setup.c \
diff --git a/src/core/bus-errors.h b/src/core/bus-errors.h
index 04c1b28..dca7824 100644
--- a/src/core/bus-errors.h
+++ b/src/core/bus-errors.h
@@ -43,6 +43,7 @@
#define BUS_ERROR_TRANSACTION_ORDER_IS_CYCLIC org.freedesktop.systemd1.TransactionOrderIsCyclic
#define BUS_ERROR_SHUTTING_DOWN org.freedesktop.systemd1.ShuttingDown
#define BUS_ERROR_NO_SUCH_PROCESS org.freedesktop.systemd1.NoSuchProcess
+#define BUS_ERROR_ACCESS_DENIED org.freedesktop.systemd1.AccessDenied
static inline const char *bus_error(const DBusError *e, int r) {
if (e e-message)
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index c341d36..3f6f4af 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -30,6 +30,7 @@
#include build.h
#include dbus-common.h
#include install.h
+#include selinux-access.h
#include watchdog.h
#include hwclock.h
#include path-util.h
@@ -556,6 +557,8 @@ static DBusHandlerResult bus_manager_message_handler(DBusConnection *connection,
JobType job_type = _JOB_TYPE_INVALID;
bool reload_if_possible = false;
const char *member;
+const char *perm;
+int require_unit;
assert(connection);
assert(message);
@@ -565,6 +568,35 @@ static DBusHandlerResult bus_manager_message_handler(DBusConnection *connection,
member = dbus_message_get_member(message);
+selinux_perm_lookup(message, perm, require_unit);
+if (require_unit) {
+const char *name;
+Unit *u;
+
+if (!dbus_message_get_args(
+message,
+error,
+DBUS_TYPE_STRING, name,
+DBUS_TYPE_INVALID))
+return bus_send_error_reply(connection, message, error, -EINVAL);
+
+if (!(u = manager_get_unit(m, name))) {
+dbus_set_error(error, BUS_ERROR_NO_SUCH_UNIT, Unit %s is not loaded., name);
+return bus_send_error_reply(connection, message, error, -ENOENT);
+}
+
+if (u-fragment_path) {
+r = selinux_access_check(connection, message, m, error, perm, u-fragment_path);
+} else {
+r = selinux_access_check(connection, message, m, error, perm, u-source_path);
+}
+if (r != 0)
+return bus_send_error_reply(connection, message, error, r);
+} else {
+r = selinux_access_check(connection, message, m, error, perm, NULL);
+if (r != 0)
+return bus_send_error_reply(connection, message, error, r);
+}
if (dbus_message_is_method_call(message, org.freedesktop.systemd1.Manager, GetUnit)) {
const char *name;
Unit *u;
diff --git a/src/core/dbus-unit.c b/src/core/dbus-unit.c
index 2d2f378..d592211 100644
--- a/src/core/dbus-unit.c
+++ b/src/core/dbus-unit.c
@@ -26,6 +26,7 @@
#include dbus-unit.h
#include bus-errors.h
#include dbus-common.h
+#include selinux-access.h
const char bus_unit_interface[] _introspect_(Unit) = BUS_UNIT_INTERFACE;
@@ -411,9 +412,21 @@ static DBusHandlerResult bus_unit_message_dispatch(Unit *u, DBusConnection *conn
JobType job_type = _JOB_TYPE_INVALID;
char *path = NULL;
bool reload_if_possible = false;
+int r;
+const char *perm;
+int require_unit;
dbus_error_init(error);
+selinux_perm_lookup(message, perm, require_unit);
+if (u-fragment_path) {
+r = selinux_access_check(connection, message, m, error, perm, u-fragment_path);
+} else {
+r = selinux_access_check(connection, message, m, error, perm, u-source_path);
+}
+if (r != 0)
+return
Re: [systemd-devel] Hosting a sprint in SF?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/09/2012 06:24 PM, Lennart Poettering wrote: On Fri, 29.06.12 09:34, David Strauss (da...@davidstrauss.net) wrote: On Fri, Jun 29, 2012 at 5:58 AM, Lennart Poettering lenn...@poettering.net wrote: It's going to be an LXC/libvirt/systemd/SELinux hackfest, in order to make systemd integrated formidably with containers and security subsystems, so that we end up with secure containers for Linux that match more closely what Solaris Zones can offer. One of the topics we're likely to discuss is journal integration for this, so that the journals of the containers seemlessly browsable on the host system. It's going to be the day before LPC, in San Diego, 28th Aug. The LXC/libvirt part is pretty interesting, and I'd like to learn more about selinux. Is there any interest from OpenShift in participating? They have a similar container to Pantheon and have their stuff in the Fedora 18 roadmap. I honestly can't answer that question, since I don#t know. We haven't made a lot of advertisements about this hackfest yet. I guess i should do that. Lennart We have been talking to the openshift guys on the side and have explained what we are doing. They are interested and will probably be some of the first people to play with it, once it is ready. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/8JG0ACgkQrlYvE4MpobM7yQCeL/p/e6e3tnRZS27nxERIZdTq MpsAoIsAl9aSIBT/T/PoIY3TLm3VjtHy =d1Lu -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Hosting a sprint in SF?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/10/2012 02:33 PM, David Strauss wrote: On Tue, Jul 10, 2012 at 5:47 AM, Daniel J Walsh dwa...@redhat.com wrote: We have been talking to the openshift guys on the side and have explained what we are doing. They are interested and will probably be some of the first people to play with it, once it is ready. Would any of them be interested in participating in the September sprint? Like OpenShift, Pantheon (my company) is focused on using this technology for high-density platform services that host user applications. I understand that Red Hat's policies are pretty strict regarding sprint travel, so I'm happy to cover some of the costs there for valuable participants. OpenShift developers would certainly qualify. You would need to contact them. Although I am sure some will be attending. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/80QcACgkQrlYvE4MpobPp3QCgibnFQjOeTIZEPW4b+AyvV+VP r6MAnRCJ1w+yAmpIiSCD4YgmDyoYZNmN =qMCd -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fix systemd-udev labeling of /var/run directory.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/30/2012 08:27 PM, Lennart Poettering wrote:
On Wed, 30.05.12 23:32, Lennart Poettering (lenn...@poettering.net) wrote:
On Wed, 30.05.12 16:13, Daniel J Walsh (dwa...@redhat.com) wrote:
+const char *prefixes[] = { /dev, /var/run, NULL };
Is there a reason this mentions /var/run and not /run?
Otherwise looks good to me!
I have now commited the patch but took the liberty to change /var/run to
/run here.
Lennart
Yes it has to be /var/run. The policy is all written with the upstream
/var/run patterns not /run.
# matchpathcon -p /run /run/udev
/run/udev system_u:object_r:default_t:s0
# matchpathcon -p /var/run /run/udev
/run/udev system_u:object_r:udev_var_run_t:s0
We have equivalence match between /run - /var/run
But the library for loading initial context does not take this into account.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/HTecACgkQrlYvE4MpobOdIACfWWj1t8wczo9k2iBgill6J8vz
JHUAni/pvi3LsI/d/KXrfb+tJUa0itzH
=Ko7F
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fix systemd-udev labeling of /var/run directory.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/31/2012 07:01 AM, Lennart Poettering wrote:
On Thu, 31.05.12 06:54, Daniel J Walsh (dwa...@redhat.com) wrote:
Heya,
On Wed, 30.05.12 16:13, Daniel J Walsh (dwa...@redhat.com) wrote:
+const char *prefixes[] = { /dev, /var/run, NULL };
Is there a reason this mentions /var/run and not /run?
Otherwise looks good to me!
I have now commited the patch but took the liberty to change /var/run
to /run here.
Lennart
Yes it has to be /var/run. The policy is all written with the upstream
/var/run patterns not /run.
# matchpathcon -p /run /run/udev /run/udev
system_u:object_r:default_t:s0
# matchpathcon -p /var/run /run/udev /run/udev
system_u:object_r:udev_var_run_t:s0
We have equivalence match between /run - /var/run
But the library for loading initial context does not take this into
account.
Humm, but it seems wrong encoding in the C code that the policy hasn't been
updated for the /var/run move yet... [1]
Note that starting with F17 /var/run is unconditionally a symlink now, and
no longer a bind mount. This means /run is always the right name for this,
on any level. Isn't it time to update the policy to reflect this?
Hmm, people have noticed that the systemd 184 (with your patch applied)
doesn't build on non-Fedora anymore because your patch appears to use a
Fedora-only API addition. Will this go upstream any time soon? I feel quite
uncomfortable leaving this in the state in systemd, effectively breaking
everybody's but Fedora's build with this?
Thanks,
Lennart
Footnotes:
[1] The least we should probably do is include both /var/run and /run in
the list...
Ok Eric and I will work to get it upstream. I guess for F18 I can move the
/var/run definition to /run and reverse the equivalence. But it is probably
best to put /var/run and /run in the list.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/HUEUACgkQrlYvE4MpobPTtgCghCBEH6gpzKUrCEqKHTuSBK68
he0An3l5+X0Csz0kCCUAhSttdCvtMD+p
=/uW0
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fix systemd-udev labeling of /var/run directory.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2012 07:51 AM, Kay Sievers wrote: On Thu, May 31, 2012 at 1:04 PM, Daniel J Walsh dwa...@redhat.com wrote: Ok Eric and I will work to get it upstream. I guess for F18 I can move the /var/run definition to /run and reverse the equivalence. But it is probably We have changed udev not do any selinux label magic for /run files/directories now, but only for /dev. I have reverted the patch for the (unreleased API) /dev, /run prefixes list for now. Hopefully we will not need anything like that with the current udev code. Thanks, Kay Ok if the only content udev creates is in /run/udev and /run/udev is created with udev_var_run_t, we should be fine. Should be faster also. (Although maybe not measurable.) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/HaIsACgkQrlYvE4MpobPDewCfVmZ2cdvcwbed/H+zPPM8qv7v HTMAoLn1EJ6bcQq19hzgCuFLKeSz6pWl =25VT -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fix systemd-udev labeling of /var/run directory.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
systemd-udev is currently incorrectly labeling /run/udev/* content because it is
using selinux prefix labeling of /dev. This patch will allow systemd-udev to
use prefix labeling of /dev and /run.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/Gf3wACgkQrlYvE4MpobM52wCeNU8iT1e4qIZnGzeDXUoHjG75
EkEAoN9HFxZv+J8HKkhpbRhWNtM8gHnO
=MulB
-END PGP SIGNATURE-
From 779a7148a40f56529821d37ac348abec3b565459 Mon Sep 17 00:00:00 2001
From: Dan Walsh dwa...@redhat.com
Date: Wed, 30 May 2012 15:34:55 -0400
Subject: [PATCH 5/6] Switch to using prefix array rather then single prefix.
This will allow proper labeling of /dev and /var/run
(/run) directory from systemd-udev
---
src/shared/label.c |6 +++---
src/shared/label.h |2 +-
src/udev/udevadm.c |4 +++-
src/udev/udevd.c |3 ++-
4 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/src/shared/label.c b/src/shared/label.c
index 2d7d42a..39c6f03 100644
--- a/src/shared/label.c
+++ b/src/shared/label.c
@@ -52,7 +52,7 @@ void label_retest_selinux(void) {
#endif
-int label_init(const char *prefix) {
+int label_init(const char *prefixes[]) {
int r = 0;
#ifdef HAVE_SELINUX
@@ -68,9 +68,9 @@ int label_init(const char *prefix) {
before_mallinfo = mallinfo();
before_timestamp = now(CLOCK_MONOTONIC);
-if (prefix) {
+if (prefixes) {
struct selinux_opt options[] = {
-{ .type = SELABEL_OPT_SUBSET, .value = prefix },
+{ .type = SELABEL_OPT_SUBSET, .values = prefixes },
};
label_hnd = selabel_open(SELABEL_CTX_FILE, options, ELEMENTSOF(options));
diff --git a/src/shared/label.h b/src/shared/label.h
index 3f880e3..90b49ff 100644
--- a/src/shared/label.h
+++ b/src/shared/label.h
@@ -26,7 +26,7 @@
#include stdbool.h
#include sys/socket.h
-int label_init(const char *prefix);
+int label_init(const char *prefixes[]);
void label_finish(void);
int label_fix(const char *path, bool ignore_enoent);
diff --git a/src/udev/udevadm.c b/src/udev/udevadm.c
index 5217d7f..c7d13f3 100644
--- a/src/udev/udevadm.c
+++ b/src/udev/udevadm.c
@@ -91,6 +91,7 @@ int main(int argc, char *argv[])
{ version, no_argument, NULL, 'V' },
{}
};
+const char *prefixes[] = { /dev, /var/run, NULL };
const char *command;
unsigned int i;
int rc = 1;
@@ -102,7 +103,8 @@ int main(int argc, char *argv[])
log_open();
log_parse_environment();
udev_set_log_fn(udev, udev_main_log);
-label_init(/dev);
+
+label_init(prefixes);
for (;;) {
int option;
diff --git a/src/udev/udevd.c b/src/udev/udevd.c
index 0d85960..85d4f66 100644
--- a/src/udev/udevd.c
+++ b/src/udev/udevd.c
@@ -1030,6 +1030,7 @@ int main(int argc, char *argv[])
int fd_ctrl = -1;
int fd_netlink = -1;
int fd_worker = -1;
+const char *prefixes[] = { /dev, /var/run, NULL };
struct epoll_event ep_ctrl, ep_inotify, ep_signal, ep_netlink, ep_worker;
struct udev_ctrl_connection *ctrl_conn = NULL;
int rc = 1;
@@ -1042,7 +1043,7 @@ int main(int argc, char *argv[])
log_parse_environment();
udev_set_log_fn(udev, udev_main_log);
log_debug(version %s\n, VERSION);
-label_init(/dev);
+label_init(prefixes);
for (;;) {
int option;
--
1.7.10.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] systemd Optimizations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/13/2012 04:44 PM, Lennart Poettering wrote: Heya, I just put together a first version of a wiki text explaining a couple fo ways to improve system boot-up performance even further: http://freedesktop.org/wiki/Software/systemd/Optimizations I hope this is useful both to folks working on distributions and those working on appliances to get the most out of systemd. It lists both suggestions that are easily made locally, and changes that need hacking but we'd like to go systemd upstream eventually. We'll try to keep this up to date. If you do systemd optimization work, this should be the first place to go to! If you have further suggestions for additions to this page please ping us! Lennart We have added some ability to optimize the loading of file regex in libselinux in the F17 libraries. We might want to look at using this to shrink the 100ms SELinux startup time penalty. You could use a prefix for /dev, /var/run and /run, /tmp and eliminate building the regex for all file context under /usr, /var/ /etc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+xBZgACgkQrlYvE4MpobOkWACfYjM7lW8s+16ecEmHycijYspx 3ioAn30v3qzHR37TB6pLRLd/s6D99R3A =0Iw0 -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v44
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/19/2012 10:12 AM, Kay Sievers wrote: On Mon, Mar 19, 2012 at 15:03, Thierry Reding thierry.red...@avionic-design.de wrote: * Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/19/2012 07:59 AM, Thierry Reding wrote: * Kay Sievers wrote: On Sat, Mar 17, 2012 at 15:14, Koen Kooi k...@dominion.thruhere.net wrote: Op 16 mrt. 2012, om 02:40 heeft Lennart Poettering het volgende geschreven: Heya, this is primarily a bugfix release (but does include a couple of new things) and might be very likely the version we'll ship in Fedora 17, unless there's some unforeseen bigger bug left to be fixed. http://cgit.freedesktop.org/systemd/systemd/plain/NEWS http://www.freedesktop.org/software/systemd/systemd-44.tar.xz I get the following error and warnings when crosscompiling for arm: | src/journal/journald.c: In function 'process_event': | src/journal/journald.c:2147:49: error: 'PAGE_SIZE' undeclared (first use in this function) PATH_MAX might be simpler to use here. Exactly how long are SELinux labels allowed to be? I couldn't find any related constants in any of the headers on my system. Alternatively, maybe a more portable way would be to use sysconf(_SC_PAGESIZE) here? Right now they are unlimited, but we are having discussions with upstream about potentially picking a limit of around 2k. What is the time frame for this? I have been able to generate a worse case label of just over 5k, in userspace, but this would be limited to around 2k if coming from the kernel. In NON-MlS world, SELinux labels would never be longer then 100 chars. In the meantime maybe some constant known to be an absolute maximum should be chosen. I don't know if the typical page-size of 4K would be enough given that you've been able to generate one that is larger. 8K on the other hand seems way too much. It used to be NAME_MAX 255 in the past, in earlier days of selinux/audit userspace, I think. I think this is a perfectly acceptable number and will satisfy most cases. Only in the wacky world of MLS where you could have a huge number of categories is the not enough, and the MLS world would rely on the audit.log anyways for this type of information. Until SELinux picks a number I would go with a NAME_MAX of 255. If longer names should be supported, PATH_MAX 4096 sounds good to me. If it should be crazy large, XATTR_SIZE_MAX 65536 seems to define the upper limit anyway. :) Kay -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9nQesACgkQrlYvE4MpobPySwCgoMN6j4QTPdHjafQyZnURXaua 3ukAn3HC+Zz0JFD7VXpoYz/QavBYKo1u =0Ga8 -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] dracut: ordering of modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/13/2012 05:29 AM, Harald Hoyer wrote: Am 13.02.2012 11:17, schrieb Roberto Sassu: Hi Harald this functionality seems to be broken in dracut due to a change in the SELinux load_policy tool. After enabling the selinux module in dracut, i obtain: [3.369059] dracut: Loading SELinux policy [3.449850] dracut: /sbin/load_policy: Can't load policy: No such file or directory [3.659899] dracut: Switching root This error can have multiple causes... Dan? Well likeliest would be selinux-policy package is not installed. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk85QaIACgkQrlYvE4MpobMNbwCgi8JG0fmlQsnvo2HNnA+Orxzr UYcAoKqHj0+Ll8lfbYpvGzANxck4MAwP =geIr -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] We are working on Secure Container Applications.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The idea is to run multiple instances of the same application within a container. For example multiple Apache servers. I am working on a tool to create these containers, which will create a service unit file. # virt-sandbox-service create -e /usr/sbin/httpd httpd_sanbox Created container dir /var/lib/libvirt/filesystems/httpd_sanbox Created sandbox config /etc/libvirt-sandbox/httpd_sanbox.sandbox Created unit file /etc/systemd/system/httpd_sanbox.service One problem we see with this is when the httpd program gets updated, it runs a systemctl reload httpd.service, to cause the httpd service to restart. We would like to get this reload command from systemd also. What do you guys think of adding something like the following to the service unit? ReloadRequest: httpd.service Then anyone asking to reload the httpd.service would also cause the httpd_sandbox.service to get the reload. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8LX2IACgkQrlYvE4MpobMoMQCgmwQoZvm68QzFw8iEwdOVD5/p g3sAoNUB9Hb2YnD5M1Egj6zxj+1f31TL =C4jm -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] selinux policy updates for logind
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2012 11:02 AM, Bill Nottingham wrote: Matthias Clasen (matthias.cla...@gmail.com) said: On Wed, Dec 28, 2011 at 9:25 AM, Daniel J Walsh dwa...@redhat.com wrote: Well are you seeing a AVC about local_login_t sending a dbus message to systemd? I don't know, I haven't checked. But the patch fixes the problem, and is pretty obvious... Is this just another case of https://bugzilla.redhat.com/show_bug.cgi?id=759202 ? Bill Could be, Matthias, are you still seeing this with the latest selinux-policy? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8DMyYACgkQrlYvE4MpobMUGACeOh4tUdp8DpvD1J+TSgBf5Ff1 Ot8AoNqEnwbGCcSdHaQOD6DYvlo2W+3g =xeDz -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] selinux policy updates for logind
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/23/2011 09:16 PM, Matthias Clasen wrote: I've spent some time playing with the ConsoleKit-replacement functionality in logind, and noticed that I couldn't test the PolicyKit integration for the poweroff/reboot methods in logind, since selinux doesn't let my method calls reach their destination. Matthias What AVCs are you seeing? diff -up systemd-37/src/org.freedesktop.login1.conf.selinux systemd-37/src/org.freedesktop.login1.conf --- systemd-37/src/org.freedesktop.login1.conf.selinux▸‧2011-12-23 21:09:32.795513513 -0500 +++ systemd-37/src/org.freedesktop.login1.conf▸‧2011-12-23 21:10:36.456511229 -0500 @@ -69,6 +69,14 @@ send_member=ActivateSession/ allow send_destination=org.freedesktop.login1 + send_interface=org.freedesktop.login1.Manager + send_member=PowerOff/ + +allow send_destination=org.freedesktop.login1 + send_interface=org.freedesktop.login1.Manager + send_member=Reboot/ + +allow send_destination=org.freedesktop.login1 send_interface=org.freedesktop.login1.Seat send_member=ActivateSession/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk77IBIACgkQrlYvE4MpobNhBQCdFZ0lgAOJQz0M/ApwmqWb0RSA Dj8An3y/Dja/rT1PmlqDcl8awiCUMuoA =C5hs -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] SELinux needs labels to be assigned at boot time to /sys
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The only way to do this is by running restorecon over the contents.
We would like to add /sys to the list of directories that systemd
fixes at boot time, just like /dev
https://bugzilla.redhat.com/show_bug.cgi?id=767355
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7nwMoACgkQrlYvE4MpobPXhgCgrFOrRkr/wlgzRE5wKcVg9bvk
FfgAoJI291nd2Oqo1eDBuyAJyT2fgTKU
=LiKB
-END PGP SIGNATURE-
diff -up systemd-37/src/mount-setup.c~ systemd-37/src/mount-setup.c
--- systemd-37/src/mount-setup.c~ 2011-08-30 13:21:41.804076227 -0400
+++ systemd-37/src/mount-setup.c2011-12-13 16:10:22.343870192 -0500
@@ -395,6 +395,7 @@ int mount_setup(bool loaded_policy) {
nftw(/dev, nftw_cb, 64, FTW_MOUNT|FTW_PHYS|FTW_ACTIONRETVAL);
nftw(/run, nftw_cb, 64, FTW_MOUNT|FTW_PHYS|FTW_ACTIONRETVAL);
+nftw(/sys, nftw_cb, 64, FTW_MOUNT|FTW_PHYS|FTW_ACTIONRETVAL);
/* Explicitly relabel these */
NULSTR_FOREACH(j, relabel)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] New pam module to start a session.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/14/2011 04:34 AM, Stef Bon wrote: Hi, I've rewritten an existing pam module pam_script. What it does: . runs a script . unshare the mount namespace (if configured, default yes) if the directory to chroot to is specfied it does also: . mount all the required directories like bin, lib, usr etcetera. . chroot to this directory See: git clone git://gitorious.org/pam_script/pam_script.git pam_script cd pam_script Please some comments. Especially the starting of a session, is this enough? If you look to the code you'll see that I've copied from nspawn.c the check is_os_tree and mount_all functions, and adjusted them a bit(is this ok?) In nspawn a lot more is done but I'm not that familiar with these low level operations. So please comment on this. Stef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Did you look at extending pam_namespace? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6YL2IACgkQrlYvE4MpobPL9gCeJ4/aKVMKiGoAjD+K5cD7paZR xocAoJfTC3bYV/0Irzkp34eIwqClDCc4 =yZh7 -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nspawn remounts /selinux readonly, thus breaking logins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/2011 08:18 AM, Zbigniew Jędrzejewski-Szmek wrote: On 07/08/2011 01:59 PM, Daniel J Walsh wrote: On 07/08/2011 07:45 AM, Lennart Poettering wrote: On Fri, 08.07.11 10:41, Zbigniew Jdrzejewski-Szmek (zbys...@in.waw.pl) wrote: On 07/07/2011 11:17 PM, Lennart Poettering wrote: On Thu, 07.07.11 16:52, Daniel J Walsh (dwa...@redhat.com) wrote: This has a nasty consequence of breaking logins: Jul 7 22:17:05 fedora-15 sshd[14261]: Accepted publickey for zbyszek from 192.168.122.1 port 51205 ssh2 Jul 7 20:17:05 fedora-15 sshd[14262]: fatal: mm_request_receive: read: Connection reset by peer Jul 7 22:17:05 fedora-15 sshd[14261]: pam_selinux(sshd:session): conversation failed Jul 7 22:17:05 fedora-15 sshd[14261]: pam_selinux(sshd:session): No response to query: Would you like to enter a security context? [N] Jul 7 22:17:05 fedora-15 sshd[14261]: pam_selinux(sshd:session): Unable to get valid context for zbyszek Jul 7 22:17:05 fedora-15 sshd[14261]: pam_unix(sshd:session): session opened for user zbyszek by (uid=0) Jul 7 22:17:05 fedora-15 sshd[14261]: error: PAM: pam_open_session(): Authentication failure Jul 7 22:17:05 fedora-15 sshd[14264]: Received disconnect from 192.168.122.1: 11: disconnected by user In case of a login on a tty, the question about a security context is displayed on the screen. In case of ssh login, if just fails without any message displayed on the remote side. Newer versions of libselinux detect if /selinux is read-only and consider selinux disabled if it is. But why is it disabled _outside_ of the container? This would mean that running nspawn disables selinux. Hmm? No, it's read-only only inside the container. We do that to make sure the container cannot modify the selinux policy, since policies cannot be virtualized really. Nope, it becomes read-only outside. Some bug? Repeating the commands from the original mail: [zbyszek@fedora-15 ~]$ mount|grep selinux selinuxfs on /selinux type selinuxfs (rw,relatime) - RW here [zbyszek@fedora-15 ~]$ sudo systemd-nspawn -D debian-tree/ /bin/true Spawning namespace container on /home/zbyszek/debian-tree (console is /dev/pts/2). [zbyszek@fedora-15 ~]$ mount|grep selinux selinuxfs on /selinux type selinuxfs (ro,relatime) - RO now I have no idea what nspawn does, but if you are turning the /selinux to readonly to prevent a root process from mucking with SELinux you are not going to be successful. Since you can mount selinufs somewhere else and muck around with it. As I understand, absolute security is not on of the goals of nspawn. It is only intended to prevent accidental breakage. If you want to run all of the processes within the nspawn environment under a single label, Like we do with Mock, then changing /selinux to read/only with the libselinux in Rawhide will give you want you want. IE All processes within the container think SELinux is disabled, while SELinux is actually running all of the processes under confinement. Zbyszek Lennart, I think to make this work correctly you need to bind mount /selinux on /selinux, then make the mount point private, then finally mount selinuxfs on /selinux read/only. Otherwise since / is shared, the mounting within the namespace will show up on all namespaces. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4W9loACgkQrlYvE4MpobNREgCgnXFPQDL6rJCPxm1jSRNJor5G ykQAni8GagyFkLjIwzI8DCOxckSR70Nh =6I8m -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nspawn remounts /selinux readonly, thus breaking logins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/2011 04:45 PM, Lennart Poettering wrote: On Thu, 07.07.11 22:42, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Hi, on freshly installed fedora-15 system, I've been trying out the nspawn, and running systemd-nspawn -D debian-tree/ (i.e. just the shell) seems to cause /selinux to be remount ro on the _host_: $ rpm -q systemd systemd-26-5.fc15.x86_64 $ mount|grep selinux selinuxfs on /selinux type selinuxfs (rw,relatime) $ sudo systemd-nspawn -D debian-tree/ /bin/true $ mount|grep selinux selinuxfs on /selinux type selinuxfs (ro,relatime) This has a nasty consequence of breaking logins: Jul 7 22:17:05 fedora-15 sshd[14261]: Accepted publickey for zbyszek from 192.168.122.1 port 51205 ssh2 Jul 7 20:17:05 fedora-15 sshd[14262]: fatal: mm_request_receive: read: Connection reset by peer Jul 7 22:17:05 fedora-15 sshd[14261]: pam_selinux(sshd:session): conversation failed Jul 7 22:17:05 fedora-15 sshd[14261]: pam_selinux(sshd:session): No response to query: Would you like to enter a security context? [N] Jul 7 22:17:05 fedora-15 sshd[14261]: pam_selinux(sshd:session): Unable to get valid context for zbyszek Jul 7 22:17:05 fedora-15 sshd[14261]: pam_unix(sshd:session): session opened for user zbyszek by (uid=0) Jul 7 22:17:05 fedora-15 sshd[14261]: error: PAM: pam_open_session(): Authentication failure Jul 7 22:17:05 fedora-15 sshd[14264]: Received disconnect from 192.168.122.1: 11: disconnected by user In case of a login on a tty, the question about a security context is displayed on the screen. In case of ssh login, if just fails without any message displayed on the remote side. Newer versions of libselinux detect if /selinux read-only and consider selinux as disabled if is. Lennart Do I need to back port this to F15? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4WHIsACgkQrlYvE4MpobNoGwCg21plu5JCs5wIv5fArvYDmOia 8+4An3FYGs3gsG21yNwkDAThrrV1kOYC =LoD+ -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] readahead-collect.c: ignore EACCES for fanotify
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/25/2011 07:15 AM, Harald Hoyer wrote:
With this patch and:
# cat myreadahead.te
module myreadahead 1.0;
require {
type readahead_t;
type kmsg_device_t;
class chr_file write;
}
#= readahead_t ==
allow readahead_t kmsg_device_t:chr_file write;
# checkmodule -M -m -o myreadahead.mod myreadahead.te
# semodule_package -o myreadahead.pp -m myreadahead.mod
# semodule -i myreadahead.pp
systemd-readahead-collect finally works with selinux enabled on my
Fedora 15 machine.
Am 25.05.2011 13:09, schrieb har...@redhat.com:
From: Harald Hoyerhar...@redhat.com
At the start of auditd, we are temporarily not able to read
from the fanotify fd. Ignoring it, seems to work.
---
src/readahead-collect.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/readahead-collect.c b/src/readahead-collect.c
index 3c48a02..913a340 100644
--- a/src/readahead-collect.c
+++ b/src/readahead-collect.c
@@ -380,7 +380,7 @@ static int collect(const char *root) {
if ((n = read(fanotify_fd,data, sizeof(data))) 0) {
-if (errno == EINTR || errno == EAGAIN)
+if (errno == EINTR || errno == EAGAIN ||
errno == EACCES)
continue;
log_error(Failed to read event: %m);
Fix will be in selinux-policy-3.9.16-25.fc15
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk3c+TkACgkQrlYvE4MpobMywQCgw1pacO0CRh7Xlt8m04HeEioc
gKAAoODHLsOxk6FbZQVPlm1vHzFsBngN
=/yK+
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running a x86_64 kernel on Fedora 15 x86 userland
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/03/2011 01:14 PM, Thomas Meyer wrote: Am 03.05.2011 um 15:14 schrieb Daniel J Walsh: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/02/2011 03:49 PM, Thomas Meyer wrote: Hi, I try to run a x86_64 kernel on x86 Fedora 15 userland. But systemd get's somehow stuck in the boot process. Any ideas how to debug the problem? What is systemd waiting for? I need to boot with selinux=0 as I get some selinux errors (file not found or something like this, strangley these lines doesn't show up in the netconsole log). Here is what I could catch via netconsole and systemd.log_level=debug: Have you grabbed the latest SELinux policy out of koji for F15? What AVC messages are you seeing? I don't get an AVC message, so maybe there is not problem with selinux, just with plymouth, that ABRTs. But I see this: [7.204437] type=1403 audit(1304471120.046:3): policy loaded auid=4294967295 ses=4294967295 Unable to fix label of /sys/fs/cgroup/systemd: No such file or directory Unable to fix label of /sys/fs/cgroup/cpuset: No such file or directory Unable to fix label of /sys/fs/cgroup/cpu: No such file or directory Unable to fix label of /sys/fs/cgroup/cpuacct: No such file or directory Unable to fix label of /sys/fs/cgroup/devices: No such file or directory Unable to fix label of /sys/fs/cgroup/freezer: No such file or directory Unable to fix label of /sys/fs/cgroup/net_cls: No such file or directory Unable to fix label of /sys/fs/cgroup/blkio: No such file or directory [7.828143] 31systemd[1]: Successfully opened /dev/kmsg for logging. [7.829998] 30systemd[1]: systemd 25 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +SYSVINIT +LIBCRYPTSETUP; fedora) I guess systemd tries to relabel these files, but fails somehow!? Well the cgroup file system does not support labeling yet, so I would expect systemd-tmpfiles to fail there. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3ARJAACgkQrlYvE4MpobN/0QCgxUh7zBNdelC1rx5J2W9le9OU ujgAoLtaYkNb/SKVFyUk2pVVlYAcAdLt =Ax0l -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/29/2011 11:07 AM, Stephen Smalley wrote:
On Fri, 2011-04-29 at 00:37 +0200, Michał Piotrowski wrote:
Hi,
I think it's a very good decision - I never understood why selinux dir
is directly under /.
I guess I missed some discussion of this. You'd need to update
libselinux at least, definition of SELINUXMNT in
libselinux/src/policy.h, used by selinux_init_load_policy() to mount
selinuxfs for initial policy load. And it may break rc scripts and
other scripts/programs that have become accustomed to /selinux.
Here is the patch I am thinking about.
I think mock might need to be updated, maybe livecd tools.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2615cACgkQrlYvE4MpobPYlQCfeB3H0/eTVITUbOkv66/P+0DB
7pAAn3nYJZSDLyJnDv7+VXwTlZQ3TW9R
=2hkb
-END PGP SIGNATURE-
diff --git a/libselinux/src/init.c b/libselinux/src/init.c
index a948920..43aa296 100644
--- a/libselinux/src/init.c
+++ b/libselinux/src/init.c
@@ -45,6 +45,18 @@ static void init_selinuxmnt(void)
}
}
+ /* We check to see if the original mount point for selinux file
+* system has a selinuxfs. */
+ do {
+ rc = statfs(/selinux, sfbuf);
+ } while (rc 0 errno == EINTR);
+ if (rc == 0) {
+ if ((uint32_t)sfbuf.f_type == (uint32_t)SELINUX_MAGIC) {
+ selinux_mnt = strdup(/selinux);
+ return;
+ }
+ }
+
/* Drop back to detecting it the long way. */
fp = fopen(/proc/filesystems, r);
if (!fp)
diff --git a/libselinux/src/load_policy.c b/libselinux/src/load_policy.c
index 83d2143..4078f69 100644
--- a/libselinux/src/load_policy.c
+++ b/libselinux/src/load_policy.c
@@ -369,7 +369,17 @@ int selinux_init_load_policy(int *enforce)
* Check for the existence of SELinux via selinuxfs, and
* mount it if present for use in the calls below.
*/
- if (mount(selinuxfs, SELINUXMNT, selinuxfs, 0, 0) 0 errno !=
EBUSY) {
+ char *mntpoint = NULL;
+ if (mount(selinuxfs, SELINUXMNT, selinuxfs, 0, 0) == 0 || errno ==
EBUSY) {
+ mntpoint = SELINUXMNT;
+ } else {
+ /* check old mountpoint */
+ if (mount(selinuxfs, /selinux, selinuxfs, 0, 0) == 0 ||
errno == EBUSY) {
+ mntpoint = /selinux;
+ }
+ }
+
+ if (! mntpoint ) {
if (errno == ENODEV) {
/*
* SELinux was disabled in the kernel, either
@@ -384,8 +394,8 @@ int selinux_init_load_policy(int *enforce)
}
goto noload;
- }
- set_selinuxmnt(SELINUXMNT);
+ }
+ set_selinuxmnt(mntpoint);
/*
* Note: The following code depends on having selinuxfs
@@ -397,7 +407,7 @@ int selinux_init_load_policy(int *enforce)
rc = security_disable();
if (rc == 0) {
/* Successfully disabled, so umount selinuxfs too. */
- umount(SELINUXMNT);
+ umount(selinux_mnt);
fini_selinuxmnt();
}
/*
diff --git a/libselinux/src/policy.h b/libselinux/src/policy.h
index 10e8712..76f968e 100644
--- a/libselinux/src/policy.h
+++ b/libselinux/src/policy.h
@@ -13,7 +13,7 @@
#define SELINUX_MAGIC 0xf97cff8c
/* Preferred selinux mount location */
-#define SELINUXMNT /selinux
+#define SELINUXMNT /sys/fs/selinux
/* selinuxfs mount point */
extern char *selinux_mnt;
libselinux-mountpoint.patch.sig
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/29/2011 06:56 PM, Lennart Poettering wrote: On Fri, 29.04.11 00:37, Michał Piotrowski (mkkp...@gmail.com) wrote: Hi, I think it's a very good decision - I never understood why selinux dir is directly under /. Yes, I think this would be a good thing to have in F16. Note however that this needs a tiny kernel patch to work, to create the mount point under /sys/fs/selinux. This is a trivial patch and has been done for /sys/fs/cgroup before, so I assume this would be easy to get in and just needs a champion to push this forward. By the way, maybe it would be good to think about the meaning of /srv existance? For seven years FHS requires that this directory exists http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A but The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done - so even the authors of the standard did not have anything to say about how this directory should be used. Is there a rational reason for the existence of this directory besides FHS conformance? I think /srv actually makes a lot of sense. Probably not so much on the desktop, but the boundaries are blurry, and I see no reason to set things up differently in this respect between servers and desktops. I see little benefit in removing this directory. Lennart I think moving /selinux is a bit more complicated then just a simple kernel change. We have libselinux changes, Lots of tools have learned over the years the path of /selinux and lots of users know about it. I am willing to work towards the goal of moving /selinux, but I might end up with a symbolic link if we can not fix all of the problems. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk27RKUACgkQrlYvE4MpobOCoACgvLrAnXtzvxV7ztHP4aiGr8Df VZ4AnAnqTzUofp62+IHkc9WmTvh74sRE =NLi7 -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What makes systemd-nspawn not suitable for secure container setups?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/26/2011 01:54 PM, Lennart Poettering wrote: On Mon, 25.04.11 20:51, microcai (micro...@fedoraproject.org) wrote: 于 2011年04月25日 20:43, Daniel J Walsh 写道: SELinux would be a good start. No, root inside can still change SE-Linux policy. No. The SELinux policy can forbid reloading the SELinux policy for certain users/processes. SELinux should work fine to secure nspawn containers. Lennart Right the idea would be to run all processes within te nspawn container with the same process label, then only allow the access required for the container. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk23B90ACgkQrlYvE4MpobNUXACgma9He3gGO6tZdv7WVwJaE0oe mUsAoJ2GMaDRfP7hpflfS3Eqx3wEQKtM =CqeA -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What makes systemd-nspawn not suitable for secure container setups?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/22/2011 07:42 PM, Josh Triplett wrote: The systemd-nspawn manpage lists the various mechanisms used to isolate the container, and then says Note that even though these security precautions are taken systemd-nspawn is not suitable for secure container setups. Many of the security features may be circumvented and are hence primarily useful to avoid accidental changes to the host system from the container. How can a process in a systemd-nspawn container circumvent the container setup? What additional steps would systemd-nspawn need to take to provide a secure container setup? - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel SELinux would be a good start. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk21bFcACgkQrlYvE4MpobNwJwCeO7xqfUTykQGDQsiJj3oAYD/4 4bIAoNJucumKU17lquo/insid7cYwCg9 =H8IP -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/4] condition: add ConditionSELinux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2011 06:32 PM, Kay Sievers wrote: On Mon, Apr 4, 2011 at 23:39, Michal Schmidt mschm...@redhat.com wrote: On Mon, 4 Apr 2011 22:51:55 +0200 Kay Sievers wrote: We really need something here that is not tied to the / inode, because we want to support r/o / or / on tmpfs with only the subdirs mounted from disk. xattrs of / just have the same issues as /.-files, it's just a different storage format regarding that problem. The key is it would a _per-filesystem_ flag meaning this fs is tainted for use with SELinux and needs relabeling. The xattr containing the value of the flag would be attached to the relative / of every mounted filesystem. filesystems mounted ro don't matter, because they cannot get their file contexts changed and therefore do not need to be marked tainted. mount itself should write the xattr when it mounts the filesystem read-write and SELinux is disabled. Bill Nottingham noted on IRC that relabeling would then be done by systemd in the same pass that handles fsck. Yeah, sounds good if that works. The setup we might want to support in the future is that the couple of needed / directories are populated by btrfs subvolumes. Something like such a flag on the root of the individual subvolume that gets mounted might work just fine. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel systemd should check if the mount flag includes seclabel field. before labeling. If a file system does not support labeling or does is mounted with a context mount option, the file system will not show the label seclabel. grep seclabel /proc/self/mountinfo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2bDkMACgkQrlYvE4MpobN9zQCfWIFyN/v867REStweuQjjFNbi 7ZUAoK8w6DDOz3+B9VYvYENDi6g4MOY0 =jz/r -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/4] condition: add ConditionSELinux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/05/2011 08:59 AM, Lennart Poettering wrote: On Tue, 05.04.11 08:42, Daniel J Walsh (dwa...@redhat.com) wrote: systemd should check if the mount flag includes seclabel field. before labeling. If a file system does not support labeling or does is mounted with a context mount option, the file system will not show the label seclabel. grep seclabel /proc/self/mountinfo What happens if we try to relabel those file systems nonetheless? Just errors? Hmm, we currently only relabel /run and /dev recursively, plus the top-level inode of all API file systems we mount. I presume devtmpfs and tmpfs do support seclabel, right? Do we really have to code a check for this flag? Given that the list of API mount points we mount at early boot is pretty much fixed (http://cgit.freedesktop.org/systemd/tree/src/mount-setup.c#n51) we could just hardcod the invocation of the relabelling per-filesystem. Do you have any particular file system in mind where we currently relabel where we shouldn't? I'd like to understand what the precise implications of the seclabel option are, is there some doc available somewhere? The mount man page doesn't mention it... :-( Lennart SECLABEL is a kernel flag that indicates that the file system supports extended attributes file labeling. It is not a mount option. If you mount with a context=system_u:object_r:TYPE_T:so flag, then the kernel will turn off the SECLABEL flag. The flag will also not show up on file systems that do not supported extended attributes. In F14 the rc.sysinit script would execute the fixfiles restore script if it found a /.autorelabel in the root directory. fixfiles restore would then look at ALL mounted file systems that did not have the SECLABEL flag on them, and fix the labels. I would recommend that you use fixfiles/setfiles/restorecon to relabel the file systems you see with the autorelabel flag in them. I still have a problem with going with the mount command writing the /.autorelabel flag, in that an admin might want to force a relabel of his entire file system, he currently just adds /.autorelabel. I the new model he would have to go to every file system and put the flag in the root of the file system. Or we could continue to have /.autorelabel means force a relabel everywhere, where as .autorelabel in a file system with out /.autorelabel will cause just that file system to be relabeled. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2bHBkACgkQrlYvE4MpobNnlQCfXivNMJhs7aZ2kFmiaHhshIU6 ZdEAoOKNjL3vyM87yXfxHWRKdYNw5VKj =aLG8 -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SELinux support takes up ~15MB of memory?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/06/2011 07:28 PM, Lennart Poettering wrote: On Sat, 04.12.10 22:57, Ran Benita (ran...@gmail.com) wrote: The culprit seems to be selabel_lookup_raw which gets called by several functions in label.c (mostly label_mkdir and label_fix). These, in turn, seem to compile a great amount of regexes and store them in an array in an selabel_handle struct. systemd keeps around one called label_hnd (in label.c) in a static global variable for the duration of the program. This is what I observed from reading label.c in systemd, label_file.c in libselinux, and some gdb. But I may have got it completely wrong; It seems to keep the entire policy in memory, or something of the sort, but I really don't know how it's _supposed_ to work. This big blob is the policy data. It is loaded the first time we have to label something and then stays in memory. The data must be accessible at runtime hence the only real improvement we could do here is if libselinux would be able to share the loaded policy in some way, using mmap. But maybe they are already doing this. Anyway, I think this needs to be optimized more in libselinux than in systemd, so I'd encourage you to ping the selinux folks about this! Lennart Well it is keeping the entire file context tree labeling tree in memory. The file /etc/selinux/targeted/context/files/file_contexts compiled into Regexs. One optimization would be to only load the the directories that systemd is going to create files in, rather then the hole tree. For example I think you can say load only the regex starting with /var if systemd is only going to create and label content under /var. This would cause the size to shring considerably # wc -l /etc/selinux/targeted/contexts/files/file_contexts 3884 /etc/selinux/targeted/contexts/files/file_contexts # grep ^/var /etc/selinux/targeted/contexts/files/file_contexts | wc -l 1028 # grep ^/var/run /etc/selinux/targeted/contexts/files/file_contexts | wc -l 326 # grep ^/var/lock /etc/selinux/targeted/contexts/files/file_contexts | wc -l 10 Taking it a step father, we could decrease it even further. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0nIbAACgkQrlYvE4MpobPMdgCeKXgWBeZEOhlPrZYoGyXWbOgR iHwAnRp6VbQD7n8Kq+o0kJ4mkq3sVs8f =LzXg -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SELinux support takes up ~15MB of memory?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/07/2011 09:33 AM, Lennart Poettering wrote: On Fri, 07.01.11 09:22, Daniel J Walsh (dwa...@redhat.com) wrote: The data must be accessible at runtime hence the only real improvement we could do here is if libselinux would be able to share the loaded policy in some way, using mmap. But maybe they are already doing this. Anyway, I think this needs to be optimized more in libselinux than in systemd, so I'd encourage you to ping the selinux folks about this! Lennart Well it is keeping the entire file context tree labeling tree in memory. The file /etc/selinux/targeted/context/files/file_contexts compiled into Regexs. One optimization would be to only load the the directories that systemd is going to create files in, rather then the hole tree. For example I think you can say load only the regex starting with /var if systemd is only going to create and label content under /var. This would cause the size to shring considerably Hmm, can we start with an empty loaded policy and then load additional parts of it as we go? i.e. if we encounter a socket /foo/bar/waldo we ask libselinux to load /foo/bar, and so on? Most likely 90% of the sockets will be in the same dir anyway (/var/run), so after the first socket everything we need should be loaded most of the time. However, since sockets can be configured dynamically to any place we might need to load policy for other areas, too. Hence if we could load hte policy bit by bit we should get relatively nice behaviour and only load a minimal subset of the policy into memory. Lennart I think the library functions are there to do this, but you would have to do the management of the paths. libselinux I believe does not have the capability to add a path after the initial load but you could have a link list of paths connected to blobs of regexes. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0nJfUACgkQrlYvE4MpobMc7wCg1zTXuTM3RGw8xdtjHaam6qwh X4IAoN4A6otCI+FYBvbOMCexyUC/rtbm =+LZF -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SELinux support takes up ~15MB of memory?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/07/2011 09:44 AM, Lennart Poettering wrote: On Fri, 07.01.11 09:40, Daniel J Walsh (dwa...@redhat.com) wrote: Hmm, can we start with an empty loaded policy and then load additional parts of it as we go? i.e. if we encounter a socket /foo/bar/waldo we ask libselinux to load /foo/bar, and so on? Most likely 90% of the sockets will be in the same dir anyway (/var/run), so after the first socket everything we need should be loaded most of the time. However, since sockets can be configured dynamically to any place we might need to load policy for other areas, too. Hence if we could load hte policy bit by bit we should get relatively nice behaviour and only load a minimal subset of the policy into memory. Lennart I think the library functions are there to do this, but you would have to do the management of the paths. libselinux I believe does not have the capability to add a path after the initial load but you could have a link list of paths connected to blobs of regexes. So, instead of loading one single policy blob we would basically load a number of independent policy blobs, but always only parts of the real thing? I guess that is quite doable, though I do wonder how the prefix finding algorithm should best look like... Lennart Yes and you have a speed versus size thing. Do you want to compile /var once or /var/lock and /var/run or much worse /var/run/app1 and /var/run/app2 ... I would not go above two directories. If you really want size versus speed you could free the blobs once you got to a steady state, if you can figure out you are in a steady state. And then reload them if you need too. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0nLtIACgkQrlYvE4MpobNwcACglha7dxx5qst94OiSmCnNZWf7 SiUAoNhUGB1EKvX9Iu2HPRUFxw46WZ8B =eciC -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SELinux support takes up ~15MB of memory?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/07/2011 11:00 AM, Lennart Poettering wrote: On Fri, 07.01.11 10:18, Daniel J Walsh (dwa...@redhat.com) wrote: On 01/07/2011 09:44 AM, Lennart Poettering wrote: On Fri, 07.01.11 09:40, Daniel J Walsh (dwa...@redhat.com) wrote: Hmm, can we start with an empty loaded policy and then load additional parts of it as we go? i.e. if we encounter a socket /foo/bar/waldo we ask libselinux to load /foo/bar, and so on? Most likely 90% of the sockets will be in the same dir anyway (/var/run), so after the first socket everything we need should be loaded most of the time. However, since sockets can be configured dynamically to any place we might need to load policy for other areas, too. Hence if we could load hte policy bit by bit we should get relatively nice behaviour and only load a minimal subset of the policy into memory. Lennart I think the library functions are there to do this, but you would have to do the management of the paths. libselinux I believe does not have the capability to add a path after the initial load but you could have a link list of paths connected to blobs of regexes. So, instead of loading one single policy blob we would basically load a number of independent policy blobs, but always only parts of the real thing? I guess that is quite doable, though I do wonder how the prefix finding algorithm should best look like... Lennart Yes and you have a speed versus size thing. Do you want to compile /var once or /var/lock and /var/run or much worse /var/run/app1 and /var/run/app2 ... I would not go above two directories. If you really want size versus speed you could free the blobs once you got to a steady state, if you can figure out you are in a steady state. And then reload them if you need too. Hmm, so, I wonder how far we could get by just hardcoding that we preload /var/run, /var/lock and /dev (the latter for /dev/initctl). That should cover 100% of the sockets/fifos of a usual install. And if that doesn't suffice we load the real deal on-demand. So, loading parts of the policy apparently takes up less memory. How exactly is the speed of loading the policy influenced by this? I.e. is loading a part of the policy as CPU/IO intensive as loading the full thing? Or even more CPU intensive due to a lot of compares? Or cheaper? Lennart I think it is just setup time. If all you are labeling in /dev is initctl, I would say just load that, /dev has lots of labels, that udev has to handle. The library is call regcomp on each line. grep ^/dev /etc/selinux/targeted/contexts/files/file_contexts | wc -l 277 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0nQZEACgkQrlYvE4MpobMxSwCfTczLRvKuVly/APVLEhW3cp4P WRcAoLuzneawNoV1/JlWhSmMuvCsxLkq =cJj7 -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
