Re: Default permissions on /dev/kvm

[Daniel J Walsh]

On 03/15/2017 11:49 AM, Daniel P. Berrange wrote:
> On Wed, Mar 15, 2017 at 11:32:35AM -0400, Dusty Mabe wrote:
>>
>> On 03/15/2017 05:17 AM, Daniel P. Berrange wrote:
>>> Sure, if udev maintainers are willing to ship the kvm rule by default,
>>> that's fine with me for reason you suggest. I simply don't think it'll
>>> have any effect on usage of /dev/kvm inside containers
>>>
>> Does that mean you assume my scenario I outlined is incorrect? The
>> only reason we are having this discussion is because i found that
>> changing the permissions of /dev/kvm on the host from 600 to 666 made
>> it so that I could run libvirt inside a container, which would mean
>> that if does have an effect on usage of /dev/kvm inside a container.
> Oh, wait I think I see - you don't have qemu installed in the host
> at all - you only installed it inside a docker image, but docker
> is just copying the host permissions, and thus see the default
> permissions from the kernel.
>
>> I could be "using it wrong", but would like for you to tell me why
>> what I'm doing is invalid.
> While Docker copies the permissions from host devices, I don't think
> that is something it is nice to rely on. Different operating systems
> have different views on what default permissions are. So if you build
> a Docker image that relies on the host OS having given /dev/kvm
> particular permissions, your Docker image is going to be non-portable.
>
> IOW while moving the udev rule out of the QEMU rpm into the udev RPM
> would fix it for future Fedora, your docker image is going to be
> unable to reliably run on other OS distros (whether older Fedora or
> Debian which has restrictive /dev/kvm by default).
>
> I don't see any way to force docker to give the device different
> permissions when using the --device flag to launch a container.
> In absence of that the only other option is to use an entrypoint
> script to chmod the file when your container starts, but that
> requires the container to run privileged which is bad. I think
> ideally Docker would provide some way to give explicit permissions
> so your container is isolated from decisions OS distros make about
> default permissions in the host. 
>
> Regards,
> Daniel
Lets open a bugzilla on this for docker, although I am not sure upstream
would be amenable to a decent solution.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

[Daniel J Walsh]

On 03/15/2017 05:27 AM, Daniel P. Berrange wrote:
> On Tue, Mar 14, 2017 at 05:35:54PM -0400, Daniel J Walsh wrote:
>>
>> On 03/14/2017 05:18 PM, Dusty Mabe wrote:
>>> On 03/14/2017 05:15 PM, Daniel J Walsh wrote:
>>>> On 03/14/2017 05:02 PM, Dusty Mabe wrote:
>>>>> On 03/14/2017 04:56 PM, Daniel J Walsh wrote:
>>>>>> On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
>>>>>> I guess if you volume/bind mount the device into the container you could
>>>>>> see an issue,
>>>>>> but most containers that deal with /dev/kvm are going to be run as root,
>>>>>> anyways.
>>>>> I was running with --privileged, still got permission denied until I
>>>>> changed permissions of /dev/kvm to 666.
>>>>> ___
>>>>> devel mailing list -- devel@lists.fedoraproject.org
>>>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>>> # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
>>>> crw-rw-rw-. 1 root 36 system_u:object_r:container_file_t:s0:c303,c737 10, 
>>>> 232 Mar 14 21:12 /dev/kvm
>>>> # chmod 600 /dev/kvm 
>>>> # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm 
>>>> crw---. 1 root 36 system_u:object_r:container_file_t:s0:c281,c442 10, 
>>>> 232 Mar 14 21:13 /dev/kvm
>>>>
>>>> So using --device to add the device to the container just maintains the 
>>>> permission of the host
>>>> for the device you added.  Whether it is volume mounted in or specified 
>>>> via --device, at least
>>>> from dockers point of view. 
>>> I'm not sure of your point. I was just trying to say that whether i
>>> was root or not did not seem to matter. I still got permission denied
>>> if perms were 600 and not 666. I'm working off of memory here, so it's
>>> possible somebody will prove me wrong.
>> Most likely libvirt or whoever is launching the containers is not running
>> as root, so it is being blocked access.
> It is simpler than that. When you ask libvirt to assign a device to a
> container it will simply mknod() in the container's private /dev, with
> permissions 0700. If the container needs to make that available to
> mon-privileged users inside the container, its "init" has to arrange
> to set permissions further.
>
> For Docker, I'm unclear whether it is also just doing a mknod in the
> container's /dev, or whether it is bind mounting the host device node.
> Either way, udev isn't involved inside the container.
>
> Regards,
> Daniel
My point was that docker is just matching the permissions from the host.

In the case of using docker run --device /dev/kvm
It is creating a different device


#ls -i /dev/kvm

18835 /dev/kvm

# docker run -ti --device /dev/kvm fedora sh

# ls -lZ /dev/kvm 
crw---. 1 root 36 system_u:object_r:container_file_t:s0:c516,c728 10, 232 
Mar 15 11:44 /dev/kvm
# ls -i /dev/kvm 
669570 /dev/kvm

If I chmod 666 outside of the container the mode of the container is still 600, 
so they are different devices.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

[Daniel J Walsh]

On 03/14/2017 05:18 PM, Dusty Mabe wrote:
>
> On 03/14/2017 05:15 PM, Daniel J Walsh wrote:
>>
>> On 03/14/2017 05:02 PM, Dusty Mabe wrote:
>>> On 03/14/2017 04:56 PM, Daniel J Walsh wrote:
>>>> On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
>>>> I guess if you volume/bind mount the device into the container you could
>>>> see an issue,
>>>> but most containers that deal with /dev/kvm are going to be run as root,
>>>> anyways.
>>> I was running with --privileged, still got permission denied until I
>>> changed permissions of /dev/kvm to 666.
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
>> crw-rw-rw-. 1 root 36 system_u:object_r:container_file_t:s0:c303,c737 10, 
>> 232 Mar 14 21:12 /dev/kvm
>> # chmod 600 /dev/kvm 
>> # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm 
>> crw---. 1 root 36 system_u:object_r:container_file_t:s0:c281,c442 10, 
>> 232 Mar 14 21:13 /dev/kvm
>>
>> So using --device to add the device to the container just maintains the 
>> permission of the host
>> for the device you added.  Whether it is volume mounted in or specified via 
>> --device, at least
>> from dockers point of view. 
> I'm not sure of your point. I was just trying to say that whether i
> was root or not did not seem to matter. I still got permission denied
> if perms were 600 and not 666. I'm working off of memory here, so it's
> possible somebody will prove me wrong.
>
> Dusty
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Most likely libvirt or whoever is launching the containers is not running
as root, so it is being blocked access.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

[Daniel J Walsh]

On 03/14/2017 05:02 PM, Dusty Mabe wrote:
>
> On 03/14/2017 04:56 PM, Daniel J Walsh wrote:
>>
>> On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
>> I guess if you volume/bind mount the device into the container you could
>> see an issue,
>> but most containers that deal with /dev/kvm are going to be run as root,
>> anyways.
> I was running with --privileged, still got permission denied until I
> changed permissions of /dev/kvm to 666.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

# docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
crw-rw-rw-. 1 root 36 system_u:object_r:container_file_t:s0:c303,c737 10, 232 
Mar 14 21:12 /dev/kvm
# chmod 600 /dev/kvm 
# docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm 
crw---. 1 root 36 system_u:object_r:container_file_t:s0:c281,c442 10, 232 
Mar 14 21:13 /dev/kvm

So using --device to add the device to the container just maintains the 
permission of the host
for the device you added.  Whether it is volume mounted in or specified via 
--device, at least
from dockers point of view. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

[Daniel J Walsh]

On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
> On Tue, Mar 14, 2017 at 08:09:00PM +, Richard W.M. Jones wrote:
>> Re: https://bugzilla.redhat.com/show_bug.cgi?id=1431876
>>
>> Currently if you install a minimal-ish, non-"Virtualization Host"
>> Fedora, then the permissions on the /dev/kvm device are:
>>
>>   crw---. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
>>
>> (I believe this is because of some kernel defaults for the device.  In
>> any case there seems to be no base install udev rule which applies a
>> `MODE=' line explicitly for /dev/kvm).
>>
>> There mere act of installing the qemu package adds a new udev rule
>> which changes the permissions:
>>
>>   [root@rawhide ~]# ll /dev/kvm 
>>   crw---. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
>>   [root@rawhide ~]# dnf -y install qemu-system-x86
>>   //...
>>   [root@rawhide ~]# ll /dev/kvm
>>   crw-rw-rw-. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
>>
>> I don't have a problem with any of that and I'm not saying that the
>> permissions should be more restrictive, but for balance I will note
>> that in Debian /dev/kvm is more restrictive (see comment in the bug
>> above).
>>
>> The problem raised in the bug above is that with containers people
>> will wish to install qemu or libvirt or other tools inside the
>> containers, but not necessarily have qemu installed on the host.  In
>> that case, they will always see /dev/kvm with mode 0600, ie. generally
>> unusable for them.
> I'm fuzzy about the issue faced with containers. Containers will usually
> have a separate /dev that is populated by the container mgmt engine (whether
> docker, libvirt, lxc or something else). That mgmt engine is responsible for
> setting permissions of /dev/kvm in the container's /dev if the user asked for
> /dev/kvm to be made available. udev should never run inside a container - it
> is only supposed to run in host context. So any udev rules that manipulate
> /dev/kvm permissions will only ever be used in host context and never have
> any effect on containers.
>
> The bug listed above doesn't actually describe any real problem with
> containers & /dev/kvm - my reading is that the bug is just thinking
> about a hypothetical  future problem, but since udev isn't involved
> in containers' /dev mgmt, I don't think there's a bug that needs fixing
> here.
>
> Regards,
> Daniel
I guess if you volume/bind mount the device into the container you could
see an issue,
but most containers that deal with /dev/kvm are going to be run as root,
anyways.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Changing default "docker" storage to to Overlay2 in Fedora 26

[Daniel J Walsh]

What is going on with this Change Request?  Any reason it has not been
acted on at this point?  We are putting changes into our packages
assuming that this will be allowed.


On 01/06/2017 05:08 PM, Igor Gnatenko wrote:
> On Fri, Jan 6, 2017 at 9:29 PM, Daniel J Walsh <dwa...@redhat.com> wrote:
>> https://fedoraproject.org/wiki/Changes/DockerOverlay2
> Thanks! Note, that you will need to send it for wrangler.
>>
>> On 01/06/2017 02:27 PM, Igor Gnatenko wrote:
>>
>> Shouldn't this be submitted as a change?
>>
>> This would bring much more visibility to users of Fedora and even outside.
>>
>> -Igor Gnatenko
>>
>> On Jan 6, 2017 8:13 PM, "Daniel J Walsh" <dwa...@redhat.com> wrote:
>>> Upstream docker is moving to overlay2 by default for its storage.  We
>>> plan on following suit.  Their are some performance advantages of
>>> overlay2 over devicemapper in memory sharing, which we would like to
>>> take advantage of.   We now have SELinux support for Overlay  file
>>> systems, so the security should be just as good.
>>>
>>> Note: Overlay is not a Posix Compliant file system, so their could be
>>> problems with your containers running on overlay, so
>>> we want to make sure it is fairly easy to switch back to devicemapper.
>>>
>>> Devicemapper out of the box, on Fedora Workstation, currently defaults
>>> to loopback devices for storage, which has a performance penalty, but
>>> this was the only way we were able to get docker to work right away.
>>> Switching to overlay2 will cause the storage to be shared with / and
>>> will eliminate this performance overhead.   This is the way we will ship
>>> Fedora Workstation.
>>>
>>> On Fedora atomic host and Fedora server we have been storing
>>> devicemapper storage on a separate partition.  We plan on doing the same
>>> thing with overlay2.  This means separate device will be mounted on
>>> /var/lib/docker.  This will make it easier for someone to switch back to
>>> devicemapper, if overlay2 has problems.
>>>
>>> Upgraded systems will not be effected.
>>>
>>> If you want to switch from one storage to another take a look at the
>>> `atomic storage` commands.
>>>
>>> We will write up release notes to cover this change. Along with a blog
>>> explaining the commands to switch back and forth.
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: per-product packaging question

[Daniel J Walsh]

On 02/01/2017 09:58 AM, Stephen Gallagher wrote:
> On 01/30/2017 05:03 PM, Vivek Goyal wrote:
>> On Mon, Jan 30, 2017 at 05:00:34PM -0500, Lokesh Mandvekar wrote:
>>> Hi,
>>>
>>> I'm looking at the per-product packaging doc at
>>> https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration
>>> and I see that variants for all products are installed at package install 
>>> time, with
>>> the ghost file pointing to the appropriate product variant.
>>>
>>> Just wondering if there's a reason for installing all variants and/or if 
>>> it's
>>> worth considering installation of just the particular variant appropriate 
>>> for
>>> the system at install time?
>> We are looking at installing per-product configuration for
>> docker-storage-setup. Now we are ending up with many configuration
>> files.
>>
>> /etc/sysconfig/docker-storage-setup-default
>> /etc/sysconfig/docker-storage-setup-server
>> /etc/sysconfig/docker-storage-setup-workstation
>> /etc/sysconfig/docker-storage-setup-atomic
>> /etc/sysconfig/docker-storage-setup-cloud
>>
>> This really looks ugly. So question is can we just install the default
>> and config file specific to that product and ignore rest?
>>
> The reason for this is because there are situations where it is impossible to
> know what variant is in use until the %posttrans scripts have fired. (This is
> because on initial system installation, the variant is selected when the
> fedora-release-$EDITION package %post has been run).
>
> All file installation happens well before the %post and %posttrans operations
> are run, and therefore there isn't any way to determine which file belongs on
> the system.
>
> I *do* recommend that you consider moving the original, versioned config files
> into a subdirectory somewhere and only include the `docker-storage-setup`
> symlink in the actual end-user location.
>
> The reason for using symlinks rather than copies here was originally to 
> support
> the possibility of converting between editions (such as promoting Fedora Cloud
> to a Fedora Server Edition) and having the configuration automatically swapped
> for you, but that never got implemented.
>
> Given that this is never going to happen (we decided that changing the config
> implicitly is a bad idea), I should update the policy to recommend using 
> copies
> rather than symlinks and keeping the variant configs in /usr/share instead of 
> in
> the /etc hierarchy.
>
>
> So in this specific case, I'd recommend that you install:
> /usr/share/docker-storage-setup/docker-storage-setup-default
> /usr/share/docker-storage-setup/docker-storage-setup-server
> /usr/share/docker-storage-setup/docker-storage-setup-workstation
> /usr/share/docker-storage-setup/docker-storage-setup-atomic
> /usr/share/docker-storage-setup/docker-storage-setup-cloud
>
> And then copy the appropriate one from there to
> /etc/sysconfig/docker-storage-setup in %posttrans.
>
> I'll also note that you only need individual config files *if they differ*. 
> For
> example, if the "atomic" and "cloud" configs are identical, it's okay to skip
> the duplication. Ditto if "default" and "server" should be the same, etc.
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
This works for me.  As long as it is a real file and not a symlink which
would lead to an
admin editing files in /usr. 

The docker package should ghost the /etc/sysconfig/docker-storage-setup
file though.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: per-product packaging question

[Daniel J Walsh]

We should just install one default in the default location,  We don't
want to document to users the difference

During post install the content can be modified based on the package.


On 01/30/2017 05:03 PM, Vivek Goyal wrote:
> On Mon, Jan 30, 2017 at 05:00:34PM -0500, Lokesh Mandvekar wrote:
>> Hi,
>>
>> I'm looking at the per-product packaging doc at
>> https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration
>> and I see that variants for all products are installed at package install 
>> time, with
>> the ghost file pointing to the appropriate product variant.
>>
>> Just wondering if there's a reason for installing all variants and/or if it's
>> worth considering installation of just the particular variant appropriate for
>> the system at install time?
> We are looking at installing per-product configuration for
> docker-storage-setup. Now we are ending up with many configuration
> files.
>
> /etc/sysconfig/docker-storage-setup-default
> /etc/sysconfig/docker-storage-setup-server
> /etc/sysconfig/docker-storage-setup-workstation
> /etc/sysconfig/docker-storage-setup-atomic
> /etc/sysconfig/docker-storage-setup-cloud
>
> This really looks ugly. So question is can we just install the default
> and config file specific to that product and ignore rest?
>
> Vivek
>
>
>> Thanks,
>> -- 
>> Lokesh
>> Freenode: lsm5
>> GPG: 0xC7C3A0DD
>> https://keybase.io/lsm5
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Docker Overlay 2

[Daniel J Walsh]

On 01/19/2017 10:17 AM, James Hogarth wrote:
>
>
> On 19 Jan 2017 2:43 pm, "Daniel J Walsh" <dwa...@redhat.com
> <mailto:dwa...@redhat.com>> wrote:
>
>
>
> On 01/19/2017 09:20 AM, Matthew Miller wrote:
> > On Thu, Jan 19, 2017 at 08:36:02AM +0100, Jan Kurik wrote:
> >> Change the default Docker Storage to be overlay2 .
> > I made a couple of edits to this, mostly clarifying that overlay2 is
> > not a second overlay filesystem, but a second Docker driver for the
> > same OverlayFS.
> >
> Sounds good to me.
>
>
> Just to quickly clarify something.
>
> If no storage driver is specified right now and /var/lib/docker is
> btrfs the btrfs driver then gets used automatically.
>
> Will I need to be aware of any specific configuration changes on my
> btrfs workstations to avoid breakage and keep things working as they are?
>
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Docker should realize a previous uses backing store and continue to use
it.  This should only effect fresh installs or systems where someone does an

atomic storage reset.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Docker Overlay 2

[Daniel J Walsh]

On 01/19/2017 09:20 AM, Matthew Miller wrote:
> On Thu, Jan 19, 2017 at 08:36:02AM +0100, Jan Kurik wrote:
>> Change the default Docker Storage to be overlay2 .
> I made a couple of edits to this, mostly clarifying that overlay2 is
> not a second overlay filesystem, but a second Docker driver for the
> same OverlayFS.
>
Sounds good to me.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Changing default "docker" storage to to Overlay2 in Fedora 26

[Daniel J Walsh]

https://fedoraproject.org/wiki/Changes/DockerOverlay2


On 01/06/2017 02:27 PM, Igor Gnatenko wrote:
> Shouldn't this be submitted as a change? 
>
> This would bring much more visibility to users of Fedora and even outside.
>
> -Igor Gnatenko
>
> On Jan 6, 2017 8:13 PM, "Daniel J Walsh" <dwa...@redhat.com
> <mailto:dwa...@redhat.com>> wrote:
>
> Upstream docker is moving to overlay2 by default for its storage.  We
> plan on following suit.  Their are some performance advantages of
> overlay2 over devicemapper in memory sharing, which we would like to
> take advantage of.   We now have SELinux support for Overlay  file
> systems, so the security should be just as good.
>
> Note: Overlay is not a Posix Compliant file system, so their could be
> problems with your containers running on overlay, so
> we want to make sure it is fairly easy to switch back to devicemapper.
>
> Devicemapper out of the box, on Fedora Workstation, currently defaults
> to loopback devices for storage, which has a performance penalty, but
> this was the only way we were able to get docker to work right away.
> Switching to overlay2 will cause the storage to be shared with / and
> will eliminate this performance overhead.   This is the way we
> will ship
> Fedora Workstation.
>
> On Fedora atomic host and Fedora server we have been storing
> devicemapper storage on a separate partition.  We plan on doing
> the same
> thing with overlay2.  This means separate device will be mounted on
> /var/lib/docker.  This will make it easier for someone to switch
> back to
> devicemapper, if overlay2 has problems.
>
> Upgraded systems will not be effected.
>
> If you want to switch from one storage to another take a look at the
> `atomic storage` commands.
>
> We will write up release notes to cover this change. Along with a blog
> explaining the commands to switch back and forth.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> <mailto:devel@lists.fedoraproject.org>
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> <mailto:devel-le...@lists.fedoraproject.org>
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Changing default "docker" storage to to Overlay2 in Fedora 26

[Daniel J Walsh]

Upstream docker is moving to overlay2 by default for its storage.  We
plan on following suit.  Their are some performance advantages of
overlay2 over devicemapper in memory sharing, which we would like to
take advantage of.   We now have SELinux support for Overlay  file
systems, so the security should be just as good.

Note: Overlay is not a Posix Compliant file system, so their could be
problems with your containers running on overlay, so
we want to make sure it is fairly easy to switch back to devicemapper.

Devicemapper out of the box, on Fedora Workstation, currently defaults
to loopback devices for storage, which has a performance penalty, but
this was the only way we were able to get docker to work right away. 
Switching to overlay2 will cause the storage to be shared with / and
will eliminate this performance overhead.   This is the way we will ship
Fedora Workstation.

On Fedora atomic host and Fedora server we have been storing
devicemapper storage on a separate partition.  We plan on doing the same
thing with overlay2.  This means separate device will be mounted on
/var/lib/docker.  This will make it easier for someone to switch back to
devicemapper, if overlay2 has problems.

Upgraded systems will not be effected. 

If you want to switch from one storage to another take a look at the
`atomic storage` commands.

We will write up release notes to cover this change. Along with a blog
explaining the commands to switch back and forth.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support

[Daniel J Walsh]

On 01/05/2017 01:36 PM, Stephen John Smoogen wrote:
> On 5 January 2017 at 13:31, Daniel J Walsh <dwa...@redhat.com> wrote:
>>> You just described a fundamental change to how people would need to
>>> build 32-bit applications locally.  They don't have to install a
>>> VM/chroot to do that today, they would in a containerized multilib
>>> solution.  I don't think it's fair to claim "Building of software
>>> shouldn't be changed at all in most cases" with this proposal.
>>>
>>> Remember, not all software is built in mock or even as RPMs.  End user
>>> software developers will be impacted by the removal of existing
>>> multilib.
>>>
>>> josh
>> Sadly will we be hearing these same arguments 10 years from now...
> Yes. We will. And in 10 years from now the inevitable backlash against
> containers because they aren't new and nifty and had all these warts
> that come from real life will be in full swing. [This doesn't mean
> that containers will go away any more than they were completely new in
> the first place but ideas that Multics (and other OS's had) in the
> 1960/70's.] This is how software goes.
>
Well we will be retired at that point, and playing shuffle board.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support

[Daniel J Walsh]

On 01/05/2017 01:26 PM, Josh Boyer wrote:
> On Thu, Jan 5, 2017 at 11:25 AM, Stephen Gallagher  
> wrote:
>> On 01/05/2017 11:17 AM, Tom Hughes wrote:
>>> On 05/01/17 16:03, Stephen Gallagher wrote:
>>>
 For many years, Fedora has supported multilib by carrying 
 parallel-installable
 libraries in /usr/lib[64]. This was necessary for a very long time in 
 order to
 support 32-bit applications running on a 64-bit deployment. However, in 
 today's
 new container world, there is a whole new option.
>>> You may be living in a "new container world" but that doesn't mean the rest 
>>> of
>>> us (or our users) are.
>>>
>> By "new container world" I meant "a world where containers exist and can 
>> offer a
>> complete 32-bit runtime" rather than a hacked-in multilib runtime.
>>
 I'd like to propose that we consider moving away from our traditional 
 approach
 to multilib in favor of recommending the use of a 32-bit container runtime 
 when
 needed on a 64-bit host.
>>> On the face of it it sounds like a terrible idea but perhaps I have
>>> misunderstood the consequences.
>>>
>>> Can you explain what this would actually mean for an average software 
>>> developer
>>> trying to build a 32 bit program?
>>>
>>> Take for example my day job where I'm developing a proprietary application 
>>> on a
>>> Fedora workstation. Now mostly I use a 64 bit build of the software but we 
>>> have
>>> a few databases we support where the vendor doesn't provide 64 bit 
>>> libraries so
>>> I have to use a 32 bit build.
>>>
>>> Would this mean I had to do some special dance to enter a container 
>>> environment
>>> in order to work with a 32 bit build rather than just telling our build 
>>> scripts
>>> to use "gcc -m32" when compiling?
>>>
>> Building of software shouldn't be changed at all in most cases. The main
>> difference would be installation/deployment. The idea would be that instead 
>> of
>> the 32-bit and 64-bit runtimes being installed directly in parallel on the 
>> base
>> system, they would instead be installed into effectively a chroot with its 
>> own
>> completely 32-bit runtime.
> You just described a fundamental change to how people would need to
> build 32-bit applications locally.  They don't have to install a
> VM/chroot to do that today, they would in a containerized multilib
> solution.  I don't think it's fair to claim "Building of software
> shouldn't be changed at all in most cases" with this proposal.
>
> Remember, not all software is built in mock or even as RPMs.  End user
> software developers will be impacted by the removal of existing
> multilib.
>
> josh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Sadly will we be hearing these same arguments 10 years from now...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Daniel J Walsh]

On 12/13/2016 03:21 PM, Tom Hughes wrote:
> On 13/12/16 20:02, Przemek Klosowski wrote:
>> On 12/13/2016 02:51 PM, Lennart Poettering wrote:
>>> Yeah, this is really what it boils down to: the goal with the systemd
>>> directives is to make things easy to grok and easy to change. I can
>>> probably explain to most Linux admins who have administered a current
>>> Fedora in 5min what ProtectSystem=strict and
>>> ReadWritePaths=/var/lib/myservice does, and why it's a good thing. And
>>
>> One thing that SELinux does right is auditing---access violations are
>> logged, so that there are no silent mysterious failures (well, mumble,
>> mumble, maybe sometimes, you know what I mean). Also, SELinux allows
>> debugging in the permissive mode that just logs without actually
>> blocking access. What happens after systemd directives result in
>> denials?
>
> There speaks the person that has never had something blocked by a
> noaudit rule in the selinux policy...
>
> Tom
>
I am all for this feature. But realize debugging EPERM is often
problematic when it comes to containerized environments.
You have Regular DAC, UserNamespace DAC, SELinux, SECCOMP, Other LSM
...  Which can all cause EPERM, diagnosing what caused them can often be
difficult.  A few years ago we attempted to work with the kernel on
FriendlyEperm, but got rejected because it was racy.  Often the only one
that know why you got EPERM is the kernel and most ways it does not
reveal why.

https://fedoraproject.org/wiki/Features/FriendlyEPERM
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Missing kubernetes files in f25 atomic?

[Daniel J Walsh]

Yes I think that would be cool and figure out whether or not his
containers work.  I am not sure if

the is a kublet container yet.  We are working on a docker container
also, but docker exists on the atomic host.


On 11/23/2016 11:19 AM, Mario Ceresa wrote:
> Thanks for the hints! It seems a nice idea indeed. I found the
> original post from Giuseppe:
> http://www.projectatomic.io/blog/2016/09/intro-to-system-containers/
>
> Do you think that I could use it to setup a small test cluster or it
> is still in progress?
>
> Best,
>
> Mario
>
> On Wed, 23 Nov 2016 at 16:30 Daniel J Walsh <dwa...@redhat.com
> <mailto:dwa...@redhat.com>> wrote:
>
>
>
> On 11/23/2016 10:19 AM, Matthew Miller wrote:
> > On Wed, Nov 23, 2016 at 10:15:29AM -0500, Daniel J Walsh wrote:
> >> We are working on this in
> >> https://github.com/projectatomic/atomic-system-containers
> >>
> >>
> >> I think giuseppe has some experimental system containers
> available for
> >> this.  We need to build them as official
> >> Fedora 25 container images though.
> > Can this be done through the Layered Image Build Service?
> >
> I don't see why not.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> <mailto:devel@lists.fedoraproject.org>
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> <mailto:devel-le...@lists.fedoraproject.org>
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Missing kubernetes files in f25 atomic?

[Daniel J Walsh]

On 11/23/2016 10:19 AM, Matthew Miller wrote:
> On Wed, Nov 23, 2016 at 10:15:29AM -0500, Daniel J Walsh wrote:
>> We are working on this in
>> https://github.com/projectatomic/atomic-system-containers
>>
>>
>> I think giuseppe has some experimental system containers available for
>> this.  We need to build them as official
>> Fedora 25 container images though.
> Can this be done through the Layered Image Build Service?
>
I don't see why not.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Missing kubernetes files in f25 atomic?

[Daniel J Walsh]

We are working on this in

https://github.com/projectatomic/atomic-system-containers


I think giuseppe has some experimental system containers available for
this.  We need to build them as official

Fedora 25 container images though.


On 11/23/2016 09:12 AM, Mario Ceresa wrote:
> Hi,
> I've just rebased an existing f24 atom to f25 and now I'm unable to
> find some kubernetes related files:
> * /usr/bin/etcd
> * /usr/lib/systemd/system/etcd.service
> * /usr/bin/kubectl
> * /usr/bin/hyperkube
>
> Those files are installed by packages such as (etcd,
> kubernetes-client, kubernetes-master) in f25 workstation. Is there a
> way to "install" them in the atom?
>
> Thanks and regards,
>
> Mario
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Modifying container storage for Fedora 26.

[Daniel J Walsh]

On 11/22/2016 06:24 PM, Josh Berkus wrote:
> Vivek, Dan,
>
>> - Now when docker users overlay2 graph driver, all the images, containers
>>   and associated metadata will be stored outside the root filesystem and
>>   onto /dev/docker-vg/foo logical volume.
> This is a change from current storage setup?  Right now, containers go in the 
> docker volume, but images do not.  If we can do that, it would be worth 
> having overlay right there.
>
> My one concern for Atomic is ... how do existing users upgrade when we make 
> this change?  Does their devicemapper config still just work when they pull 
> the new tree?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
They don't we to have tools to allow a user to convert from devicemapper
backend to overlay.  And we can document that in a blog once we make a
change.
I think there is an existing blog that covers it.

Sadly I can not find it right now.

But you can do something like:

atomic storage export
atomic storage reset
atomic storage modify --driver overlay2
atomic storage import

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Modifying container storage for Fedora 26.

[Daniel J Walsh]

No as long as the storage is modified before the first start of the
docker daemon and the first execution of docker-storage-setup, it should
be fine.


On 11/17/2016 07:54 PM, Subhendu Ghosh wrote:
>
> Assuming cloud-init can also select the storage or is that too late in
> the process?
>
>
> On Nov 16, 2016 15:58, "Vivek Goyal" <vgo...@redhat.com
> <mailto:vgo...@redhat.com>> wrote:
>
> On Wed, Nov 16, 2016 at 03:19:06PM -0500, Stephen Gallagher wrote:
> > On 11/16/2016 03:09 PM, Vivek Goyal wrote:
> > > On Wed, Nov 16, 2016 at 03:01:06PM -0500, Stephen Gallagher wrote:
> > >> On 11/16/2016 02:56 PM, Vivek Goyal wrote:
> > >>> On Wed, Nov 16, 2016 at 02:49:25PM -0500, Stephen Gallagher
> wrote:
> > >>>> On 11/16/2016 02:40 PM, Vivek Goyal wrote:
> > >>>>> On Wed, Nov 16, 2016 at 02:32:46PM -0500, Daniel J Walsh
> wrote:
> > >>>>>> We would like to change the docker container storage to
> default to
> > >>>>>> Overlayfs2 in Fedora 26.  But we have a problem on Atomic
> Host and
> > >>>>>> Fedora Server distributions.
> > >>>>>>
> > >>>>>>
> > >>>>>> Currently docker-storage-setup defaults to devicemapper
> and is hard
> > >>>>>> coded to setup a thinpool of 40% of remaining disk. 
> Otherwise it sets
> > >>>>>> up loopback devices on the root file system. 
>  Devicemapper is nice
> > >>>>>> since it works with thinpools and can automatically
> expand the storage
> > >>>>>> if the disk space is getting used up.
> > >>>>>>
> > >>>>>> Moving to Overlay, we can more easily use the root file
> system directly,
> > >>>>>> which would be fine for Fedora Workstation.  We want to
> preserve the use
> > >>>>>> of the remaining storage for Overlay on AH and Fedora
> Server,  since
> > >>>>>> this would give a user flexibility to switch back to
> using devicemapper
> > >>>>>> if they had problems with the Overlay driver.
> > >>>>>
> > >>>>> And being able to do so basically involves following.
> > >>>>>
> > >>>>> - docker-storage-setup creates a logical volume from free
> space
> > >>>>> - Creates a filesystem on that logical volume
> > >>>>> - Mounts that logical volume on the directory which docker
> is going to
> > >>>>>   use.
> > >>>>>
> > >>>>>   mount /dev/docker-vg/foo /var/lib/docker/
> > >>>>>
> > >>>>> - Now when docker users overlay2 graph driver, all the
> images, containers
> > >>>>>   and associated metadata will be stored outside the root
> filesystem and
> > >>>>>   onto /dev/docker-vg/foo logical volume.
> > >>>>>
> > >>>>>> We can not as easily
> > >>>>>> support the expanding disk for Overlay since we will not
> use using thinpool.
> > >>>>>
> > >>>>>>
> > >>>>>> We have looked at options to hard code OverlayFS with the
> defaults,
> > >>>>>
> > >>>>> If we always mount /var/lib/docker on on /dev/vg/foo for
> overlay2 driver
> > >>>>> this will be a regression w.r.t current behavior. So I
> would not
> > >>>>> recommend changing current behavior. I think this should
> be an opt-in.
> > >>>>> We are working on provide a config knob to elect this
> behavior and
> > >>>>> atomic host and fedora server will have to opt-in somehow.
> > >>>>>
> > >>>>> I think it will be easy for atomic host as they already
> drop something
> > >>>>> in /etc/sysconfig/docker-storage-setup. Not sure how
> fedora server
> > >>>>> variant will do it.
> > >>>>>
> > >>>>
> > >>>>
> > >>>> Today, Fedora Server relies on whatever is the default for
&

Modifying container storage for Fedora 26.

[Daniel J Walsh]

We would like to change the docker container storage to default to
Overlayfs2 in Fedora 26.  But we have a problem on Atomic Host and
Fedora Server distributions.


Currently docker-storage-setup defaults to devicemapper and is hard
coded to setup a thinpool of 40% of remaining disk.  Otherwise it sets
up loopback devices on the root file system.   Devicemapper is nice
since it works with thinpools and can automatically expand the storage
if the disk space is getting used up. 

Moving to Overlay, we can more easily use the root file system directly,
which would be fine for Fedora Workstation.  We want to preserve the use
of the remaining storage for Overlay on AH and Fedora Server,  since
this would give a user flexibility to switch back to using devicemapper
if they had problems with the Overlay driver.   We can not as easily
support the expanding disk for Overlay since we will not use using thinpool.

We have looked at options to hard code OverlayFS with the defaults, or
we could just drop a /etc/sysconfig/docker-storage-setup that specified
Overlay and the percentage of remaining space to use for the
/var/lib/docker device.  But what is the best way to set different
defaults for AH, Fedora Server and Fedora Workstation.

We would like to discuss with you guys about what  you would think is
the best way to handle. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: docker-compose & selinux

[Daniel J Walsh]

On 10/30/2016 02:54 PM, Nikos Roussos wrote:
> On 10/28/2016 02:58 PM, Daniel J Walsh wrote:
>> What AVC's are you seeing?
> Plenty of AVC messages in the form:
>
> type=AVC msg=audit(1477853452.023:1338): avc:  denied  { setattr } for
> pid=23456 comm="chown" name="app_model.MYD" dev="dm-0" ino=10879938
> scontext=system_u:system_r:container_t:s0:c140,c877
> tcontext=system_u:object_r:container_var_lib_t:s0 tclass=file permissive=0
>
> Where app_model is a specific database table. So by plenty I mean I get
> one AVC for each database table of my application (for .MYD|.MYI|.frm)
>
>
> Or similarly:
> sudo docker-compose logs db
>
> db_1 | chown: changing ownership of
> `/var/lib/mysql/project/app_name.MYD': Permission denied
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
Is the mysql directory automatically created via a volume? The problem
is this does not have a private label
associated with the database.  Do you know where on disk the directory
mounted into /var/lib/mysql exists?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: docker-compose & selinux

[Daniel J Walsh]

What AVC's are you seeing?


On 10/28/2016 05:59 AM, Nikos Roussos wrote:
> I use docker-compose extensively for local development. On F24 all I had
> to do to make it play well with selinux was something like this:
>
> sudo chcon -Rt svirt_sandbox_file_t project_folder
>
> After updating to F25 this doesn't work anymore. Did something changed
> on selinux policies (besides that label been renamed to
> container_file_t) or I should file a bug?
>
> Specifically I cannot start a mariadb container with compose.
>
>
> On a related note, I opened a bug on our developer portal, since it
> lacks any mention on SELinux
> https://github.com/developer-portal/content/issues/163
>
> ~nikos
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: User instances of systemd and SELinux

[Daniel J Walsh]

On 08/15/2016 04:10 PM, Andrew Lutomirski wrote:
> On Mon, Aug 15, 2016 at 12:59 PM, Daniel J Walsh <dwa...@redhat.com> wrote:
>>
>> On 08/10/2016 03:42 PM, Andrew Lutomirski wrote:
>>> On Wed, Aug 10, 2016 at 12:26 PM, Zbigniew Jędrzejewski-Szmek
>>> <zbys...@in.waw.pl> wrote:
>>>> On Tue, Aug 09, 2016 at 01:32:10PM -0400, Daniel J Walsh wrote:
>>>>> On 08/09/2016 10:24 AM, Michal Sekletar wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Most of you are probably aware that systemd except running as PID 1
>>>>>> also runs inside user sessions. This allow users to define their own
>>>>>> "user services" and start up various scripts and background processes
>>>>>> right after logging in.
>>>>>>
>>>>>> In default targeted policy PID 1 runs with init_t SELinux label and
>>>>>> --user instances of systemd are not confined by SELinux, i.e. running
>>>>>> with unconfined_t.
>>>>>>
>>>>>> During Flock I got asked whether we can change that and run systemd
>>>>>> --user instances in some confined domain. Fixing this on systemd side
>>>>>> should be trivial, i.e. we would have to add SELinuxContext= option
>>>>>> with appropriate value to /usr/lib/systemd/system/user@.service (unit
>>>>>> file used for spawning user instances of systemd).
>>>>>>
>>>>>> I am writing this email with a hope that we can discuss if above
>>>>>> proposal even makes sense (what are possible gains from system
>>>>>> security perspective) and if yes what is appropriate SELinux label to
>>>>>> use (I guess we would need new one and define policy for it).
>>>>> Yes we should allow for systemd to specify a label, but the label needs
>>>>> to be transitioned from the user domain.
>>>>>
>>>>> For example if I login as unconfined_t and want to run a service as
>>>>> httpd_t, then I need to be able to transition from
>>>>> unconfined_t to httpd_t.  As long as systemd-user is running as the user
>>>>> domain, then SElinux will control this.
>>>> That doesn't seem useful ;) Why would a user by able run anything as 
>>>> httpd_t?
>>>> The way I understand Michal's question is: in what ways specifying a
>>>> context for systemd --user that is different than current 
>>>> unconfined_u:unconfined_r:unconfined_t
>>>> would be actually useful? What general rules for transitions could be 
>>>> provided?
>> That was just an example.  The idea would be to allow  a user to build a
>> service that he wants to run at boot time or login time from
>> his homedir. But wants to lock it down and at least isolate it from his
>> homedir.  Running it with a container type for example.  We are
>> working on non-root service containers.
> I thing doing this is very valuable, but it doesn't need selinux or
> any other form of MAC, and what I'm saying is that I'd like to see
> this type of isolation be implemented in a way that doesn't require
> selinux or any other LSM.
>
>>> My intuition is that, especially for non-root processes, using the
>>> various sandboxing features available without MAC or any privileged
>>> configuration (ProtectXYZ, namespaces, seccomp, etc) is already a good
>>> deal easier to work with, more flexible, and less needing of
>>> centralized policy than SELinux.  Maybe Fedora should focus on that
>>> type of isolation for systemd user instances rather than trying to
>>> make SELinux work for them.
>> I don't see seccomp as being a good deal easier, but the point being we
>> want to take
>> advantage of all isolation tecnigues available in Linux.  Dropping Caps,
>> Read Only file system
>> labeled file isolation, dropped syscalls ...
> Everything you've mentioned with the sole exception of labeled files
> is something that naturally offers its full power and configurability
> directly to the process doing to isolation without needing any
> systemwide configuration.  So a user systemd can isolate a user daemon
> by itself without needing to ship privileged policy or to get a
> privileged process to label files on the user's behalf.
No privilege required for SELinux either.  I just want types that the
user can access and set labels.
SELinux requires NO privs at all.  Users can set types on files in their
home directory and can
switch to other types.  runcom is a perfect example. 

I don't want systemd --user to run as anything but the users UID and as
the users context.  I just want
a way to be able to specify in a unit file that I want this process to
run with this label type and this MCS
label. 


> --Andy
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: User instances of systemd and SELinux

[Daniel J Walsh]

On 08/10/2016 03:42 PM, Andrew Lutomirski wrote:
> On Wed, Aug 10, 2016 at 12:26 PM, Zbigniew Jędrzejewski-Szmek
> <zbys...@in.waw.pl> wrote:
>> On Tue, Aug 09, 2016 at 01:32:10PM -0400, Daniel J Walsh wrote:
>>>
>>> On 08/09/2016 10:24 AM, Michal Sekletar wrote:
>>>> Hi all,
>>>>
>>>> Most of you are probably aware that systemd except running as PID 1
>>>> also runs inside user sessions. This allow users to define their own
>>>> "user services" and start up various scripts and background processes
>>>> right after logging in.
>>>>
>>>> In default targeted policy PID 1 runs with init_t SELinux label and
>>>> --user instances of systemd are not confined by SELinux, i.e. running
>>>> with unconfined_t.
>>>>
>>>> During Flock I got asked whether we can change that and run systemd
>>>> --user instances in some confined domain. Fixing this on systemd side
>>>> should be trivial, i.e. we would have to add SELinuxContext= option
>>>> with appropriate value to /usr/lib/systemd/system/user@.service (unit
>>>> file used for spawning user instances of systemd).
>>>>
>>>> I am writing this email with a hope that we can discuss if above
>>>> proposal even makes sense (what are possible gains from system
>>>> security perspective) and if yes what is appropriate SELinux label to
>>>> use (I guess we would need new one and define policy for it).
>>> Yes we should allow for systemd to specify a label, but the label needs
>>> to be transitioned from the user domain.
>>>
>>> For example if I login as unconfined_t and want to run a service as
>>> httpd_t, then I need to be able to transition from
>>> unconfined_t to httpd_t.  As long as systemd-user is running as the user
>>> domain, then SElinux will control this.
>> That doesn't seem useful ;) Why would a user by able run anything as httpd_t?
>> The way I understand Michal's question is: in what ways specifying a
>> context for systemd --user that is different than current 
>> unconfined_u:unconfined_r:unconfined_t
>> would be actually useful? What general rules for transitions could be 
>> provided?
That was just an example.  The idea would be to allow  a user to build a
service that he wants to run at boot time or login time from
his homedir. But wants to lock it down and at least isolate it from his
homedir.  Running it with a container type for example.  We are
working on non-root service containers.
> My intuition is that, especially for non-root processes, using the
> various sandboxing features available without MAC or any privileged
> configuration (ProtectXYZ, namespaces, seccomp, etc) is already a good
> deal easier to work with, more flexible, and less needing of
> centralized policy than SELinux.  Maybe Fedora should focus on that
> type of isolation for systemd user instances rather than trying to
> make SELinux work for them.
I don't see seccomp as being a good deal easier, but the point being we
want to take
advantage of all isolation tecnigues available in Linux.  Dropping Caps,
Read Only file system
labeled file isolation, dropped syscalls ...
> --Andy
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: User instances of systemd and SELinux

[Daniel J Walsh]

On 08/09/2016 10:24 AM, Michal Sekletar wrote:
> Hi all,
>
> Most of you are probably aware that systemd except running as PID 1
> also runs inside user sessions. This allow users to define their own
> "user services" and start up various scripts and background processes
> right after logging in.
>
> In default targeted policy PID 1 runs with init_t SELinux label and
> --user instances of systemd are not confined by SELinux, i.e. running
> with unconfined_t.
>
> During Flock I got asked whether we can change that and run systemd
> --user instances in some confined domain. Fixing this on systemd side
> should be trivial, i.e. we would have to add SELinuxContext= option
> with appropriate value to /usr/lib/systemd/system/user@.service (unit
> file used for spawning user instances of systemd).
>
> I am writing this email with a hope that we can discuss if above
> proposal even makes sense (what are possible gains from system
> security perspective) and if yes what is appropriate SELinux label to
> use (I guess we would need new one and define policy for it).
>
> Michal
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Yes we should allow for systemd to specify a label, but the label needs
to be transitioned from the user domain.

For example if I login as unconfined_t and want to run a service as
httpd_t, then I need to be able to transition from
unconfined_t to httpd_t.  As long as systemd-user is running as the user
domain, then SElinux will control this.

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: Fedora Docker Layered Image Guidelines

[Daniel J Walsh]

Hopefully we are looking at getting docker-squash/docker-scripts 
involved in squashing images


built from the service.  At least optionally if not required.

docker-squash should allow you to squash everything in the Dockerfile 
back to the from line.


from=$(awk '/^FROM/{print $2}' ~/Dockerfile)

docker-squash -f ${from} -t SQUASHEDTAGNAME --output-path /images 
UNSQUASHEDIMAGENAME


On 04/28/2016 06:52 PM, Adam Miller wrote:

Hello all,
 We're wrapping up the first phase of the Fedora Docker Layered Image
Build Service[0] and the time has come to start thinking about what we as a
Project need to do to formalize what it means to be shipping Docker Layered
Images once we are capable of building and distributing them.

 These are effectively going to compliment their RPM counterpart at least
in the beginning since we as a Project have never shipped any build artifact
other than RPMs as a part of the distribution before. We can grow organically
from there if we want to extend beyond the initial offering for Docker
Layered Images but I thought following RPM as a guide in the beginning was a
reasonable goal to achieve. Some areas that seemed pertinant right off the
bat are below, for each of them I have alread created a Draft document that
I would appreciate feedback on.

 Docker Layered Image "packaging" Guidelines [1]

 Package Review Process with a Docker Containers section [2]

 Docker Layered Images Naming Guildelines [3]

The Fedora Cloud SIG has done a first-pass review of these (thanks Cloud
SIG!) so hopefully there's a certainly level of sanity to them but I'm
absolutely open to new ideas and extending the content with more coverage.

Another point to note is that we need to determine how this should be handled
in BZ components for bug reporting as well as for filing review requests.

Something else what was brought up when I originally submitted these ideas to
FESCo[4] (aside from the fact that this should go to devel list first) was
that it is probably a good idea to establish a Container-centric Guidelines
Committee much in the way there is a Fedora Packaging Committee (which focuses
on RPMs). My question to everyone on that topic is, would there be enough
interest to establish such a committee?

As a side note and just a matter of opinion but I think the idea of forming
a Committee to help shepherd these new types of deliverables through Fedora
will help to enable aspects of Fedora Modularization[5] which ultimately will
be good for the whole of the Fedora Project.

I look forward to questions and feedback.

Thank you,
-AdamM


[0] - https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
[1] - https://fedoraproject.org/wiki/PackagingDrafts/Containers
[2] - 
https://fedoraproject.org/wiki/PackagingDrafts/Package_Review_Process_with_Containers
[3] - 
https://fedoraproject.org/wiki/Draft/Packaging:DockerLayeredImageNamingGuidelines
[4] - https://fedorahosted.org/fesco/ticket/1573
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: packaging suid files

[Daniel J Walsh]

No most likely the suid file should be fine with SELInux.  Only a 
confined user would

be prevented from using it.

On 04/20/2016 07:12 AM, Dave Love wrote:

I have a package to submit that has an suid binary.  The packaging
guidelines say in that case you must

%global _hardened_build 1

and it turns on PIE/PIC.  However, it doesn't do so on el6, at least.
Should flags be added by hand and, if so, exactly which?

Also, does an suid binary require something to be done for selinux?  (I
know embarrassingly little about it, mainly working on HPC systems, for
which the instructions generally and unfortunately start with "turn off
selinx".)
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: HEADS UP: systemd package split

[Daniel J Walsh]

On 03/05/2016 03:09 PM, Haïkel wrote:

2016-03-04 23:36 GMT+01:00 Zbigniew Jędrzejewski-Szmek :

Hi,

I finally pushed the split of the systemd package to Rawhide and F24 today
[https://fedoraproject.org/w/index.php?title=Changes/systemd_package_split].
If you upgrade with dnf you should see something like this:
Installing:
  systemd-container  x86_64 229-5.fc23@commandline 353 k
  replacing  systemd.x86_64 222-13.fc23
  systemd-udev   x86_64 229-5.fc23@commandline 1.2 M
  replacing  systemd.x86_64 222-13.fc23
Upgrading:
  systemdx86_64 229-5.fc23@commandline 5.1 M
  systemd-libs   x86_64 229-5.fc23@commandline 452 k
  ...

(systemd-udev provides udevd and hardware support, systemd-container provides
machinectl and other tools to manager containers and VMs.)

Comps 'core' group includes systemd-udev as mandatory and systemd-container
as optional, so they should be present in new installs.
Please check that you have systemd-udev package installed after an upgrade.
If you are building containers, things should be functional without either
of those new packages.
Otherwise, please holler on the bugzilla or here.

Zbyszek


Great news!
Thank you for keeping us up to date;)



--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


Does this mean we can install systemd into a base container without 
systemd-udev?

And without systemd-container?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Minimizing the fedora docker base image footprint

[Daniel J Walsh]

On Mon, 2016-02-22 at 11:26 -0500, Bill Nottingham wrote:
> Courtney Pacheco (cpach...@redhat.com) said: 
> > 
> > Hi everyone,
> > 
> > I've spent some time trying to minimize the footprint of the Fedora
> > docker
> > base image. Overall, I managed to reduce its size by 39.9%.
> > 
> > A summary of the work I did can be found here:
> > https://gist.github.com/iamcourtney/1a4af7c4289014f57080
> > 
> > If you're interested, you can find a more detailed version of the
> > above work
> > here: https://gist.github.com/iamcourtney/b8709ed897b7ecc9ac0f
> May be a dumb question...
> 
> If we're excluding DNF, RPM, etc. for a slimmer base image during
> runtime,
> how are we describing the best practices for build? Is the intention
> that
> you should always be pulling in a separate tool container to assist
> with
> the build process?
> 
> Bill
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.
> org
> 
> 

I have no problem removing dnf, but removing rpm is going to far.  For
now we still need rpm for looking at the contents of a container.
 While external rpm would probably work, I don't think we are redy for
this, nor is the benefit enough.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ship Fedora with /etc/{subuid|subgid}

[Daniel J Walsh]

Strange package to include those.

This also looks like an interesting package.

http://manpages.ubuntu.com/manpages/vivid/man1/newuidmap.1.html

On 02/17/2016 11:45 AM, Antonio Murdaca wrote:
>
> - Messaggio originale -
> | Da: "Antonio Murdaca" <amurd...@redhat.com>
> | A: devel@lists.fedoraproject.org
> | Cc: "Daniel J Walsh" <dwa...@redhat.com>, "Nalin Dahyabhai" 
> <na...@redhat.com>
> | Inviato: Mercoledì, 17 febbraio 2016 14:44:34
> | Oggetto: ship Fedora with /etc/{subuid|subgid}
> | 
> | Hello everyone,
> | 
> | TL;DR;
> | a fresh Fedora installation won't have /etc/subuid and /etc/subgid
> | Docker user namespace implementation require those files to be present -
> | otherwise it fails
> | 
> | Docker user ns relies on two files /etc/{subuid,subgid} to be on the rootfs
> | in order to
> | gather information about remapped root(s). AFAIK other distros ship those
> | files (empty by default IIRC).
>
> seems like "passwd" is providing those files on stock Ubuntu(s)
> http://manpages.ubuntu.com/manpages/wily/en/man5/subuid.5.html
>
> | The only exception is Fedora (as also stated in their official docs at [1]).
> | 
> | Is there any particular issue|reason Fedora doesn't ship those two files?
> | 
> | [1]
> | 
> https://github.com/docker/docker/blob/master/docs/reference/commandline/daemon.md#starting-the-daemon-with-user-namespaces-enabled
> | 
> | Thx,
> | Antonio (runcom) Murdaca
> | --
> | devel mailing list
> | devel@lists.fedoraproject.org
> | http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> |
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: System Python

[Daniel J Walsh]

On 02/08/2016 01:16 PM, Chris Murphy wrote:
> On Mon, Feb 8, 2016 at 10:47 AM, Stephen Gallagher  
> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 02/08/2016 12:45 PM, Mathieu Bridon wrote:
>>> On Mon, 2016-02-08 at 17:21 +0100, Petr Viktorin wrote:
 Part of the change is defining the exact subset. The idea is that it
 should be small, to keep cloud images small for apps that don't use
 Python themselves.
>>> Wouldn't it be a better goal to not have Python at all on Cloud images?
>>>
>> So... no dnf? That seems a little unlikely to yield a good long-term result.
> If Cloud becomes Atomic, it probably wouldn't have dnf. Current atomic
> builds don't. I'm not sure how far off the hybrid rpm install rpms in
> an rpm-ostree release is going to be.
>
That might be the goal, that anything in atomic would have to use
sysstem-python.  Would be a good start.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Easier %config management?

[Daniel J Walsh]

On 12/15/2015 09:32 PM, Colin Walters wrote:
> On Tue, Dec 15, 2015, at 06:43 PM, Japheth Cleaver wrote:
>>  
>> Perhaps RPM (or yum/dnf, via plugin) could write a duplicate copy of
>> all config files into a tree somewhere? (E.g., /usr/lib/config/ or
>> /usr/share/config/?)
>  
> I mentioned this above, but might as well repeat since it was missed;
> OSTree (as used by the existing Fedora Atomic Host) does this by
> default today in /usr/etc, so if one was adapting this change to the
> client-side system assembly tools like yum/dnf, I'd say it would make
> sense to follow the precedent.
>  
>  
>  
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
I think this makes sense as a first step to getting to the point where
you could reset your machine by removing /etc/ and /var.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora Docker Images containing fedora-updates-testing packages

[Daniel J Walsh]

Theoretically you should be able to build F21 and F22 containers and run
them on F20.  The only problem would be if
software within a container tried to use something that the F20 Kernel
did not support.

On 07/23/2015 11:11 AM, Jon Miller wrote:
 Matthew Miller writes:

 On Wed, Jul 22, 2015 at 03:19:41PM -0700, Jon Miller wrote:
 I tried with the fedora:21 container and it does not have the same
 problem. Would be nice, however, if someone could help push an update. 
 We were just discussing this, and there is a pretty strong consensus
 against pushing updates for EOL releases. Are you able to rebase to the
 F21 (or F22) image?
 I can live without an update and use F21 and/or F22 images, though I may also
 try to rebuild my own F20 container then. I've got several machines still
 using F20 and I have the software sync'ed to a Spacewalk server
 internally. Perhaps I'll go visit the Cloud working group's script for
 building a container from scratch and use my own channels. 

 Thanks,

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: SELinux policy store migration

[Daniel J Walsh]

Could all of this be done with links?  IE Could you install
selinux-policy into
/usr/share/selinux/TARGETED/base/*.pp
/usr/share/selinux/TARGETED/custom/*.pp

Then we reassemble these modules with custom modules in
/var/lib/selinux/TARGETED/ supplied by administrators?



On 06/15/2015 05:15 AM, Petr Lautrbach wrote:
 Dne 13.6.2015 v 19:07 Lennart Poettering napsal(a):
 On Fri, 12.06.15 19:00, Miroslav Grepl (mgr...@redhat.com) wrote:

 On 06/12/2015 12:17 PM, Lennart Poettering wrote:
 On Thu, 11.06.15 06:51, Jan Kurik (jku...@redhat.com) wrote:

 = Proposed System Wide Change: SELinux policy store migration =
 https://fedoraproject.org/wiki/Changes/SELinuxPolicyStoreMigration
 I cannot make sense of this with my limited selinux knowledge, could
 you please elaborate on this on the changes page for people like me
 who only have a superficial understanding of selinux?
 Yeap, we are working on it.

 Basically the binary policy file
 (/etc/selinux/targeted/policy/policy.29) loaded to kernel is built from
 SELinux policy modules. These modules are currently located in
 /etc/selinux/targeted/modules and we call it as a module store. This
 store is now moved to /var/lib/selinux/targeted/modules. This only
 affects tools like semanage, semodule which are used for a policy
 manipulation. So we are able to boot without /var also from SELinux
 point of view.
 Why /var and not /usr?

 If these module files are shipped with RPMs as vendor versions they
 belong in /usr, no?

 What makes this approproate for moving them to /var?

 Albeit modules are shipped with RPM, SELinux tools (semanage, semodule)
 work on this storage to make intended changes. When you enable or
 disable modules, when you install modules, when you do changes in
 SELinux users, logins and booleans, it's done in SELinux store.



 Petr



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

New Article on Future Docker Security.

[Daniel J Walsh]

http://opensource.com/business/15/3/docker-security-future
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Is systemd within a Docker container still recommended?

[Daniel J Walsh]

On 03/01/2015 10:41 PM, Michael DePaulo wrote:
 Hi,

 I am developing a Dockerfile for X2Go. I intend to submit a PR to
 fedora-Dockerfiles within a week.

 https://github.com/mikedep333/Fedora-Dockerfiles/tree/add-x2go

 (X2Go was already added in F20)
 https://fedoraproject.org/wiki/Changes/X2Go

 Example Dockerfile with systemd:
 https://github.com/fedora-cloud/Fedora-Dockerfiles/blob/master/systemd/apache/Dockerfile

 However, I would like to know if the Fedora project still recommends
 that I use systemd, or if I should resort to using supervisord or a
 shell script.

 I merely need to start sshd and x2gocleansessions. Both have systemd
 unit files, but can be run via an init script too.

 When I do try systemd, I am experiencing known issues with cgroups and
 with mounting /run, unless I run a privileged container. It has been a
 while since there were any comments on the CLOSED NOTABUG bz on these
 issues.
 https://bugzilla.redhat.com/show_bug.cgi?id=1033604

 -Mike
We are continuing to work on making running systemd within a container
better.
I am trying to get a /run on tmpfs patch to be acceptable upstream.  But
we still
have a problem with systemd requiring /sys/fs/cgroup to be mounted
inside the container
to run.  Which allows for an information leak.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Is systemd within a Docker container still recommended?

[Daniel J Walsh]

On 03/02/2015 10:03 AM, Mauricio Tavares wrote:
 On Mon, Mar 2, 2015 at 9:42 AM, Lennart Poettering mzerq...@0pointer.de 
 wrote:
 On Mon, 02.03.15 09:17, Daniel J Walsh (dwa...@redhat.com) wrote:

 On 03/01/2015 10:41 PM, Michael DePaulo wrote:
 Hi,

 I am developing a Dockerfile for X2Go. I intend to submit a PR to
 fedora-Dockerfiles within a week.

 https://github.com/mikedep333/Fedora-Dockerfiles/tree/add-x2go

 (X2Go was already added in F20)
 https://fedoraproject.org/wiki/Changes/X2Go

 Example Dockerfile with systemd:
 https://github.com/fedora-cloud/Fedora-Dockerfiles/blob/master/systemd/apache/Dockerfile

 However, I would like to know if the Fedora project still recommends
 that I use systemd, or if I should resort to using supervisord or a
 shell script.

 I merely need to start sshd and x2gocleansessions. Both have systemd
 unit files, but can be run via an init script too.

 When I do try systemd, I am experiencing known issues with cgroups and
 with mounting /run, unless I run a privileged container. It has been a
 while since there were any comments on the CLOSED NOTABUG bz on these
 issues.
 https://bugzilla.redhat.com/show_bug.cgi?id=1033604

 -Mike
 We are continuing to work on making running systemd within a container
 better.
 I am trying to get a /run on tmpfs patch to be acceptable upstream.  But
 we still
 have a problem with systemd requiring /sys/fs/cgroup to be mounted
 inside the container
 to run.  Which allows for an information leak.
 You'd have to get the kernel changed for that information leak to be
 fixed.

 That said, containers on Linux are not really about security, the
 whole thing has more holes than a swiss cheese. Maybe one day the
 security holes can be fixed, but as of now, it's simply not
 secure. And this information leak is certainly the least of your
 problems...

   What would then be the recommended solution if containers are insecure?
Well we are trying to fix this, but as Lennart says, there are many
holes in the strategy at this
point.  I am working on a presentation that talks about different levels
of security.  As soon
as you get to Virtualization you get less security.

I would say running each service on an individual machine is the most
secure.  Running Each Service
on a separate VM is the second most, especially if you are using
SELInux/Svirt for separation of your VM's.
Third level is running each Service in a different container, (Again you
want SELinux for some separation).
Fourth is each Service running on the host, (Wrapped with SELinux). 
Fifth setenforce 0.


 Lennart

 --
 Lennart Poettering, Red Hat
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: yum or dnf in the Fedora 22 Docker base image?

[Daniel J Walsh]

Not that I know of.
On 02/16/2015 09:50 AM, M. Edward (Ed) Borasky wrote:
 Thanks! Are there tracking bugs in Bugzilla I can subscribe to?

 On Mon, Feb 16, 2015 at 9:42 AM, Daniel J Walsh dwa...@redhat.com wrote:
 On 02/16/2015 12:31 PM, M. Edward (Ed) Borasky wrote:
 On Mon, Feb 16, 2015 at 5:19 AM, Daniel J Walsh dwa...@redhat.com wrote:

 I think the F22 and Rawhide (Is it F23 at this point), should both use dnf
 not yum.  We need to get more testing on dnf in containers.
 I'm ready to start testing F22 containers either way and would prefer
 dnf. What's the best process to get this rolling? Who owns the image -
 release engineering or Project Atomic? The reason I ask is that
 Project Atomic has their own mailing list and uses Trac, not the Red
 Hat Bugzilla, for issue tracking.

 Either way, my main upstream component (RStudio Server) may end up
 stuck with F21 - it doesn't link with the latest Boost right now and
 they only support CentOS and Debian/Ubuntu.
 Vaclav is handling this right now.  I don't see this as owned by
 ProjectAtomic.
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: yum or dnf in the Fedora 22 Docker base image?

[Daniel J Walsh]

On 02/16/2015 02:32 AM, Jan Zelený wrote:
 On 14. 2. 2015 at 22:28:53, M. Edward  Borasky wrote:
 Right now, the fedora:rawhide image on Docker Hub uses yum instead of
 dnf, as does the Fedora 21 release. Is there any plan to switch this
 release over to dnf?
 Not likely. Porting of the system components is being done in F22+. Even if 
 all the system components were ported, dnf as default is a Change proposed 
 for 
 F22. Doing this in F21 would not be safe for countless reasons.
I think the F22 and Rawhide (Is it F23 at this point), should both use dnf
not yum.  We need to get more testing on dnf in containers.
 I'm in the process of refactoring my remix - big pieces of it are
 going into Docker images. I'm wondering if it's worth porting the main
 workstation to dnf if the Docker pieces will still be on yum.
 You will need to deal with such situation anyway, unless you migrate your 
 containers to F22 (all at once) at some point in the future.

 Thanks
 Jan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Is it a SELinux policy problem ?

[Daniel J Walsh]

On 01/27/2015 05:11 PM, Casper wrote:
 Or is it a luajit problem ?

 Dear devs hello.
 I would like to determine if these AVC are caused by prosody, lua, or
 a wrong SELinux policy.

This avc (execmem) looks like it is allowed in Fedora
selinux-policy-3.13.1-105.fc21.src.rpm

Does prosody have a log file error.log?



 lancaster ~ # systemctl status prosody
 ● prosody.service - Prosody XMPP (Jabber) server
Loaded: loaded (/usr/lib/systemd/system/prosody.service; disabled)
  Active: inactive (dead)

 lancaster ~ # sestatus
 SELinux status: enabled
 SELinuxfs mount:/sys/fs/selinux
 SELinux root directory: /etc/selinux
 Loaded policy name: targeted
 Current mode:   enforcing
 Mode from config file:  enforcing
 Policy MLS status:  enabled
 Policy deny_unknown status: allowed
 Max kernel policy version:  29

 lancaster ~ # rpm -q prosody luajit
 prosody-0.9.4-4.fc21.x86_64
 luajit-2.0.3-3.fc21.x86_64


 systemd start:
 janv. 27 19:28:03 lancaster prosodyctl[21208]: PANIC: unprotected
 error in call to Lua API (runtime code generation failed, restricted
 kernel?)
 janv. 27 19:28:04 lancaster prosodyctl[21208]: PANIC: unprotected
 error in call to Lua API (runtime code generation failed, restricted
 kernel?)
 janv. 27 19:28:04 lancaster systemd[1]: prosody.service: control
 process exited, code=killed status=11
 janv. 27 19:28:04 lancaster systemd[1]: Failed to start Prosody XMPP
 (Jabber) server.
 janv. 27 19:28:04 lancaster systemd[1]: Unit prosody.service entered
 failed state.
 janv. 27 19:28:04 lancaster systemd[1]: prosody.service failed.

 kernel log:
 janv. 27 19:28:03 lancaster prosodyctl[21208]: PANIC: unprotected
 error in call to Lua API (runtime code generation failed, restricted
 kernel?)
 janv. 27 19:28:03 lancaster kernel: luajit[21209]: segfault at bcefddd
 ip 0bcefddd sp 7fff98c8cf00 error 15
 janv. 27 19:28:04 lancaster prosodyctl[21208]: PANIC: unprotected
 error in call to Lua API (runtime code generation failed, restricted
 kernel?)
 janv. 27 19:28:04 lancaster kernel: luajit[21208]: segfault at bcefe33
 ip 0bcefe33 sp 7fffe6d4a6b0 error 15
 janv. 27 19:28:04 lancaster systemd[1]: prosody.service: control
 process exited, code=killed status=11
 janv. 27 19:28:04 lancaster systemd[1]: Failed to start Prosody XMPP
 (Jabber) server.
 janv. 27 19:28:04 lancaster systemd[1]: Unit prosody.service entered
 failed state.
 janv. 27 19:28:04 lancaster systemd[1]: prosody.service failed.
 janv. 27 19:28:05 lancaster dbus[904]: [system] Successfully activated
 service 'org.fedoraproject.Setroubleshootd'
 janv. 27 19:28:14 lancaster setroubleshoot[21211]: Plugin Exception
 restorecon_source
 janv. 27 19:28:14 lancaster setroubleshoot[21211]: SELinux is
 preventing /usr/bin/luajit-2.0.3 from read access on the file
 /var/log/prosody/debug.log. For complete SELinux messages. run sealert
 -l 4598d861-a393-472b-9dda-2c1c3b069fd4
 janv. 27 19:28:14 lancaster setroubleshoot[21211]: SELinux is
 preventing /usr/bin/luajit-2.0.3 from read access on the file
 /var/log/prosody/info.log. For complete SELinux messages. run sealert
 -l 4598d861-a393-472b-9dda-2c1c3b069fd4
 janv. 27 19:28:14 lancaster setroubleshoot[21211]: SELinux is
 preventing /usr/bin/luajit-2.0.3 from read access on the file
 /var/log/prosody/error.log. For complete SELinux messages. run sealert
 -l 4598d861-a393-472b-9dda-2c1c3b069fd4
 janv. 27 19:28:15 lancaster setroubleshoot[21211]: SELinux is
 preventing /usr/bin/luajit-2.0.3 from using the execmem access on a
 process. For complete SELinux messages. run sealert -l
 e0b419ae-9eb4-45ec-9d8e-0ef19df4f5cb
 janv. 27 19:28:15 lancaster setroubleshoot[21211]: SELinux is
 preventing /usr/bin/luajit-2.0.3 from using the execmem access on a
 process. For complete SELinux messages. run sealert -l
 e0b419ae-9eb4-45ec-9d8e-0ef19df4f5cb


 lancaster ~ # sealert -l 4598d861-a393-472b-9dda-2c1c3b069fd4
 SELinux is preventing /usr/bin/luajit-2.0.3 from read access on the
 file /var/log/prosody/error.log.

 *  Plugin catchall (100. confidence) suggests
**

 If vous pensez que luajit-2.0.3 devrait être autorisé à accéder read
 sur error.log file par défaut.
 Then vous devriez rapporter ceci en tant qu'anomalie.
 Vous pouvez générer un module de stratégie local pour autoriser cet
 accès.
 Do
 autoriser cet accès pour le moment en exécutant :
 # grep luajit /var/log/audit/audit.log | audit2allow -M mypol
 # semodule -i mypol.pp


 Additional Information:
 Source Contextsystem_u:system_r:prosody_t:s0
 Target Contextsystem_u:object_r:var_log_t:s0
 Target Objects/var/log/prosody/error.log [ file ]
 Sourceluajit
 Source Path   /usr/bin/luajit-2.0.3
 Port  Unknown
 Host  lancaster
 Source RPM Packages   

Re: Flash plugin 0-day vulnerability in the wild

[Daniel J Walsh]

On 01/23/2015 10:25 AM, poma wrote:
 On 23.01.2015 15:12, Kevin Fenzi wrote:
 On Fri, 23 Jan 2015 12:44:23 +0100
 poma pomidorabelis...@gmail.com wrote:

 On 23.01.2015 10:51, Martin Stransky wrote:
 Folk,

 There's a live 0-day flash vulnerability which is not fixed yet
 [1][2]. If you use flash plugin I recommend you to enable the
 click-to-play mode for it.
 Are we covered with
 $ rpm -q flash-plugin
 flash-plugin-11.2.202.438-release.x86_64
 ?

 Ref.
 http://helpx.adobe.com/security.html
 No. 

 http://helpx.adobe.com/security/products/flash-player/apsa15-01.html

 kevin



 Thanks for reference.

 Until this is resolved, is this a valid way:
 $ sandbox -X -T tmp -t sandbox_web_t firefox
 to cover this security issue, or can we isolate only libflashplayer.so,
 not the entire browser.

 Daniel, can you comment.


libflashplayer.so runs within the Mozilla-plugin I believe. If so it
would be confined
if you have not turned on the unconfined_mozilla_plugin_transition boolean.

If this is the case we are somewhat protected, and of course  you run
with setenforce 1.

sandbox -X will also add more protection.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default

[Daniel J Walsh]

On 01/20/2015 07:29 AM, Lennart Poettering wrote:
 On Tue, 20.01.15 12:53, Jaroslav Reznik (jrez...@redhat.com) wrote:

 = Proposed System Wide Change: Enable Polyinstantiated /tmp and /var/tmp 
 directories by default =
 https://fedoraproject.org/wiki/Changes/Polyinstantiated_tmp_by_Default

 Change owner(s): Huzaifa Sidhpurwala huzai...@redhat.com

 Polyinstantiation of temperary directories is a pro-active security measure, 
 which reduced chances of attacks caused due to the /tmp and /var/tmp 
 directories being world-writable. These include flaws caused by predictive 
 temp. file names, race conditions due to symbolic links etc. 

 == Detailed Description ==
 The basic idea is to provide better security to Fedora installs. Though 
 Polyinstantiated /tmp has worked since Fedora 19, its not a single step 
 process to configure it. Secondly people don't really understand its 
 benefits. 
 Because of this having it on by default makes more sense. It is completely 
 transparent to the user, they wont even realize that it has been enabled.

 The Red Hat Product Security Team assigns CWE ids to severe flaws (CVSSv2  
 7). 
 Here is a list of severe flaws caused by insecure tmp files [1].

 == Scope ==
 * Proposal owners: No work required to be done by proposal owner.

 * Other developers:
 ** Add /tmp-inst and /var/tmp/tmp-inst to filesystem. (packagename: 
 filesystem)
 ** Enable namespaces in /etc/security/namespace.conf (packagename: PAM)
 ** Enable proper selinux context and polyinstantiation_enabled boolean to be 
 set (packagename: selinux-policy-targeted or selinux-policy)
 Well, /tmp is used by X11 among other for IPC across user
 boundaries. If you give each other their private instance of it, they
 cannot use this for communication anymore. You are breaking X11 this
 way.
I believe X11 attempts to use the abstract namespace @/tmp/.X11-unix  
first, at least it used to.

 Moreover, if you want to give each user a private instance of /tmp you
 have to run that user in a private mount namespace and disable
 propagation from that namespace into the host for the / directory for
 this. (After all the /tmp over-mounting shall be private to the user,
 and not propagate to the rest of the system.)  This of course means
 that if the user later-on invokes /bin/mount or /bin/umount on any
 subdir of / the commands have will have zero effect for the rest of
 the system. You pretty much brek mounting/umounting for normal
 users. If you do this, pretty much every admin will hate you deeply.
There is a way to setup sudo and su to switch back the the hosts /tmp,
but I agree this
would cause confusion.  For example a user copies something to /tmp and
then tells the
admin or another user to look at it, and the admin can not see it.
 Also, introducing /tmp-inst sounds really wrong to me, what's the
 point of that? systemd's PrivateTmp= works by mounting /tmp over with
 a subdir of /tmp, so that things stay on the same file system. Why
 introduce a new directory?
I agree this should be a subdir of the hosts /tmp.
 How do you intend for the new /tmp instance to be life-cycled? When is
 the private /tmp instance removed? On logout? Tracking a user
 session's lifecycle is not easy, as the user might have processes
 running that are not attached to any session, and you shouldn't remove
 the private /tmp before those processes are dead too.

 To me this sounds very much not thought to the end. 

 We thought a couple of times in adding an option for this to
 systemd/logind, after all, we have the namespacing code in systemd
 anyway, and we can at least track the sessions through logind very
 precisely. However, X11 and the mount propagation breakage are real
 blockers to make this useful in the general case.

 This idea can only fly for very special systems where the propagation
 is irrelevant. It's not compatible with admin workflows, at all.

 Lennart

I agree.  Although it would be nice is there was a simple command to
turn this on, and then we
could have users actually try it out.  It is very nice for multi user
systems, where the users
are not really trustworthy.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: docker 1.4.0 available, fixes multiple CVEs - testing/karma needed

[Daniel J Walsh]

On 12/12/2014 03:34 PM, Lokesh Mandvekar wrote:
 On Fri, Dec 12, 2014 at 10:14:50AM -0800, M. Edward (Ed) Borasky wrote:
 Working here on F21 - karma logged!
 Thanks. Btw, could you also check if things work fine after restarting
 docker.service (if not tested already)? I see database locked errors after a
 restart on rawhide :\

 On Fri, Dec 12, 2014 at 7:57 AM, Lokesh Mandvekar
 l...@fedoraproject.org wrote:
 I've updated docker to 1.4.0 for fedora and fedora epel. This release fixes:
 CVE-2014-9357: https://access.redhat.com/security/cve/CVE-2014-9357
 CVE-2014-9358: https://access.redhat.com/security/cve/CVE-2014-9358
 CVE-2014-9356: https://access.redhat.com/security/cve/CVE-2014-9356

 It'd be great if people could test these and add karma/comments:
 https://admin.fedoraproject.org/updates/docker-io-1.4.0-1.fc21
 https://admin.fedoraproject.org/updates/docker-io-1.4.0-1.fc20
 https://admin.fedoraproject.org/updates/docker-io-1.4.0-1.fc19
 https://admin.fedoraproject.org/updates/docker-io-1.4.0-1.el6

 Thanks!
 --
 Lokesh
 Freenode, OFTC: lsm5
 GPG: 0xC7C3A0DD

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


 -- 
 Twitter: http://twitter.com/znmeb; OSJourno: Robust Power Tools for
 Digital Journalists https://osjourno.com

 Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday.
 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


 docker in Rawhide is busted.

According to docker there is a problem with their sqlite go bindings and
golang-1.4.

https://bugzilla.redhat.com/show_bug.cgi?id=1169334

The following temporarily works for me when this situation happens.

rm -f /var/lib/docker/linkgraph.db; systemctl restart docker

Works for me. Although you might need to run this command again when the 
database gets locked up.



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Allow internet/network access based on binary -- ask user for permission if a binary wants to connect to the internet

[Daniel J Walsh]

You can do this with SELinux and confined users somewhat.

YOU basically could setup a user as xguest with no network access and
then write
policy to transition to certain domains that can use the internet.  No
ability to prompt the user
though.

This will get you most of the way you want to go, but somethings can be
tricky.

Also lots of apps contact the network just by calling getpw* calls, if
you have certain settings in nsswitch.


On 12/09/2014 06:16 AM, Bastien Nocera wrote:

 - Original Message -
 I only want certain binaries to be allowed network access.

 For example, I want to allow the below binaries access to the internet:

 /usr/lib64/firefox/firefox
 /usr/lib/virtualbox/VirtualBox
 /bin/yum (it seems to be done via python like /usr/bin/python /bin/yum
 update -- so here obviously python is allowed network access only for
 yum ('the binary'). This rule should not give python network access
 for any other binaries/.py scripts etc.)

 I want no other binary to be able to access the network.
 It's not implementable, because you have no way to know that the
 binary trying to access the network is what it says it is.

 For now, at least. We'll certainly get something like that when
 application sandboxing is implemented and deployed.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

I want to make Ryan Hallisey a co-maintainer of policycoreutils.

[Daniel J Walsh]

He is not currently in the packager list.  But he does not have a
package that needs to be added to Fedora.  He is just making changes to
policycoreutils?

What is the procedure to get him on the packager list for this package.

Dan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Running docker in a mock chroot

[Daniel J Walsh]

On 11/05/2014 05:45 PM, Dridi Boukelmoune wrote:
 Hi,

 I haven't really tried, I only wanted to look at fig 1.0 currently in
 f21 updates-testing. So I --shell'ed inside my fedora-21-x86_64
 mock chroot after installing fig, and tried to start a docker daemon
 in the background but it failed.

# docker -d -H unix:///var/run/docker.sock 
2014/11/05 23:08:33 docker daemon: 1.3.0 c78088f/1.3.0; execdriver:
native; graphdriver:
[45f3a6fd] +job serveapi(unix:///var/run/docker.sock)
[error] attach_loopback.go:42 There are no more loopback devices available.
2014/11/05 23:08:33 loopback mounting failed

 If I need to use a VM, I will (any news for vagrant?) but I was
 wondering whether this was actually possible. I haven't looked in
 detail at how mock creates the chroots, and don't have time to dig
 at all these days.

 I was just wondering whether it was actually possible to run docker
 in a chroot, especially one built with mock!

 Cheers,
 Dridi
Probably missing /dev/loop* within mock chroot.  Otherthen this it
should probably work.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Time to start blogging on all of the new Security features in Fedora 21

[Daniel J Walsh]

If you have one, please send it to me with some explanation of what it
is and why it is important.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Anyone know how to get rsyslog to not use journald but to listen on /dev/log again.

[Daniel J Walsh]

We need this for running rsyslog within a docker container where
systemd/journald might not be running.

https://bugzilla.redhat.com/show_bug.cgi?id=1139734
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Systemd boot issue

[Daniel J Walsh]

Did you try to boot with enforcing=0?

To see if it is an SELinux issue?
On 09/09/2014 09:46 AM, P J P wrote:
 Hello,

 I've been trying to boot into kernel-3.16.0 on a F19 machine. But it just 
 stops after saying

 ..
 [OK] Reached target Initrd Default target

 System is not hung, but there is no activity/progress either. I did search 
 about it, some say it's because of SELinux. But other kernels do boot with 
 SELINUX=enforcing on my machine, so I'm not sure. I asked on IRC channels, 
 but no fix in sight yet.

 Is it a familiar issue to anyone? Is there a way to debug what Systemd is 
 doing after printing above message??

 Thank you.
 ---
 Regards
-Prasad
 http://feedmug.com

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd dependencies

[Daniel J Walsh]

On 08/26/2014 08:23 AM, Lennart Poettering wrote:
 On Tue, 26.08.14 14:18, Vít Ondruch (vondr...@redhat.com) wrote:

 Recently I have noticed that systemd package dependency is creeping into
 some packages where it is not necessary. subversion [1] or rsync [2] are
 good examples. Please consider moving daemon parts into independent
 subpackages. When I install rsync/subversion, I am typically interested
 just in client side.

 Just to be clear, systemd-libs is in minimal build root already, so I am
 not complaining about systemd-libs package, but about systemd package.
 What's the rationale here? I mean, we have so many dependencies, if you
 want to minimize them, you have a lng way to go...
 Someone has to start somewhere. It is annoying to install several
 packages, when you expect that only one should be installed. And by
 coincidence, I met several of systemd dependencies during short period
 of time.
 What I am not getting: what's the point? I mean, systemd is not exactly
 an optional package in Fedora.

 You are asking people to split their packages in two, but what's the
 real reason for that? If the systemd package isn't optional anyway, why
 is this the dep you start with and asking people to complicate things
 for?

 Lennart

Well it is optional in docker container images.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: fakesystemd package breaking builds

[Daniel J Walsh]

On 08/27/2014 03:15 PM, Lennart Poettering wrote:
 On Wed, 27.08.14 21:00, Václav Pavlín (vpav...@redhat.com) wrote:

 I also offered to split out the hwdb in Brno, if you remember. If this
 is about the hwdb, then let's just do that...
 Talk to Michal Sekletar about it then - he is working on something
 we call systemd-container internally. We need systemd running in
 Docker container. I don't like to have needless stuff in images but
 if the result is just drop the hwdb then I am fine with that.
 As discussed in Brno, not liking to have needless stuff around alone
 is really not a convincing reason. 

 I mean, you could make the case for the size of things, but afaics this
 doesn't hold any water here... kmod is a 150K dep, and the other stuff,
 is that any bigger? For 150K we shouldn't complicate things this much...

 You could also make the case for the dependencies, but this is kind the
 same as the size argument...

 And you could make the case for security, but that's really wrong too,
 since recent systemd versions have exactly zero suid binaries, and if
 you don't run the daemons, then you have exactly zero ways to raise your
 priviliges. And just having dead code lying around is not really an
 issue. I mean, if you managed to exploit something and smuggled in some
 code, then you smuggled in some code, why would make it any difference
 if there's dead code lying around or not in the container?

 But regarding kmod/devicemapper, can we please get some stats about how
 big this individually are, and how much is saved by this? kmod at least
 is 150K or so only. Is there really any value in doing this weird stuff
 for a fricking 150K?! Fedora has no bigger fishes to fry?
 I'll prepare stats for you tomorrow.
 The systemd-container or fakesystemd stuff sounds awfully adhoc. Can we
 please always discuss this first, and see if we can find a different
 solution? We don't need three different solutions, if one works
 too...
 We've talked about this on Flock - it's not only about disk space
 but also about security reasons (CC'ing Dan Walsh). My goal was not
 Dan, can you elaborate what the rationale for this is?
It is not about Security escalation is is about the need to update a
container image if a CVE happens on any of the packages installed. 
Basically we want to keep the turn on images as small as possible.  If
systemd, kmod, udev ... have a
CVE and they are not used within an image, then we would still need to
update the image because it  containers Vulnerable code, or
potentially vulnerable code.  Fakesystemd was developed for RHEL/Centos
images to help minimize the CVE footprint.  This was discussed on on
this fpc request.  https://fedorahosted.org/fpc/ticket/425.  I actually
did not want fakesystemd to go into Fedora for exactly the fear of it
screwing up builds.  I like the idea of systemd-container, or some other
minimal systemd environment which understands and works well within
container, and am trying to get pull requests into docker to allow
systemd to work well.

https://github.com/docker/docker/pull/7685
https://github.com/docker/docker/pull/7685

If we got a good version of systemd-container, (Or systemd) which did
not suck in other requirements an stopped other random rpm sucking in
stuff not needed in container, I would be all for dropping fakesystemd.




 to have needless junk in base image - if we are not going to use
 systemd to manage services there, why should it be there with all
 it's dependencies?
 This sounds awfully like a just because! reason... 

 Lennart


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: fakesystemd package breaking builds

[Daniel J Walsh]

On 08/28/2014 02:10 PM, Lennart Poettering wrote:
 On Thu, 28.08.14 07:24, Daniel J Walsh (dwa...@redhat.com) wrote:

 But regarding kmod/devicemapper, can we please get some stats about how
 big this individually are, and how much is saved by this? kmod at least
 is 150K or so only. Is there really any value in doing this weird stuff
 for a fricking 150K?! Fedora has no bigger fishes to fry?
 I'll prepare stats for you tomorrow.
 The systemd-container or fakesystemd stuff sounds awfully adhoc. Can we
 please always discuss this first, and see if we can find a different
 solution? We don't need three different solutions, if one works
 too...
 We've talked about this on Flock - it's not only about disk space
 but also about security reasons (CC'ing Dan Walsh). My goal was not
 Dan, can you elaborate what the rationale for this is?
 It is not about Security escalation is is about the need to update a
 container image if a CVE happens on any of the packages installed.
 Basically we want to keep the turn on images as small as possible.  If
 systemd, kmod, udev ... have a CVE and they are not used within an
 image, then we would still need to update the image because it
 containers Vulnerable code, or potentially vulnerable code.
 Is kmod/systemd really that bad with CVEs? I mean, if there was a large
 number of them, maybe that's something to think about, but I see 2 in
 2012, and 5 in 2013, and 0 in 2014... and those are not really the
 biggest issues in the world either, and certainly not in any way
 relevant if you just leave the files lying around
Well systemd just showed up in RHEL7, but as I said, the goal was to
limit the exposure. We were seeing systemd, kmod, udev and a few other
packages being sucked into a container that only needed httpd.   Every
package we add is a possibility of a CVE and forcing us to rebuild. 
 Fakesystemd was developed for RHEL/Centos images to help minimize the
 CVE footprint.  This was discussed on on this fpc request.
 https://fedorahosted.org/fpc/ticket/425.  I actually did not want
 fakesystemd to go into Fedora for exactly the fear of it screwing up
 builds.  I like the idea of systemd-container, or some other minimal
 systemd environment which understands and works well within container,
 and am trying to get pull requests into docker to allow systemd to
 work well.

 https://github.com/docker/docker/pull/7685
 https://github.com/docker/docker/pull/7685

 If we got a good version of systemd-container, (Or systemd) which did
 not suck in other requirements an stopped other random rpm sucking in
 stuff not needed in container, I would be all for dropping fakesystemd.
 I don't think there's any value in having a second version of systemd
 for containers. We repeatedly made clear that we care about containers
 upstream, and want that systemd works fine in containers out of the
 box. I want a unified OS that works in any way executed. But by
 inventing thigns like systemd-container or fakesystemd you just
 create two more crappy options that don't fully work. 

 Really, we should emphasize the value of our platform and its APIs, what
 you are doing there is just splitting up things into a crude variety of
 half-working, half-supported hacks. 

 Let's just see what changes we can make upstream and in the systemd rpm
 in fedora, don't start doing things like fakesystemd/systemd-container
 without first trying to do these things properly, upstream and in the
 default RPM.

 For example, let's split out the hwdb stuff in Fedora, and maybe some
 other things, and then you can drop that from the container images, but
 let's not wildly invent new hacks, without checking if there are better
 ways...

 Thank you very much,

 Lennart

I agree, as I said, I did not want any of these to show up in Fedora. 
My understanding of systemd-container (minimum) was just a rebuild of
systemd code to not require these additional packages.  If we can end up
with regular systemd running within a container and not requiring
kmod/udev and others that would be great.  Similarly not starting any
services/getty's/SySV Services. 

I agree that systemd should just work and I hope that happens going
forward with Fedora, so we can get it working in RHEL/Centos. 

In the end a multi-service container with httpd and mariadb should end
up with

systemd, journald, httpd* and mariadb* processes.  Nothing else and as
close to minimal packages as httpd and mariadb require to run.


Lennart, I think we are in agreement, and you understand our needs.  My
end goal is to make systemd the default multi-process container manager
and never ship cruft like supervisord.  I would also like to
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: BIND 9.10.1 beta with seccomp functionality

[Daniel J Walsh]

On 08/19/2014 11:20 AM, Tomasz Torcz wrote:
 On Tue, Aug 19, 2014 at 10:12:31AM -0500, Chris Adams wrote:
 Once upon a time, Tomas Hozza tho...@redhat.com said:
 That's where seccomp kicks in, it acts as a 2nd wall of defence. In case
 of a security hole being present in the server process, it goes further
 than a chroot, it prevents the attacker from making socket connections
 orexecuting his code, as his playing field is significantly reduced.
 There's very little he can do.”
 How is that different from an SELinux policy?  How is the additional
 resitrction handled (if it isn't SELinux, what mechanism is used to do
 the restriction)?
   The mechanism is called ”seccomp” – http://en.wikipedia.org/wiki/Seccomp

Seccomp can add additional security features to SELinux by eliminating
certain syscalls. 
I think using both SELinux and seccomp is a good idea.  Security in Depth.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Advice needed for packaging local SELinux policy

[Daniel J Walsh]

On 07/22/2014 01:42 PM, John Florian wrote:

 I have a locally maintained package for private use that among other
 things constrains proliferation of files in the following directory:

  

 # ls -lZd /var/lib/puppet/reports/

 drwxr-x---. puppet puppet system_u:object_r:puppet_var_lib_t:s0
 /var/lib/puppet/reports/

  

 My rpm contains a script that uses the tmpwatch tool to do some of the
 work and is called by cron and ran as the puppet user.  Using the
 standard selinux-policy-targeted, I get this AVC (and perhaps others):

  

 type=AVC msg=audit(1405588621.722:37432): avc:  denied  { read } for 
 pid=15113 comm=tmpwatch name=puppet dev=vda3 ino=260273
 scontext=system_u:system_r:tmpreaper_t:s0-s0:c0.c1023
 tcontext=system_u:object_r:puppet_var_lib_t:s0 tclass=dir

  

 I could change the job to run as root and am familiar with using
 audit2allow to make a local policy exception.  However, I’d like to
 resolve the issue via my rpm directly.  I’ve not been successful in
 finding any guidelines in how to best approach that task.  Do I
 package a bit of SEL policy or is there a way to have my script run
 with the puppet_var_lib_t context?

 --

 John Florian

  



Then you should add a custom policy to allow tmpreaper_t to manage
puppet_var_lib_t.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: runuser error in a docker container on rawhide

[Daniel J Walsh]

On 06/04/2014 02:27 PM, Robert Rati wrote:
 I'm trying to run some docker containers and it appears the runuser in
 rawhide isn't functional in the container:

 # runuser
 runuser: System error

 I can run runuser in a physical system running rawhide however.  These
 same images created off of F20 containers worked fine.

 Has anyone run into this?  Any ideas?

 Rob
I would guess it is potentially SELinux or /proc being readonly.

Put the machine into permissive mode to see if it is SELinux, (I doubt it).

You could check with a priv container to see if /proc or capabilities ar
ethe problem.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: runuser error in a docker container on rawhide

[Daniel J Walsh]

On 06/04/2014 03:17 PM, Robert Rati wrote:
 I checked the status of selinux in the container and it was disabled,
 so I don't think that's the problem.  I then tried re-launching the
 container in privileged mode (--privileged=true) and that didn't
 change anything.  The runuser command still prints System error if I
 use it to do anything, even nothing.

 Rob

 On 06/04/2014 02:37 PM, Daniel J Walsh wrote:

 On 06/04/2014 02:27 PM, Robert Rati wrote:
 I'm trying to run some docker containers and it appears the runuser in
 rawhide isn't functional in the container:

 # runuser
 runuser: System error

 I can run runuser in a physical system running rawhide however.  These
 same images created off of F20 containers worked fine.

 Has anyone run into this?  Any ideas?

 Rob
 I would guess it is potentially SELinux or /proc being readonly.

 Put the machine into permissive mode to see if it is SELinux, (I
 doubt it).

 You could check with a priv container to see if /proc or capabilities ar
 ethe problem.

Strange testing on rhel7 I see it working.

# docker run --rm -ti fedora runuser -u ftp id
uid=14(ftp) gid=50(ftp) groups=50(ftp)

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: runuser error in a docker container on rawhide

[Daniel J Walsh]

On 06/04/2014 04:03 PM, Robert Rati wrote:
 I'm pretty baffled.  I've successfully used runuser with F20 as the
 host and F20 in the container.  Something is different in rawhide.  I
 even tried downgrading util-linux in the container to the latest
 version in F20 and I still get the same error, which leads me to
 believe it's not util-linux at all.  The docker version in rawhide is
 newer (I'm running rawhide host and rawhide in the container), but I
 wouldn't expect that to affect runuser.

 Rob

It looks like /dev/log is not being created.

 On 06/04/2014 03:54 PM, Daniel J Walsh wrote:

 On 06/04/2014 03:17 PM, Robert Rati wrote:
 I checked the status of selinux in the container and it was disabled,
 so I don't think that's the problem.  I then tried re-launching the
 container in privileged mode (--privileged=true) and that didn't
 change anything.  The runuser command still prints System error if I
 use it to do anything, even nothing.

 Rob

 On 06/04/2014 02:37 PM, Daniel J Walsh wrote:

 On 06/04/2014 02:27 PM, Robert Rati wrote:
 I'm trying to run some docker containers and it appears the
 runuser in
 rawhide isn't functional in the container:

 # runuser
 runuser: System error

 I can run runuser in a physical system running rawhide however. 
 These
 same images created off of F20 containers worked fine.

 Has anyone run into this?  Any ideas?

 Rob
 I would guess it is potentially SELinux or /proc being readonly.

 Put the machine into permissive mode to see if it is SELinux, (I
 doubt it).

 You could check with a priv container to see if /proc or
 capabilities ar
 ethe problem.

 Strange testing on rhel7 I see it working.

 # docker run --rm -ti fedora runuser -u ftp id
 uid=14(ftp) gid=50(ftp) groups=50(ftp)


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: selinux issue with containers

[Daniel J Walsh]

On 05/28/2014 05:26 PM, Zbigniew Jędrzejewski-Szmek wrote:
 On Wed, May 28, 2014 at 01:52:23PM -0400, Daniel J Walsh wrote:
 On 05/28/2014 01:40 PM, Richard W.M. Jones wrote:
 On Wed, May 28, 2014 at 06:32:04PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
 On Wed, May 28, 2014 at 10:41:45AM -0400, Daniel J Walsh wrote:
 Yum -y update your entire computer and yum reinstall
 selinux-policy-targeted  Should fix the problem.
 Nope. No effect afaict. Any pointers how to debug this?
 Does it list any AVCs if you run this command shortly after the
 failure?
 No. I only have some unrelated SERVICE_START/SERVICE_STOP messages from 
 systemd-tmpfiles.

 # ausearch -ts recent -m avc
 no matches

 rpm -q selinux-policy-targeted
 selinux-policy-targeted-3.13.1-55.fc21.noarch

 I now tried with a new rawhide VM and I get identical
 results.

 This looks like the old bug we had with a bad selinux policy update.
 Yes.

 Zbyszek

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: selinux issue with containers

[Daniel J Walsh]

Yum -y update your entire computer and yum reinstall
selinux-policy-targeted  Should fix the problem.


On 05/27/2014 09:12 PM, Zbigniew Jędrzejewski-Szmek wrote:
 Hi,
 installing Fedora in containers fails strangely (see below). It seems to be
 selinux related, since booting with selinux=0 allows the installation to 
 continue.
 Strangely, just 'setenforce 0' does not work by itself. I feel like I'm 
 missing
 something obvious here.

 The host is rawhide with selinux-policy-3.13.1-54.fc21.noarch.

 # yum -y --releasever=20 --nogpg --installroot=$c --disablerepo='*' 
 --enablerepo=fedora install systemd passwd yum fedora-release vim-minimal sudo

 ..
 Running transaction check
 Running transaction test
 Transaction test succeeded
 Running transaction
   Installing : libgcc-4.9.0-5.fc21.x86_64 
1/25 
   Installing : fedora-release-rawhide-21-0.6.noarch   
2/25 
   Installing : fedora-release-21-0.6.noarch   
3/25 
   Installing : setup-2.9.0-1.fc21.noarch  
4/25 
   Installing : filesystem-3.2-24.fc21.x86_64  
5/25 
   Installing : basesystem-10.0-9.fc20.noarch  
6/25 
   Installing : ncurses-base-5.9-13.20140323.fc21.noarch   
7/25 
   Installing : tzdata-2014c-1.fc21.noarch 
8/25 
   Installing : nss-softokn-freebl-3.16.1-2.fc21.x86_64
9/25 
   Installing : glibc-common-2.19.90-18.fc21.x86_64
   10/25 
   Installing : glibc-2.19.90-18.fc21.x86_64   
   11/25 
 warning: %post(glibc-2.19.90-18.fc21.x86_64) scriptlet failed, exit status 127
 Non-fatal POSTIN scriptlet failure in rpm package glibc-2.19.90-18.fc21.x86_64
   Installing : libstdc++-4.9.0-5.fc21.x86_64  
   12/25 
 warning: %post(libstdc++-4.9.0-5.fc21.x86_64) scriptlet failed, exit status 
 127
 Non-fatal POSTIN scriptlet failure in rpm package 
 libstdc++-4.9.0-5.fc21.x86_64
   Installing : ncurses-libs-5.9-13.20140323.fc21.x86_64   
   13/25 
 warning: %post(ncurses-libs-5.9-13.20140323.fc21.x86_64) scriptlet failed, 
 exit status 127
 Non-fatal POSTIN scriptlet failure in rpm package 
 ncurses-libs-5.9-13.20140323.fc21.x86_64
   Installing : bash-4.3.18-1.fc21.x86_64  
   14/25 
   Installing : libsepol-2.3-1.fc21.x86_64 
   15/25 
 warning: %post(libsepol-2.3-1.fc21.x86_64) scriptlet failed, exit status 127
 Non-fatal POSTIN scriptlet failure in rpm package libsepol-2.3-1.fc21.x86_64
 ..
 error: %pre(ca-certificates-2013.1.94-18.fc20.noarch) scriptlet failed, exit 
 status 127
 Error in PREIN scriptlet in rpm package 
 ca-certificates-2013.1.94-18.fc20.noarch...

 When I boot the host with selinux=0, things seems to work fine. Nothing 
 useful in
 the logs as far as I can see. When I chroot into the container seems to work.

 Zbyszek

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: selinux issue with containers

[Daniel J Walsh]

On 05/28/2014 01:40 PM, Richard W.M. Jones wrote:
 On Wed, May 28, 2014 at 06:32:04PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
 On Wed, May 28, 2014 at 10:41:45AM -0400, Daniel J Walsh wrote:
 Yum -y update your entire computer and yum reinstall
 selinux-policy-targeted  Should fix the problem.
 Nope. No effect afaict. Any pointers how to debug this?
 Does it list any AVCs if you run this command shortly after the
 failure?

 # ausearch -ts recent -m avc

 Rich.

rpm -q selinux-policy-targeted

This looks like the old bug we had with a bad selinux policy update.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Daniel J Walsh]

On 05/02/2014 06:32 AM, Lennart Poettering wrote:
 On Wed, 30.04.14 09:44, Daniel J Walsh (dwa...@redhat.com) wrote:

 On 04/29/2014 05:47 PM, Marcelo Ricardo Leitner wrote:
 Em 29-04-2014 18:27, Martin Langhoff escreveu:
 On Tue, Apr 29, 2014 at 5:12 PM, Reindl Harald h.rei...@thelounge.net
 mailto:h.rei...@thelounge.net wrote:

 defense in depth means limit the attack surface as much as you can


 As folks are trying to point out to you, these principles are well
 understood in this group.

 However, _any minimally usable environment will have a scripting engine_
 -- /bin/sh, python, and having _any_ of those general purpose tools
 available is enough for the attacker.

 On your own machines, you might gain some (limited) advantage removing
 some of them.

 Fedora and its derivatives, OTOH, are a large enough target that it's
 worth for attackers to tailor attacks to it. So removing some tools
 won't do much, and removing _all_ tools will ruin everyone's day.
 Hm? Okay, thread got long, but I don't recall anybody saying to remove
 scripting engines  etc. The point always was being able to have
 docker images without systemd, just because it's just not needed in
 there, and the thread got drifted away on 'may or not be a security
 liability'.

 It's part of getting Fedora somewhat optimized for containers.

 Anyway, sounds like we have even already agreed to remove the
 Requires, if I'm reading the thread correctly. So yeah, nothing much
 left to discuss in here ;)

 Cheers,
 Marcelo

 I agree, where do I open a bugzilla to make this happen?  rpm?  Distro?
 Systemd?
 file a fpc ticket first.

 https://fedorahosted.org/fpc/

 Lennart

I did.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Daniel J Walsh]

On 04/29/2014 05:47 PM, Marcelo Ricardo Leitner wrote:
 Em 29-04-2014 18:27, Martin Langhoff escreveu:
 On Tue, Apr 29, 2014 at 5:12 PM, Reindl Harald h.rei...@thelounge.net
 mailto:h.rei...@thelounge.net wrote:

 defense in depth means limit the attack surface as much as you can


 As folks are trying to point out to you, these principles are well
 understood in this group.

 However, _any minimally usable environment will have a scripting engine_
 -- /bin/sh, python, and having _any_ of those general purpose tools
 available is enough for the attacker.

 On your own machines, you might gain some (limited) advantage removing
 some of them.

 Fedora and its derivatives, OTOH, are a large enough target that it's
 worth for attackers to tailor attacks to it. So removing some tools
 won't do much, and removing _all_ tools will ruin everyone's day.

 Hm? Okay, thread got long, but I don't recall anybody saying to remove
 scripting engines  etc. The point always was being able to have
 docker images without systemd, just because it's just not needed in
 there, and the thread got drifted away on 'may or not be a security
 liability'.

 It's part of getting Fedora somewhat optimized for containers.

 Anyway, sounds like we have even already agreed to remove the
 Requires, if I'm reading the thread correctly. So yeah, nothing much
 left to discuss in here ;)

 Cheers,
 Marcelo

I agree, where do I open a bugzilla to make this happen?  rpm?  Distro?
Systemd?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Daniel J Walsh]

On 04/30/2014 10:05 AM, Kalev Lember wrote:
 On 04/29/2014 12:31 PM, Lennart Poettering wrote:
 On Mon, 28.04.14 15:11, Toshio Kuratomi (a.bad...@gmail.com) wrote:

 On Apr 28, 2014 5:01 PM, Daniel J Walsh dwa...@redhat.com wrote:
 The problem  is lots of services require systemd because they ship a
 unit file and want systemctl reload to happen.
 Would removing the requires on systemd and doing:

 /usr/bin/systemctl reload ||:

 Work for these cases?
 Note that all the invocations of systemctl done by the systemd rpm
 macros are suffixed with /dev/null 21 || :, as it is customary for
 rpm scriplets. Hence there's little to do really, except dropping the
 deps, and leaving everything else in place...
 I suspect just dropping the deps would break initial installations, e.g.
 anaconda / livecd-creator. RPM uses the deps to order the transaction so
 that systemd gets installed first, and the packages that ship service
 files get installed later. Without the deps, rpm wouldn't know the order
 in which it has to run the transaction.

 For example, when a package bar has a postinstall script that does:

 systemctl enable bar.service /dev/null 21 || :

 .. but if systemctl gets installed _after_ foo in the same transaction,
 then the systemctl command never runs and service stays disabled.


Well you are never supposed to do this.  You are only supposed to do a
systemctl reload bar in a post install.  Any package that does do an
enable, should require systemd, as they are probably not candidates to
run in a container.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Daniel J Walsh]

On 04/30/2014 10:28 AM, Adam Jackson wrote:
 On Wed, 2014-04-30 at 16:05 +0200, Kalev Lember wrote:

 I suspect just dropping the deps would break initial installations, e.g.
 anaconda / livecd-creator. RPM uses the deps to order the transaction so
 that systemd gets installed first, and the packages that ship service
 files get installed later. Without the deps, rpm wouldn't know the order
 in which it has to run the transaction.

 For example, when a package bar has a postinstall script that does:

 systemctl enable bar.service /dev/null 21 || :

 ... but if systemctl gets installed _after_ foo in the same transaction,
 then the systemctl command never runs and service stays disabled.
 If you are right, this is an argument for rpm collections, which we've
 had for ages now and should really start using.

 - ajax

Created a ticket.

https://fedorahosted.org/fpc/ticket/425

Next I will create a change request if the ticket is approved.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Daniel J Walsh]

On 04/29/2014 06:31 AM, Lennart Poettering wrote:
 On Mon, 28.04.14 15:11, Toshio Kuratomi (a.bad...@gmail.com) wrote:

 On Apr 28, 2014 5:01 PM, Daniel J Walsh dwa...@redhat.com wrote:
 The problem  is lots of services require systemd because they ship a
 unit file and want systemctl reload to happen.
 Would removing the requires on systemd and doing:

 /usr/bin/systemctl reload ||:

 Work for these cases?
 Note that all the invocations of systemctl done by the systemd rpm
 macros are suffixed with /dev/null 21 || :, as it is customary for
 rpm scriplets. Hence there's little to do really, except dropping the
 deps, and leaving everything else in place...

 Lennart

That seems ideal.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Daniel J Walsh]

On 04/28/2014 06:44 PM, Adam Jackson wrote:
 On Mon, 2014-04-28 at 17:01 -0400, Daniel J Walsh wrote:
 The problem  is lots of services require systemd because they ship a
 unit file and want systemctl reload to happen.  Systemd then triggers a
 require for udev and kmod, which docker containers do not need.

 rpm -q --whatrequires systemd| wc -l
 151

 On rawhide I see 151 packages on my system which require systemd.

 We have a couple of options we could add a package called fakesystemd
 which provides a /usr/bin/systemctl that does nothing and does a
 provides systemd in the specfile.  Then if the user wanted to install
 systemd into a container it would need to obsolete the fakesystemd package.

 Or we could break out /usr/bin/systemctl into its own package and have
 it be smart enough to do nothing if systemd did not exist.
 Or you could just rpm -e systemd once you've done the initial rpm
 install, since it's just a Requires(post) and not a permanent Requires?

 - ajax

Although it would get sucked back in if a user did another yum install
(Update?) that needed systemctl.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Daniel J Walsh]

On 04/29/2014 06:33 AM, Lennart Poettering wrote:
 On Mon, 28.04.14 17:01, Daniel J Walsh (dwa...@redhat.com) wrote:

 The problem  is lots of services require systemd because they ship a
 unit file and want systemctl reload to happen.  Systemd then triggers a
 require for udev and kmod, which docker containers do not need.
 If you discount the docs/man pages of the RPMs, how much does kmod,
 udev, systemd actually contribtue in bytes to your docker images?

 Lennart

Shrinking the the docker image is more then just size.  We want to
eliminate packages that are not used (Within reason) to eliminate
problems like CVE's.  If udev/systemd/kmod had a CVE we would need to
update all Container images. 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Daniel J Walsh]

On 04/29/2014 03:17 PM, Chris Adams wrote:
 Once upon a time, Reindl Harald h.rei...@thelounge.net said:
 wrong question - is /bin/sh used?
 if the answer is yes then the anser to your question is no

 the point is remove anything *unneeded* from production systems
 that are best practices for many years and for good reasons
 No, the point is that remove a bunch of stuff to 'secure' the system
 is not security, and should not be claimed that it is being done for
 'security'.  If you have bash as /bin/sh (as a 'standard' Fedora system
 does), you don't need wget/curl to download stuff for example.

 Can you lock that down more?  Sure, you can remove network access,
 remove local write access, etc.  However, that is separate from removing
 arbitrary binaries from the system/image.  Removing non-privileged
 binaries from the image does _nothing_ for security (as claimed
 up-thread).

I am looking at this from a tools perspective.  If I run an scap tool
that says container image XYZ has a vulnerable image of udev, even if
udev is not being used, I will have to update the image.  If it does not
have the package, no reason to update.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Daniel J Walsh]

The problem  is lots of services require systemd because they ship a
unit file and want systemctl reload to happen.  Systemd then triggers a
require for udev and kmod, which docker containers do not need.

rpm -q --whatrequires systemd| wc -l
151

On rawhide I see 151 packages on my system which require systemd.

We have a couple of options we could add a package called fakesystemd
which provides a /usr/bin/systemctl that does nothing and does a
provides systemd in the specfile.  Then if the user wanted to install
systemd into a container it would need to obsolete the fakesystemd package.

Or we could break out /usr/bin/systemctl into its own package and have
it be smart enough to do nothing if systemd did not exist.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Workstation: Disable firewall

[Daniel J Walsh]

On 04/16/2014 09:32 AM, Simo Sorce wrote:
 On Wed, 2014-04-16 at 05:40 -0700, Daniel J Walsh wrote:
 On 04/15/2014 09:31 AM, Simo Sorce wrote:
 On Tue, 2014-04-15 at 09:13 -0700, Andrew Lutomirski wrote:
 I keep thinking that, if I had unlimited time, I'd write a totally
 different kind of firewall.  It would allow some policy (userspace
 daemon or rules loaded into the kernel) to determine when programs can
 listen on what sockets and when connections can be accepted on those
 sockets.  This avoids the attack surface of iptables, it will be
 faster, it can cause programs to actually report errors if you want
 them to, and it could be a lot easier to configure.

 Wouldn't it be great if, when you start some program that wants to
 listen globally, your system could prompt you and ask whether it was
 okay, even if that program didn't know about firewalld?

 I think what you are describing could be probably realized with SELinux
 today, just with a special setroubleshoot frontend that catches the AVC
 when the service tries to listen and ask the user if he wants to allow
 it.

 However this would still not be completely sufficient as you completely
 lack any context about what network you are operating on.

 The firewall's purpose is to block access to local services on bad
 networks too, it is not a binary open/close equation when you have
 machines (laptops) that roam across a variety of networks.

 Simo.

 Nothing worse then asking Users Security related questions about opening
 firewall ports.
 Users will just answer yes, whether or not they are being hacked.

 firefox wants to listen on port 9900 in order to see this page, OK?

 Which is not what I proposed Dan.

 I in fact said we should *NOT* ask per application.

 What we should ask is one single question, upon connecting to an unknown
 network: Is this network trusted ?

 If yes you open up to the local network. If no you keep ports not
 accessible on that network.

 We can hint that a cafe wifi is usually not trusted and users should say
 no, or perhaps we do not even ask and default to untrusted on open wifi
 networks, and only ask on secured networks (this would be my
 preference).
Didn't mean to accuse you of saying that.  I do like the idea of asking
if you are on a trusted network.
 %99.999 will answer yes, and be aggravated.

 Setting up a rule that says app XYZ is allowed to open certain ports
 would be a great step forward.  But there would need to be a provable
 way to guarantee that only the XYZ application is able to open those
 ports.  You could do this with SELinux, but we would need to transition
 user apps to certain domains, but we would need to run users with a
 confined domain, and stop disabling SELinux...
 I think we can do this in steps, I certainly agree with the long term
 goal.

 Simo.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Workstation: Disable firewall

[Daniel J Walsh]

On 04/15/2014 09:31 AM, Simo Sorce wrote:
 On Tue, 2014-04-15 at 09:13 -0700, Andrew Lutomirski wrote:
 I keep thinking that, if I had unlimited time, I'd write a totally
 different kind of firewall.  It would allow some policy (userspace
 daemon or rules loaded into the kernel) to determine when programs can
 listen on what sockets and when connections can be accepted on those
 sockets.  This avoids the attack surface of iptables, it will be
 faster, it can cause programs to actually report errors if you want
 them to, and it could be a lot easier to configure.

 Wouldn't it be great if, when you start some program that wants to
 listen globally, your system could prompt you and ask whether it was
 okay, even if that program didn't know about firewalld?

 I think what you are describing could be probably realized with SELinux
 today, just with a special setroubleshoot frontend that catches the AVC
 when the service tries to listen and ask the user if he wants to allow
 it.

 However this would still not be completely sufficient as you completely
 lack any context about what network you are operating on.

 The firewall's purpose is to block access to local services on bad
 networks too, it is not a binary open/close equation when you have
 machines (laptops) that roam across a variety of networks.

 Simo.

Nothing worse then asking Users Security related questions about opening
firewall ports.
Users will just answer yes, whether or not they are being hacked.

firefox wants to listen on port 9900 in order to see this page, OK?

%99.999 will answer yes, and be aggravated.

Setting up a rule that says app XYZ is allowed to open certain ports
would be a great step forward.  But there would need to be a provable
way to guarantee that only the XYZ application is able to open those
ports.  You could do this with SELinux, but we would need to transition
user apps to certain domains, but we would need to run users with a
confined domain, and stop disabling SELinux...




-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services

[Daniel J Walsh]

On 03/27/2014 01:49 PM, Miloslav Trmač wrote:
 2014-03-26 15:06 GMT+01:00 Jaroslav Reznik jrez...@redhat.com:
 == Detailed Description ==
 When PrivateDevices=yes...
 Furthermore, the
 CAP_MKNOD capability is removed. Finally, the devices cgroup controller is
 used to ensure that no access to device nodes except the listed ones is
 possible.
 When PrivateNetwork=yes ...
 4. This also disconnects the AF_UNIX abstract namespace
 5. This also disconnects the AF_NETLINK and AF_AUDIT socket families
 How much does this overlap existing SELinux policy?  Would it make
 sense to have both configured from a single source?  It seems to me
 that every inconsistency between the systemd unit file and the SELinux
 policy must be a bug; could we eliminate this class of bugs entirely,
 or if fully automated extraction of the information between the two
 data sets weren't feasible, would it make sense to have and regularly
 run tools that compare the two policies?
 Mirek
It doesn't really overlap with SELinux, just adds another layer of
security.  And gives the administrator more flexibility on how he
configures his services.  I do not think there are two many confined
domains that need mknod, and most confined domains are not allowed to
look at many device nodes.  In a way this can eliminate SELinux avcs,
from apps just doing the equiv of ls -l /dev

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services

[Daniel J Walsh]

On 03/27/2014 04:03 PM, Miloslav Trmač wrote:
 2014-03-27 20:57 GMT+01:00 Daniel J Walsh dwa...@redhat.com:
 On 03/27/2014 01:49 PM, Miloslav Trmač wrote:
 2014-03-26 15:06 GMT+01:00 Jaroslav Reznik jrez...@redhat.com:
 == Detailed Description ==
 When PrivateDevices=yes...
 Furthermore, the
 CAP_MKNOD capability is removed. Finally, the devices cgroup controller 
 is
 used to ensure that no access to device nodes except the listed ones is
 possible.
 When PrivateNetwork=yes ...
 4. This also disconnects the AF_UNIX abstract namespace
 5. This also disconnects the AF_NETLINK and AF_AUDIT socket families
 How much does this overlap existing SELinux policy?  Would it make
 sense to have both configured from a single source?  It seems to me
 that every inconsistency between the systemd unit file and the SELinux
 policy must be a bug; could we eliminate this class of bugs entirely,
 or if fully automated extraction of the information between the two
 data sets weren't feasible, would it make sense to have and regularly
 run tools that compare the two policies?
 Mirek
 It doesn't really overlap with SELinux, just adds another layer of
 security.
 Layers tend to overlap :) in affected areas, if not in specific 
 implementation.

 And gives the administrator more flexibility on how he
 configures his services.  I do not think there are two many confined
 domains that need mknod, and most confined domains are not allowed to
 look at many device nodes.
 So, could we generate a starting list of daemons to be restricted by
 PrivateDevices by looking for domains that aren't allowed in the
 SELinux policy to look at device nodes?  And use the fixes previously
 done in the SELinux policy to notice daemons that actually do need
 access to devices without ever publishing a RPM with a too constrained
 systemd unit to users?

 That's where I was going with this--possibly up to possible full
 bidirectional synchronization between SELinux and systemd units.
 Mirek
Yes I think that is a good idea.  I would look at all domains that need
access to non standard devices and eliminate them from the list.
 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Sshd getting 'dyntransition' AVC's in SElinux enforcing mode

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/06/2014 01:45 AM, Dan Callaghan wrote:
 Excerpts from Dan Callaghan's message of 2014-03-06 16:43:26 +1000:
 Excerpts from Daniel J Walsh's message of 2014-01-03 01:46:44 +1000:
 This is caused by sshd running with the wrong label, It should be 
 running as sshd_t not init_t.  If the executable labeled sshd_exec_t?
 
 ls -lZ /usr/sbin/sshd
 
 restorecon -v /usr/sbin/sshd
 
 should fix the label.
 
 I started getting the same AVC denials a week or so ago. My 
 /usr/sbin/sshd was indeed wrongly labelled:
 
 $ ll -Z /usr/sbin/sshd -rwxr-xr-x. root root
 unconfined_u:object_r:bin_t:s0   /usr/sbin/sshd $ sudo restorecon -v
 /usr/sbin/sshd restorecon reset /usr/sbin/sshd context
 unconfined_u:object_r:bin_t:s0-unconfined_u:object_r:sshd_exec_t:s0
 
 What I'm wondering is, how did it become wrongly labelled? Nothing else 
 on my filesystem was wrong, according to restorecon.
 
 The errors only appear in my logs after sshd was restarted on 24 Feb for
  a yum upgrade. The updated packages included:
 
 selinux-policy-3.12.1-122.fc20.noarch openssh-server-6.4p1-3.fc20.x86_64
 
 (among many others). Any hints on how I can figure out what went wrong 
 with the labelling of /usr/sbin/sshd?
 
 Oh, I forgot that the yum upgrade on 24 Feb was actually from F19-F20, 
 just like Philip who originally started this thread.
 
 I suppose that means we just write it off as upgrading between releases is
 not supported then...
 
 
 
I don't know what happened.  We have seen this bug usually when people are
updating from older Fedoras to F20.  It is strange, and I would figure it is
something with rpm, or something in the sshd package.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMYgsgACgkQrlYvE4MpobNdEwCfTyrlhx/WCsZumpK5VM62zWBF
1RMAoL3Pi7RK1zebSH+OwKL4eAxjJYSL
=mwRc
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Audit overhead and default rules

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/10/2014 04:49 PM, Andrew Lutomirski wrote:
 On Mon, Feb 10, 2014 at 1:02 PM, Steve Grubb sgr...@redhat.com wrote:
 On Monday, February 10, 2014 12:41:08 PM Andrew Lutomirski wrote:
 There are, indeed, many ways for me to fix this on my machine.
 I'm suggesting that Fedora change the default so that no one has 
 experiences this overhead by default.
 
 There are 3 levels of audit performance degradation. 1) audit is
 disabled. You get full speed 2) audit is enabled and no rules. This
 is the default for Fedora so that more information can be collected
 when AVC's occur. 3) audit is enabled and rules loaded. This does get
 a performance hit that can be measured. In this case, the person
 wanted auditing and is willing to take any performance hit it may
 incur.
 
 The audit system has been set for #2 for the last 8 or 9 years as a 
 balance between getting information for avc's, not taking a big
 performance hit, and keeping setup easy for when people want to add
 auditing to their system.
 
 Right.  I'm proposing changing the default from #2 to #1.
 
 I forgot to mention option 0) audit package not installed. I don't think
 the audit package is mandatory and that would be the default. But if you
 do install the audit package its assumed you want auditing in some
 capacity and are willing to take the minimal hit. You also get more audit
 events such as promiscuous socket use, user space events, and a couple
 other kernel events that are security related.
 
 I think that #2-by-default is a terrible tradeoff.  I suspect I've
 debugged more selinux denials than the average user, and I have *never*
 *once* looked at a 'syscall' entry in the log.
 
 The selinux people wanted the syscall event. Once upon a time, you used
 to have to add a rule to get the syscall information. But they decided
 they want more information by default. I would suggest reverting that
 patch as a test. I think the problem was that they needed a file path
 sometimes and would ask people to add an audit rule like -w /etc/shadow
 -p w. But then the user wouldn't get a recurrence and they couldn't
 really fix the problem very fast. The exact details may be different, but
 I think this is the gist of it.
 
 
 Here's an example from my logs:
 
 type=AVC msg=audit(1383816002.656:3662): avc:  denied  { execute } for 
 pid=32707 comm=sh name=ldconfig dev=dm-2 ino=172883 
 scontext=system_u:system_r:smoltclient_t:s0-s0:c0.c1023 
 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file type=SYSCALL
 msg=audit(1383816002.656:3662): arch=c03e syscall=59 success=no
 exit=-13 a0=9c0d30 a1=9c0e00 a2=9bfd70 a3=0 items=0 ppid=32706 pid=32707
 auid=999 uid=999 gid=998 euid=999 suid=999 fsuid=999 egid=998 sgid=998
 fsgid=998 ses=415 tty=(none) comm=sh exe=/usr/bin/bash 
 subj=system_u:system_r:smoltclient_t:s0-s0:c0.c1023 key=(null)
 
 The useful things (I think) are dev and ino, both of which are in the
 AVC line, not the syscall line.
 
 
 I think that subjecting every Fedora user by default to 20-40 ns of
 extra syscall latency for the sole benefit of getting those 'syscall'
 messages is a bad tradeoff.
 
 I don't think all Fedora users have audit installed and would not see the
 hit.
 
 From the F20 comps:
 
 group idcore/id _nameCore/_name _descriptionSmallest possible
 installation/_description defaultfalse/default 
 uservisiblefalse/uservisible packagelist packagereq
 type=mandatoryaudit/packagereq
 
 audit is the very first mandatory package :-/
 
 
 I'm willing to write kernel code to improve the situation.  The problem
 is that getting rid of TIF_SYSCALL_AUDIT when there are no audit rules
 configured is messy.  Better suggestions are welcome.
 
 The problem is getting TIF_SYSCALL_AUDIT back in all processes when
 auditing is enabled. We cannot stop the OS and stab that flag into all
 processes when audit gets re-enabled. Its best not to play with that
 flag.
 
 Sure we can.  I have patches to do that.  They have other problems, though,
 but that's fixable.
 
 
 The kernel logic is supposed to be something like
 
 if (tif  TIF_SYSCALL_AUDIT) if (current-audit_context) if
 (audit_ever_enabled) audit_syscall_entry()
 
 So, the overhead when disabled should only be an if statement or two.
 
 On my laptop it's up to 1/3 of *total* syscall time.  Linux fast-path 
 syscalls are fast, and audit disables the fast path.
 
 --Andy
 

Knowing the syscall was an execute versus and open call is valuable to knowing
if this is a leaked file descriptor versus an actual piece of code opening a
file.  Syscall records are also used by kernel engineers and other programmers
to figure out why a strange AVC appeared.  If there was a way to collect this
information only when an AVC happened, I would be fine with it.

I added a few of the SELinux kernel engineers to get their comment.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

Re: change Selinux context in %post?

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/07/2014 02:18 PM, Richard Shaw wrote:
 Ok, after sleeping on it, I have a question.
 
 Do I really need a full blown policy? I'm not creating anything new here.
 I'm just applying the existing context applied to /var/lib/mongod to 
 /var/lib/unifi/data, so can I just use semanage from %postrans?
 
 Thanks, Richard
 
 
No you should be able to just set the file context.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlL6RNUACgkQrlYvE4MpobOGbACgx97bIWV5RqSemVuCJWukHZK2
8OUAoLZAU5MCttuwsLoV/6GtIeI8+QVj
=aJpU
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: change Selinux context in %post?

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/06/2014 12:44 PM, Richard Shaw wrote:
 On Thu, Feb 6, 2014 at 11:37 AM, Daniel J Walsh dwa...@redhat.com 
 mailto:dwa...@redhat.com wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 02/06/2014 02:39 PM, Richard Shaw wrote:
 On Thu, Feb 6, 2014 at 2:49 AM, Miroslav Suchý msu...@redhat.com
 mailto:msu...@redhat.com wrote:
 
 On 02/05/2014 08:24 PM, Richard Shaw wrote:
 
 Are there official guidelines on how to handle selinux contexts in 
 packaging? I can still only find the draft which seems way more 
 complicated than necessary for my needs.
 
 I'm working on a package that uses mongodb internally (runs it's own 
 instance). Selinux is complaining because it has mongodb creating
 the database (and logs) outside of the normal locations
 You need to tell SELinux about the labels.
 
 semanage fcontext -e /var/lib/mysql PATHTO/mysql restorecon -R -v
 PATHTO/mysql
 
 Is probably what you want.
 
 
 Ok, I ended up getting to the same place using -a mongod_var_lib_t... Now
 how to turn that into a policy I can package?
 
 I ended up with this as the requirements to create a functional package:
 
 /var/lib/unifi/logs(/.*)?system_u:object_r:mongod_var_lib_t:s0 
 /var/lib/unifi/data(/.*)?system_u:object_r:mongod_var_lib_t:s0 portcon
 tcp 27117 system_u:object_r:mongod_port_t:s0
 
 Thanks, Ricahrd
 
 
Most likely the better solution would have been

/var/lib/unifi/logs(/.*)?system_u:object_r:mongod_log_t:s0

SHould these go into Fedora Policy?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlL6RRQACgkQrlYvE4MpobMSkACfcjz7Y7o3w+lYXpwL4PB+UJ4t
X3oAoM48lMdCw4J6cbAQkejcGt00rXNJ
=bgUx
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: change Selinux context in %post?

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/11/2014 03:23 PM, Richard Shaw wrote:
 On Tue, Feb 11, 2014 at 9:43 AM, Daniel J Walsh dwa...@redhat.com 
 mailto:dwa...@redhat.com wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 02/06/2014 12:44 PM, Richard Shaw wrote:
 On Thu, Feb 6, 2014 at 11:37 AM, Daniel J Walsh dwa...@redhat.com
 mailto:dwa...@redhat.com
 mailto:dwa...@redhat.com mailto:dwa...@redhat.com wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 02/06/2014 02:39 PM, Richard Shaw wrote:
 On Thu, Feb 6, 2014 at 2:49 AM, Miroslav Suchý msu...@redhat.com
 mailto:msu...@redhat.com
 mailto:msu...@redhat.com mailto:msu...@redhat.com wrote:
 
 On 02/05/2014 08:24 PM, Richard Shaw wrote:
 
 Are there official guidelines on how to handle selinux contexts in 
 packaging? I can still only find the draft which seems way more 
 complicated than necessary for my needs.
 
 I'm working on a package that uses mongodb internally (runs it's
 own instance). Selinux is complaining because it has mongodb
 creating the database (and logs) outside of the normal locations
 You need to tell SELinux about the labels.
 
 semanage fcontext -e /var/lib/mysql PATHTO/mysql restorecon -R -v 
 PATHTO/mysql
 
 Is probably what you want.
 
 
 Ok, I ended up getting to the same place using -a mongod_var_lib_t...
 Now how to turn that into a policy I can package?
 
 I ended up with this as the requirements to create a functional package:
 
 /var/lib/unifi/logs(/.*)?system_u:object_r:mongod_var_lib_t:s0 
 /var/lib/unifi/data(/.*)?system_u:object_r:mongod_var_lib_t:s0
 portcon tcp 27117 system_u:object_r:mongod_port_t:s0
 
 
 Most likely the better solution would have been
 
 /var/lib/unifi/logs(/.*)?system_u:object_r:mongod_log_t:s0
 
 
 That would probably work, I just used mongod_var_lib_t because it writes
 the logs in /var/lib instead of /var/log. As long as it works I'm not
 terribly picky.
 
 
 SHould these go into Fedora Policy?
 
 
 Well, if this was a package destined for the Fedora repository I would ask,
 what reasons/requirements need to be met to have the policy go into the
 upper level Fedora policy and when should it go directly in the package
 itself?
 
 Since this is not FOSS software (however useful and required to manage the 
 devices) it's destined for RPM Fusion non-free so I'm guessing it needs to
 go into the package itself.
 
 Thanks, Richard
 
 

If these paths make sense, we can add the labels to the Fedora Policy.  It
does not have to be FOSS Software to be in the policy package.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlL6kEEACgkQrlYvE4MpobMEigCePz23veRszwhASjCsdKuSvt3s
5/4An3uQtGuhNsKtnGag0Wov37yENnQx
=E28n
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: change Selinux context in %post?

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/06/2014 02:39 PM, Richard Shaw wrote:
 On Thu, Feb 6, 2014 at 2:49 AM, Miroslav Suchý msu...@redhat.com wrote:
 
 On 02/05/2014 08:24 PM, Richard Shaw wrote:
 
 Are there official guidelines on how to handle selinux contexts in 
 packaging? I can still only find the draft which seems way more
 complicated than necessary for my needs.
 
 I'm working on a package that uses mongodb internally (runs it's own 
 instance). Selinux is complaining because it has mongodb creating the
 database (and logs) outside of the normal locations
You need to tell SELinux about the labels.

semanage fcontext -e /var/lib/mysql PATHTO/mysql
restorecon -R -v PATHTO/mysql

Is probably what you want.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLzyGsACgkQrlYvE4MpobNYWQCeJZf17KvHSr6JfoKRSTx7oopb
RgoAn1OmUd7nLkr6alO1g5Ct58KQrwHz
=yJZG
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: I want to turn on a part of the kernel to make SELinux checking more stringent.

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/26/2014 03:49 PM, Andrew Lutomirski wrote:
 On Sun, Jan 26, 2014 at 12:38 PM, Richard W.M. Jones rjo...@redhat.com
 wrote:
 Slightly OT, but is SELinux stopping programs from executing code at 
 address zero?  (And how can I stop it doing that?)
 
 JONESFORTH, a public domain FORTH I wrote, is written in x86 assembler 
 and prefers to put its threaded interpreter at address 0.  This worked 
 fine before, but has now stopped working, and this is reported to be due
 to SELinux.
 
 IIRC, in new kernels, /proc/sys/vm/mmap_min_addr and MAC policy both have
 to allow the mmap call.  In older kernels, only one of them had to allow
 it.
 
 Maybe some day SMAP-capable machines (e.g. Haswell, I think) will ignore
 these settings entirely -- I think that SMAP covers all the cases that
 mmap_min_addr was meant to pretect against.
 
 --Andy
 
setsebool -P mmap_low_allowed 1

Will turn off this protection from an SELinux point of view, although you
should be careful with this.
 
 http://rwmj.wordpress.com/2010/08/07/jonesforth-git-repository/#comment-6591



 
Rich.
 
 -- Richard Jones, Virtualization Group, Red Hat
 http://people.redhat.com/~rjones virt-df lists disk usage of guests
 without needing to install any software inside the virtual machine.
 Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- 
 devel mailing list devel@lists.fedoraproject.org 
 https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of
 Conduct: http://fedoraproject.org/code-of-conduct

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLmfwEACgkQrlYvE4MpobOECwCfVZ5Q7fMjcYQQ/KHRZF2krmq3
07EAn0BUTIuX/i3WtlEd3MBaMXqpj5Xl
=dnIj
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: I want to turn on a part of the kernel to make SELinux checking more stringent.

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/24/2014 07:29 PM, Alek Paunov wrote:
 On 24.01.2014 21:20, Daniel J Walsh wrote:
 
 No, we pretty much allow executable stack/memory from user processes now
 and block it for most daemons, except for those that need it.  My
 understanding of this change is that the kernel was not doing complete
 checking, but most apps at this point do the right thing.  We will turn
 it on in Rawhide and through the beta.  If we see problems we will
 revert.  It is now a one line change in
 
 
 SELinux newbie question: Where the daemons exception is actually defined.
 My practical interest is: What should be added to LuaJIT [1] to be able to
 run e.g. non-packaged web servers like [2]?
 
 Thanks, Alek
 
 [1] http://pkgs.fedoraproject.org/cgit/luajit.git/plain/luajit.spec [2]
 https://github.com/kernelsauce/turbo
 
I don't really understand your question.

When you run your Web Server does SELinux actually block anything?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLmf1EACgkQrlYvE4MpobMNAQCeKcLabW047Plzf6MDdXUIfBEk
uBMAn3Oq2ZBEnvDQcKLdV8u/iKEz3CTu
=mdtX
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

I want to turn on a part of the kernel to make SELinux checking more stringent.

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I wrote a systemd unit file to enable it, and to allow a user to disable the
feature if he wants.

# cat /usr/lib/systemd/system/selinux-checkreqprot.service
[Unit]
Description=SELinux check actual protection flags applied by kernel, rather
than checking what application requested.

[Service]
Type=oneshot
RemainAfterExit=yes
Environment=CHECKREQPROT=0
EnvironmentFile=-/etc/selinux/config
ExecStart=/bin/sh -c '/bin/echo $CHECKREQPROT  /sys/fs/selinux/checkreqprot'


I would like to enable this service on the post install of a initial install
of libselinux.  But I believe this will not happen with

%systemd_post_enable selinux-checkreqprot.service

How would I go about doing this?

I know there is one problem in the unit file, it will fail if
/sys/fs/selinux/checkreqprot, does not exist.  Is their an easy check to just
exit if this file does not exist?

Also is using a unit file for this, the best way to handle this?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLihVAACgkQrlYvE4MpobNpZACfbC5WmT7GUirmcBIri1BJOs33
DcMAnA24d4xumzT4vBPWbLSeEnQwj1VU
=Kswu
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: I want to turn on a part of the kernel to make SELinux checking more stringent.

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/24/2014 10:32 AM, Lennart Poettering wrote:
 On Fri, 24.01.14 10:22, Daniel J Walsh (dwa...@redhat.com) wrote:
 
 Heya,
 
 Do we really need a service for this? Can't this be done instead via a 
 tmpfiles snippet that uses f and the extra argument at the end?
 
No I did not know that tmpfiles.d did this.  I will look into using that.
 I mean I am not convinced it's worth involving shell here. Also the 
 canonical way to write things to /proc or /sys is 
 {/etc,/usr/lib/}/sysctl.d/ and {/etc,/usr/lib/}/tmpfiles.d/ if it's simple
 and static. And I don't see why we shouldn't do this differently in this
 case than in all others...
 
 If you would ship a simple tmpfiles snippet in /usr/lib/tmpfiles.d/, then
 users who want to opt out of this could simply symlink the file to 
 /dev/null in /etc/tmpfiles.d/.
 

 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 I wrote a systemd unit file to enable it, and to allow a user to disable
 the feature if he wants.
 
 # cat /usr/lib/systemd/system/selinux-checkreqprot.service [Unit] 
 Description=SELinux check actual protection flags applied by kernel,
 rather than checking what application requested.
 
 [Service] Type=oneshot RemainAfterExit=yes Environment=CHECKREQPROT=0 
 EnvironmentFile=-/etc/selinux/config ExecStart=/bin/sh -c '/bin/echo
 $CHECKREQPROT  /sys/fs/selinux/checkreqprot'
 
 
 I would like to enable this service on the post install of a initial
 install of libselinux.  But I believe this will not happen with
 
 %systemd_post_enable selinux-checkreqprot.service
 
 How would I go about doing this?
 
 I know there is one problem in the unit file, it will fail if 
 /sys/fs/selinux/checkreqprot, does not exist.  Is their an easy check to
 just exit if this file does not exist?
 
 Also is using a unit file for this, the best way to handle this?
 
 Lennart
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLijEAACgkQrlYvE4MpobMm5gCfebHFEnypgZbZy0fVSR1Omz0I
0N8An3c4B9rP8hpV0Jkla8bQIXATzpT4
=KUxo
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: I want to turn on a part of the kernel to make SELinux checking more stringent.

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Here is the request from upstream to enable this feature in Rawhide, with an
explanation of what it does.

 Android is starting to apply execmem and friends to the non-Dalvik 
 components (i.e. non-Java components, primarily the native system
 daemons). As part of that, I uploaded a change to effectively echo 0  
 /sys/fs/selinux/checkreqprot so that we always check the actual protection 
 flags applied by the kernel rather than only checking what the application 
 requested.
 
 Originally checkreqprot was to support legacy applications that had no 
 PT_GNU_STACK marking or were marked with PT_GNU_STACK RWE, so that we 
 wouldn't have to add execute permission pervasively to policy for such 
 applications.  But it effectively provides a way to bypass policy by
 creating such an application, and as I later discovered, just by calling 
 personality(READ_IMPLIES_EXEC) from an application at any time. The
 simplest way to eliminate that bypass comprehensively is to change the
 defaults for checkreqprot.
 
 I think this is likely safe in Fedora since you now allow execmem by
 default to most domains.  Can we get the same change applied in Fedora,
 either by changing the default kernel configuration 
 (CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=0) or by putting something in
 an init script to set the /sys/fs/selinux/checkreqprot value?


-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLijmYACgkQrlYvE4MpobP3GgCg0sGEjAuD7tKM+4aH3HkGOnJP
wuYAoJOfrvEjYm90uwUMpDIW0p7NfSel
=DOlV
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: I want to turn on a part of the kernel to make SELinux checking more stringent.

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/24/2014 02:11 PM, Björn Persson wrote:
 Daniel J Walsh wrote:
 Here is the request from upstream to enable this feature in Rawhide, with
 an explanation of what it does.
 
 Android is starting to apply execmem and friends to the non-Dalvik 
 components (i.e. non-Java components, primarily the native system 
 daemons). As part of that, I uploaded a change to effectively echo 0
 /sys/fs/selinux/checkreqprot so that we always check the actual 
 protection
 flags applied by the kernel rather than only checking what the 
 application requested.
 
 Originally checkreqprot was to support legacy applications that had no
 PT_GNU_STACK marking or were marked with PT_GNU_STACK RWE, so that we
 wouldn't have to add execute permission pervasively to policy for such
 applications.  But it effectively provides a way to bypass policy by
 creating such an application, and as I later discovered, just by
 calling personality(READ_IMPLIES_EXEC) from an application at any time.
 The simplest way to eliminate that bypass comprehensively is to change
 the defaults for checkreqprot.
 
 I think this is likely safe in Fedora since you now allow execmem by 
 default to most domains.  Can we get the same change applied in Fedora,
 either by changing the default kernel configuration 
 (CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=0) or by putting something
 in an init script to set the /sys/fs/selinux/checkreqprot value?
 
 I'm afraid all I understand of that explanation is that this has something
 to do with executable stacks. How does the proposed change affect programs
 that need an executable stack?
 
 Björn Persson
 
 
 
No, we pretty much allow executable stack/memory from user processes now and
block it for most daemons, except for those that need it.  My understanding of
this change is that the kernel was not doing complete checking, but most apps
at this point do the right thing.  We will turn it on in Rawhide and through
the beta.  If we see problems we will revert.  It is now a one line change in

# grep check /lib/tmpfiles.d/selinux-policy.conf
w /sys/fs/selinux/checkreqprot 1

I believe you can revert it by adding

echo w /sys/fs/selinux/checkreqprot 0  /etc/tmpfiles.d/selinux-policy.conf





-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLivPsACgkQrlYvE4MpobMODQCgxDzqQZEwAVB3PeLPkDB5t4jI
FFcAnRpPxMSQO1ymoxEsDaxU64qCGxMq
=oI08
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Drawing lessons from fatal SELinux bug #1054350

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/24/2014 01:35 PM, Reindl Harald wrote:
 
 
 Am 24.01.2014 19:31, schrieb Reindl Harald:
 
 Am 24.01.2014 19:18, schrieb drago01:
 On Fri, Jan 24, 2014 at 7:12 PM, Fabian Deutsch fabian.deut...@gmx.de
 wrote:
 Am Freitag, den 24.01.2014, 00:55 +0100 schrieb Kevin Kofler:
 it is time to analyze the fallout from the following catastrophic 
 Fedora 20 regression: 
 https://bugzilla.redhat.com/show_bug.cgi?id=1054350 rpm scriptlets
 are exiting with status 127
 
 Hey,
 
 can't we add a default boot entry which starts the system in
 permissive mode?
 
 How would that help? If a user knows enough about the issue to try it 
 he/she could just switch to permissive mode
 
 in *that* case
 
 in a case where a broken selinux update leads in not boot at all i can
 not imagine what i would to besides boot with a CD/DVD/USB
 
 to be clear - *i can* edit the boot-params and put selinux=0 there
 
 the average user can't but he may remember uhm something with selinux was
 one of the last updates and try the however named option, keep in mind
 some people own only one machine and can't google for help
 
 
 
enforcing=0 in the kernel command line will boot the machine in permissive mode.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLivWUACgkQrlYvE4MpobOCVwCg13o4l1+JL6MkQhbEOKfXqMBx
0YcAoNnetQTwZMslI7jP1To03WwC0twi
=86Sz
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Go packaging guidelines?

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/14/2014 02:18 PM, Matthew Miller wrote:
 On Tue, Jan 14, 2014 at 12:06:09PM +0100, Florian Weimer wrote:
 A couple of questions and comments.  I think overall, the approach
 works. # Packaging Libraries This does not mention libraries which use
 cgo.  Should they be handled the same way?  What about additional C
 wrappers?
 
 I think for now, yes. Unless you have a better suggestion.
 
 # Security in Go Language Packages The repoquery invocations for checking
 for affected programs are incorrect because the archive may have evolved
 from the time the binary Go program has been built and no longer reflect
 those dependencies.  The non-stripped nature of binaries should make it 
 possible to see, based on the binaries alone, which libraries were used
 to compile it.
 
 Hmmm, okay. Would it be useful to have a script that generates a list 
 automatically?
 
 On the other hand, I wonder if we should rebuild all dependent binary Go
 programs each time any of the libraries used to build it change.  This
 ensure that we ship matching source code for the compiled binary, and it
 causes any breakage sooner.
 
 I'm worried that that would cause a lot of needless churn. But maybe it's 
 for the best.
 
I have added some go bindings for libselinux, which are used in the docker
port.  Currently I am shipping these in libselinux-devel.

# rpm -q libselinux-devel
libselinux-devel-2.2.2-2.fc21.x86_64

# rpm -ql libselinux-devel | grep go
/usr/share/gocode/src/selinux
/usr/share/gocode/src/selinux/selinux.go

Is the correct way for C libraries that we ship to provide go bindings?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLegL0ACgkQrlYvE4MpobMumgCffnGnOxQr05KJ434TVzdG3XjH
WW0Anj/bV06DBh6T/ZK+83q5PsAlsdJN
=sqgm
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: SELinux RPM scriplet issue annoucement

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/20/2014 04:42 AM, Michael Schwendt wrote:

I think we should have a much higher Karma for SELinux-policy to be released.
5 or maybe 10.  The problem with selinux-policy is it gets karma fast, since
each update fixes multiple bugs.  And people just update it, see if it fixes
their bug, then the tester updates the karma.  As has been said, the update
broke the next update. Which no one caught.

Forcing it to wait a week would probably not be a bad idea.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLdO8AACgkQrlYvE4MpobMbagCgsdkkZA2mSPvku/mrUlS6aOZu
fKQAoKmGHU0kJJZilPXWULTKL6ZyG7MC
=Tmvz
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: SELinux RPM scriplet issue annoucement

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/20/2014 10:50 AM, Simo Sorce wrote:
 On Mon, 2014-01-20 at 08:42 +0100, Michael Schwendt wrote:
 On Sun, 19 Jan 2014 23:02:24 -0500, Simo Sorce wrote:
 
 Anyone not aware of the problem and the fix, who applies the
 -117.fc20 selinux-policy update in _enforcing_ mode (since it has
 entered stable updates meanwhile) believing it to be a normal update,
 will face another failure and a partial update. Package
 selinux-policy updated to -117.fc20 but -targeted remaining at
 -116.fc20.
 
 I don't see this. I just updated today before reading this message (and
 I haven;t read the whole thread, sorry) and I got selinux-policy and
 targeted updated without any problem (I always run in enforcing mode).
 
 Did you update from -116.fc20 or an earlier one?
 
 Only if you come from -116.fc20, you would be affected, since -116.fc20
 is the bad update.
 
 Ah I think I skipped 116, sorry for the noise.
 
 Simo.
 
Lucky man, hopefully a lot of users skipped it...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLdXA4ACgkQrlYvE4MpobObvwCgrvA8ndAn5zBUpWA/LvO3fCUw
qKUAoLHkon72qLTudvb/5LsHguzzt8Rg
=8cRf
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Livecd-creator is disabling selinux

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/13/2014 04:17 PM, Richard W.M. Jones wrote:
 [Moving this to the libguestfs mailing list]
 
 On Mon, Jan 13, 2014 at 03:05:14PM -0500, Daniel J Walsh wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 01/13/2014 11:49 AM, Richard W.M. Jones wrote:
 On Mon, Jan 13, 2014 at 10:20:22AM -0500, Daniel J Walsh wrote:
 Secondly we prevent even unconfined_t from putting down labels on
 the file system that the kernel does not understand.  IE If I am
 building a F21 image on a RHEL6 box, it would blow up in enforcing
 mode if run as unconfined_t.  We added a special policy called
 livecd_t that is allowed to put down labels which the kernel does not
 understand, and unconfined_t will transition to this domain.
 
 Slightly off-topic, but this (in-)ability to label files with labels
 which the kernel doesn't know about affects libguestfs negatively too.
 Is there some reason why it's bad?
 
 Well we could add a label to libguestfs to allow these labels.  From the
 running kernel point of view you end up with unlabeled_t.
 
 I think it's more complex with libguestfs because of the appliance, and
 because libguestfs normally runs with SELinux disabled inside the 
 appliance.
 
 [Note to peanut gallery: libguestfs uses and endorses SELinux and sVirt to
 implement containment of qemu *in the host*.  The above applies only to the
 appliance.]
 
 I know you wrote a good blog posting and we have a (very very old) open bug
 to fix libguestfs's SELinux support:
 
 https://bugzilla.redhat.com/show_bug.cgi?id=554829
 
 After thinking about this for some years and Pino Toscano implementing a
 new  useful copy-attributes API in libguestfs, I think what we really want
 is to copy security.selinux xattr from one file to another.  This gives us
 almost all we need, doesn't require us to run loadpolicy, and should work
 independent of guest policy.
 
 Luckily for us ... it works!
 
 $ virt-builder fedora-20 $ guestfish -a fedora-20.img -i
 fs getxattrs /etc/shadow
 [0] = { attrname: security.selinux attrval:
 system_u:object_r:shadow_t:s0\x00 }
 fs cp /etc/shadow /etc/shadow.copy fs setxattr security.selinux
 system_u:object_r:shadow_t:s0 29 /etc/shadow.copy fs getxattrs
 /etc/shadow.copy [0] = {
 attrname: security.selinux attrval: system_u:object_r:shadow_t:s0 }
 
 Is this expected?  Are we bypassing the kernel/SELinux in some way? Note
 that the libguestfs appliance kernel doesn't (AFAIK) know about the
 system_u:object_r:shadow_t:s0 label.
 
 We also would like to prevent users from making mistakes like assigning
 httpd_t to a file when it is a process type.
 
 SELinux is going to check before you put the label down unless you have
 the mac_admin capability.
 
 Rich.
 
That is correct, and what you are doing is correct.  In libguestfs case there
is no reason to load_policy in the guest.  As long as you don't force the host
to setenforce 0.  Setting a XAttr to anything, is ok on an SELinux disabled
system, which is why this is working for you.  As long as libguestfs maintains
the SELinux labels inside the guest, it is perfect.

Thanks.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLVTIQACgkQrlYvE4MpobNbjQCeMCd2oNg5VT9n3h0QEuQVKlaf
T1UAni/ZEXcgteDI7qKRLVJKi5ppFZbB
=jQvP
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Livecd-creator is disabling selinux

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/10/2014 10:47 PM, Dennis Gilmore wrote:
 El Fri, 10 Jan 2014 18:31:13 -0700 Tim Flink tfl...@redhat.com escribió:
 On Fri, 10 Jan 2014 15:35:59 -0800 Adam Williamson awill...@redhat.com
 wrote:
 
 On Fri, 2014-01-10 at 17:33 -0600, Dennis Gilmore wrote:
 El Fri, 10 Jan 2014 15:26:38 -0800 Adam Williamson
 awill...@redhat.com escribió:
 On Thu, 2014-01-09 at 11:32 +0100, Maros Zatko wrote:
 Dear guys and ladies, So it seems like livecd-creator is silently
 disabling selinux. Proof: vim $(which livecd-creator) ; line 150 
 Fact, that it's re-enabled afterwards doesn't ease silent 
 disablement of security feature.
 
 I'd love to know the reason and if it's possible to do something
 about it.
 
 Because live images don't work properly if it's either disabled or
 enforcing while the image is being generated. Why *that* is I don't
 know, but before bcl made the livecd-creator script do this, we
 just had a bit in the livecd-creator instructions which said you
 have to run setenforce Permissive before starting to build a live
 image.
 
 If you try building a live image with SELinux either disabled or 
 enforcing on the build host, you wind up either with a compose that
 fails, or an image that can't be booted in enforcing mode.
 
 Adam this is not true, All Offical Fedora images for years were built
 on hosts with selinux disabled. F20 was the first time images were
 built with the host in permissive mode, but then they are built in a
 mock chroot which has selinux disabled in the chroot
 
 Hum, I'm sure back before the script tried to take care of it for you,
 I'd had multiple failures with both 'enforcing' and 'disabled'. But if
 you say so...
 
 I've also run into problems with livecd-creator and was told the same 
 thing: for best results, run with SELinux in permissive mode - not 
 disabled and not enforcing.
 
 It was a while ago but I don't think that it was something I hit for 
 every build. This leads me to suspect that whatever the issue is, it 
 doesn't happen every time and the releng setup must be able to avoid 
 whatever it is that people can (and do) hit with SELinux disabled or 
 enforcing.
 
 Also, I think that until F20 releng was building livecds in mock chroots
 on el boxes (dennis, please correct me if I'm wrong) where both you and I
 were building livecds on fedora installs.
 
 Tim,
 
 F20 images were built in f20 chroots on f19 boxes. but selinux on the host
 was permissive. prior to f20 it was the target os chroot on el
 
 Dennis
 

The point being any of these tools to work with SELinux in enforcing mode, we
need the processes within the build tools to believe SELinux is disabled,
since we do not want them trying to do SELinux things, like loading policy.

Secondly we prevent even unconfined_t from putting down labels on the file
system that the kernel does not understand.  IE If I am building a F21 image
on a RHEL6 box, it would blow up in enforcing mode if run as unconfined_t.  We
added a special policy called livecd_t that is allowed to put down labels
which the kernel does not understand, and unconfined_t will transition to this
domain.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLUBDUACgkQrlYvE4MpobOFugCbBY2+4hDmEmeJTy0PCy+7J3un
x5AAn1c4H0xrXEwRCjN7vFk6pkywBhaP
=a7/6
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Livecd-creator is disabling selinux

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/13/2014 11:49 AM, Richard W.M. Jones wrote:
 On Mon, Jan 13, 2014 at 10:20:22AM -0500, Daniel J Walsh wrote:
 Secondly we prevent even unconfined_t from putting down labels on the
 file system that the kernel does not understand.  IE If I am building a
 F21 image on a RHEL6 box, it would blow up in enforcing mode if run as
 unconfined_t.  We added a special policy called livecd_t that is allowed
 to put down labels which the kernel does not understand, and unconfined_t
 will transition to this domain.
 
 Slightly off-topic, but this (in-)ability to label files with labels which
 the kernel doesn't know about affects libguestfs negatively too. Is there
 some reason why it's bad?
 
 Rich.
 
Well we could add a label to libguestfs to allow these labels.  From the
running kernel point of view you end up with unlabeled_t.  We also would like
to prevent users from making mistakes like assigning httpd_t to a file when it
is a process type.

SELinux is going to check before you put the label down unless you have the
mac_admin capability.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLURvoACgkQrlYvE4MpobM8UwCgumLZBVrnwCwwby6jjeKiCXMV
q4QAn3R1avfBzgLHG24DPLEYHSmhAgNE
=YckJ
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Livecd-creator is disabling selinux

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/09/2014 05:32 AM, Maros Zatko wrote:
 Dear guys and ladies, So it seems like livecd-creator is silently disabling
 selinux. Proof: vim $(which livecd-creator) ; line 150 Fact, that it's
 re-enabled afterwards doesn't ease silent disablement of security feature.
 
 I'd love to know the reason and if it's possible to do something about it.
 
 Cheers, - maros
 
 N.b.: i'm sorry if this is repost
Please open a bugzilla on this, and CC me on it.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLOr3QACgkQrlYvE4MpobN1mwCg3hwxswlI5kvbrJOb0qYzR+23
GnYAoKYoOf+pho+PkL6B6JWiZmN8V5KK
=VP4w
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Sshd getting 'dyntransition' AVC's in SElinux enforcing mode

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/27/2013 05:06 PM, Philip Prindeville wrote:
 I’m seeing the following after an update (via yum) from F19 to F20:
 
  time-Tue Dec 24 16:05:44 2013 type=SYSCALL
 msg=audit(1387926344.492:5867): arch=c03e syscall=1 success=no exit=-13
 a0=6 a1=7f4e5e7afbb0 a2=20 a3=7fff44c2c550 items=0 ppid=686 pid=693
 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
 ses=4294967295 tty=(none) comm=sshd exe=/usr/sbin/sshd
 subj=system_u:system_r:init_t:s0 key=(null) type=AVC
 msg=audit(1387926344.492:5867): avc:  denied  { dyntransition } for
 pid=693 comm=sshd scontext=system_u:system_r:init_t:s0
 tcontext=system_u:system_r:sshd_net_t:s0 tclass=process  time-Tue Dec
 24 16:05:45 2013 type=SYSCALL msg=audit(1387926345.093:5883): arch=c03e
 syscall=1 success=no exit=-13 a0=7 a1=7f4e5e7acef0 a2=2a
 a3=666e6f636e753a72 items=0 ppid=686 pid=706 auid=1000 uid=1000 gid=1000
 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 ses=627
 tty=(none) comm=sshd exe=/usr/sbin/sshd
 subj=system_u:system_r:init_t:s0 key=(null) type=AVC
 msg=audit(1387926345.093:5883): avc:  denied  { dyntransition } for
 pid=706 comm=sshd scontext=system_u:system_r:init_t:s0
 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process
 
 
 Is this a known issue?  I’m running:
 
 selinux-policy-devel-3.12.1-106.fc20.noarch 
 selinux-policy-targeted-3.12.1-106.fc20.noarch 
 selinux-policy-doc-3.12.1-106.fc20.noarch 
 selinux-policy-3.12.1-106.fc20.noarch openssh-clients-6.4p1-3.fc20.x86_64 
 openssh-6.4p1-3.fc20.x86_64 openssh-server-6.4p1-3.fc20.x86_64
 
 Thanks,
 
 -Philip
 
This is caused by sshd running with the wrong label, It should be running as
sshd_t not init_t.  If the executable labeled sshd_exec_t?

ls -lZ /usr/sbin/sshd

restorecon -v /usr/sbin/sshd

should fix the label.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLFieQACgkQrlYvE4MpobP9MgCfc021YV5LYtmoTfa6I4wMWbus
A8wAniWyoTqQWpmhvQ8gN2SCKvtAcNGh
=FGdE
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 20 TC2 AMIs

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/21/2013 03:13 PM, Vitaly Kuznetsov wrote:
 Matthew Miller mat...@fedoraproject.org writes:
 
 On Thu, Nov 21, 2013 at 01:30:15PM +0100, Vitaly Kuznetsov wrote:
 I ran basic tests agains them and they're ok. The only issue I still
 see is wrong SELinux context for several files:
 
 # restorecon -Rvn -e/dev -e/proc -e/sys -e/run -e/tmp/ / restorecon
 reset /var/cache/yum context
 system_u:object_r:file_t:s0-system_u:object_r:rpm_var_cache_t:s0 
 restorecon reset /var/log/boot.log context
 system_u:object_r:var_log_t:s0-system_u:object_r:plymouthd_var_log_t:s0

 
restorecon reset /boot/extlinux/ldlinux.sys context
system_u:object_r:file_t:s0-system_u:object_r:boot_t:s0
 
 That's weird. We're running fixfiles at the end of the build process to 
 clean up anything like that.
 
 I looked into kickstart, you do '/usr/sbin/fixfiles -R -a restore'. I tried
 running it manually on fresh instance:
 
 # /usr/sbin/fixfiles -R -a restore 75k/sbin/restorecon set context 
 /boot/extlinux/ldlinux.sys-system_u:object_r:boot_t:s0 failed:'Operation
 not permitted' 80k/sbin/restorecon set context 
 /boot/extlinux/ldlinux.sys-system_u:object_r:boot_t:s0 failed:'Operation
 not permitted' 177k/sbin/restorecon set context 
 /boot/extlinux/ldlinux.sys-system_u:object_r:boot_t:s0 failed:'Operation
 not permitted'
 
 However /boot/extlinux/ldlinux.sys is the only file needs fixind after 
 this:
 
 # restorecon -Rvn -e/dev -e/proc -e/sys -e/run -e/tmp/ / restorecon reset
 /boot/extlinux/ldlinux.sys context 
 system_u:object_r:file_t:s0-system_u:object_r:boot_t:s0
 
 Anyway, https://bugzilla.redhat.com/show_bug.cgi?id=1033274 as suggested by
 dwalsh)
 
Any change something is mounted on top of these files/directories when the
fixfiles is run.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKPXq8ACgkQrlYvE4MpobPw7wCeMz5w3mGE9PRI+qRJxQTDmpK3
gzYAoN2VWaVI5iGpxkVN/vTA+JTfKWoh
=WycT
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 20 TC2 AMIs

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/21/2013 07:30 AM, Vitaly Kuznetsov wrote:
 Dennis Gilmore den...@ausil.us writes:
 
 Hi all,
 
 Final TC2 images have been uploaded to EC2 and are available at
 
 ami-3392b55a : us-east-1 image for i386 ami-f794b39e : us-east-1 image
 for x86_64
 
 
 I ran basic tests agains them and they're ok. The only issue I still see is
 wrong SELinux context for several files:
 
 # restorecon -Rvn -e/dev -e/proc -e/sys -e/run -e/tmp/ / restorecon reset
 /var/cache/yum context
 system_u:object_r:file_t:s0-system_u:object_r:rpm_var_cache_t:s0 
 restorecon reset /var/log/boot.log context
 system_u:object_r:var_log_t:s0-system_u:object_r:plymouthd_var_log_t:s0 
 restorecon reset /boot/extlinux/ldlinux.sys context
 system_u:object_r:file_t:s0-system_u:object_r:boot_t:s0
 
These should be opened as a bug in anaconda. (The file_t ones anyways.)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKOFv4ACgkQrlYvE4MpobOezgCfRCHVSoSCaM9M0X8Jn9b8+RBq
kd0AoML3rHbYa00CSGojEFWS8WmmLc9Y
=xunE
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 20 TC2 AMIs

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/21/2013 11:19 AM, Dennis Gilmore wrote:
 We don't use anaconda to make the images. We use appliance-creator which is
 part of appliance-tools. I'm the upstream for them.
 
Is the appliance-tools running restorecon -R -v / in the end like
livecd-creator used to?

anaconda has a list of files/directories that it runs restorecon on after the
install is done.  The idea is to fix labels of content that was created before
selinux policy was loaded into the kernel.  If these are the only two files
that are mislabeled, then I would just run restorecon on them.
 Daniel J Walsh dwa...@redhat.com wrote:
 
 On 11/21/2013 07:30 AM, Vitaly Kuznetsov wrote:
 
 Dennis Gilmore den...@ausil.us writes:
 
 Hi all,
 
 Final TC2 images have been uploaded to EC2 and are available at
 
 ami-3392b55a : us-east-1 image for i386 ami-f794b39e : us-east-1 image for
 x86_64
 
 
 I ran basic tests agains them and they're ok. The only issue I still see
 is wrong SELinux context for several files:
 
 # restorecon -Rvn -e/dev -e/proc -e/sys -e/run -e/tmp/ / restorecon reset 
 /var/cache/yum context 
 system_u:object_r:file_t:s0-system_u:object_r:rpm_var_cache_t:s0 
 restorecon reset /var/log/boot.log context 
 system_u:object_r:var_log_t:s0-system_u:object_r:plymouthd_var_log_t:s0 
 restorecon reset /boot/extlinux/ldlinux.sys context 
 system_u:object_r:file_t:s0-system_u:object_r:boot_t:s0
 
 These should be opened as a bug in anaconda. (The file_t ones anyways.)
 
 
 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
 
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKOSb4ACgkQrlYvE4MpobPBUACgsHbZ6R6ie+Co0m2STvpD73Xx
HRMAoLZ604yqAErwiW4m7rhLWa0JuadR
=2+91
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Base] Summary/Minutes from today's Base WG meeting (2013-11-08)

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/11/2013 10:31 AM, Harald Hoyer wrote:
 On 11/10/2013 01:39 PM, Daniel J Walsh wrote:
 A few other things, I would like to see broken out would be sort of a
 lower level definition for containers, based on the docker model.  IE Can
 we remove the need for systemd/kernel from the new container group?
 
 Base  Minimal Install  Container Install.
 
 Since Containers were put off til later, we can discuss then.
 
 What kind of containers? App containers or OS containers?
 
 Isn't systemd a required addition for OS containers? I think it has to
 manage cgroups and d-bus if kdbus kicks in.
 
Application/docker containers.  Does not need kernel or systemd.  Just running
httpd within a container.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKBDOkACgkQrlYvE4MpobM8MwCggEWv5erkIK98llk9IH4cJC61
zoYAnjNrx9NVvQzczChmYa8sy/rEfBUt
=npKI
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Base] Summary/Minutes from today's Base WG meeting (2013-11-08)

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/08/2013 11:51 AM, Dennis Gilmore wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 == 
 #fedora-meeting: Fedora Base Design Working Group (2013-11-08) 
 ==
 
 
 Meeting started by pknirsch at 15:00:59 UTC. The full logs are available 
 at 
 http://meetbot.fedoraproject.org/fedora-meeting/2013-11-08/fedora_base_design_working_group.2013-11-08-15.00.log.html

 
Also I apologize for not being there, I was at a conference.

A few other things, I would like to see broken out would be sort of a lower
level definition for containers, based on the docker model.  IE Can we remove
the need for systemd/kernel from the new container group?

Base  Minimal Install  Container Install.

Since Containers were put off til later, we can discuss then.

Dreaming big would be to specify base language of English and then define new
ways for packaging to add other languages as needed.

Is remote access to the Base Instance required?  sshd?

Is Login required?

Audit?

Firewall?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJ/fpgACgkQrlYvE4MpobNGZQCgnsBRqryJAoMDVMsGUOmOsB3e
nbsAoOZrshFBzUx5izVzkKgGEPkZwEO2
=YlEC
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct