Livecd-creator is disabling selinux

[Maros Zatko]

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

[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-----

[Adam Williamson]

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.

livecd-creator is a string-and-duct-tape hack, it does quite a lot of
ugly things. bcl's been trying to replace it with livemedia-creator for
a while, but that effort seems to keep running into roadblocks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Fri, 10 Jan 2014 15:26:38 -0800
Adam Williamson <awilliam(a)redhat.com&gt; 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

Dennis
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIcBAEBAgAGBQJS0IM5AAoJEH7ltONmPFDR0g4QAI6klWhJfx3rNdtYX5k+5CZy
> jYGsPMyv7SE2N20p0WNj7v0SNA1jo3wcqsugHTsyGME1G72n15zL3PIqaYUuq4rJ
> RmHQDxfUugq66n5iNnfw7lsJ/N2sqCd86wR1TTnWHKYypqf5XmKx6tBOY6A+uEEF
> MmOTaoDHVbtFM9bKZGKkfqorhFJH16mNleS1mC/sC/+a5xuGKbVBDYM2Pt+7/H1T
> YNPTZQhyEUR6k40vTV642yFxkSE/chltBswE9ZXTErey2JUuPLOdrRbppd9tj7vu
> Lcbxm7NPpXTJA9fKeBlNwIlXq25wVHu98NlyCfawNE6fNZzqWm03tP7If0PHy7x7
> KG3M6EUQy+aLm+vRRa/H7iEH/USGe8wgTDY1IizDShuJQeKfAmVtUyXijvGNcGer
> K3z3BURivWvvXjuZ8sIfZTCq6IDkWC7MQh4X6gPj58t4ZVj3/p5nnxBhVwh1Nksn
> pumS3/mtUz/c+Rw5JtwWKS2QuUTG4U9ywspjkz7oGqEWDm/Th67t/1zmhof/LT0T
> lVmJWM6gyz9lhWBGNZhkGfNqcTvNdTo9TJ8nu4eCTKIGQRS7ODk6u/m1sBFxg8/i
> 0IrxHfW6Od0wrglxwh695G9liRVctLfmrwzTcnmiee/KQRVNa0TTDq7RdvU6Nsp+
> zzNex8J/09Vj73TLmg9B
> =JLdx
> -----END PGP SIGNATURE-----
>

[Adam Williamson]

On Fri, 2014-01-10 at 17:33 -0600, Dennis Gilmore wrote:
>  El Fri, 10 Jan 2014 15:26:38 -0800
>  Adam Williamson <awilliam(a)redhat.com&gt; 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...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Tim Flink]

On Fri, 10 Jan 2014 15:35:59 -0800
Adam Williamson <awilliam(a)redhat.com&gt; wrote:

>  On Fri, 2014-01-10 at 17:33 -0600, Dennis Gilmore wrote:
>  > El Fri, 10 Jan 2014 15:26:38 -0800
>  > Adam Williamson <awilliam(a)redhat.com&gt; 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

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Fri, 10 Jan 2014 18:31:13 -0700
Tim Flink <tflink(a)redhat.com&gt; escribió:
>  On Fri, 10 Jan 2014 15:35:59 -0800
>  Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  
>  > On Fri, 2014-01-10 at 17:33 -0600, Dennis Gilmore wrote:
>  > > El Fri, 10 Jan 2014 15:26:38 -0800
>  > > Adam Williamson <awilliam(a)redhat.com&gt; 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIcBAEBAgAGBQJS0L7UAAoJEH7ltONmPFDRcRkQAMmepLraNTt5/r8IPRU8tos5
> pRs1c7a0h+IR0Dn1zZigVmgJzr42ST38X2eKqOJGHZj1Fh48TaJ8wjjTbsI8jhYz
> iEa8mjbGpJz0qoUw2C6Ah8vjO/isetM2qAniFBX58mG1V3fPrMe51M9KWtzI7pSt
> 304yO7Eqzf7Wb00MGzD+EWXDLRjlZXW6ekSUXOz1cfxzExDaVmMcIGE59hoh1HNa
> rPEPmSrU87i1EEcHyT1NHdaQ17KoM2yuqbchjtw4vcHFkdAXcSqeLyvOr8JkE39s
> CeNH+11wcPKfK7YxcNyBOX679jk9us2kov7t+fnNCglrh1qiAcSUgy3QT+p/qmVP
> /xYOjm6gy1a3FkWbQAvQ723RBDKJJ8GQ19LSUcByOc9rRrkKKnQQfYNK7as/J2b7
> vVBlLIJMPpjMl081JQYI8sxEDvDFrQ8MVniHJFsDomvZjtBXNdxu7nofhiIUNx0A
> VwfJ1GvReNnIgRLcN1X2i/cDOn736tvilhLFQFdZMcB9bNF7C6xYSeEbERqA8QCI
> c1JlTtrSnHzpx8XN6yLxl5nM9e/XMBdcpxh5zxihNPQKngCDZ5KtspdTWo/NbpSk
> g27HBgiKm1Oo/zSFmFHQ+sG2eKqnGDT6EzqsT1IZUdrSfQkzR7q5ad/FWtN2CbKf
> Lpnl7HtI3f4zIWT+yA81
> =mJNO
> -----END PGP SIGNATURE-----
>

[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
> <tflink(a)redhat.com&gt; escribió:
> > On Fri, 10 Jan 2014 15:35:59 -0800 Adam Williamson <awilliam(a)redhat.com&gt;
> > wrote:
>  
> >> On Fri, 2014-01-10 at 17:33 -0600, Dennis Gilmore wrote:
> >>> El Fri, 10 Jan 2014 15:26:38 -0800 Adam Williamson
> >>> <awilliam(a)redhat.com&gt; 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-----

[Richard W.M. Jones]

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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

[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-----

[Richard W.M. Jones]

[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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[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-----