Bug#736909: Missing appconfig file for libvirt and LXC containers

2014-01-29 Thread Daniel J Walsh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/28/2014 05:15 AM, Laurent Bigonville wrote:
 Hi,
 
 Libvirt selinux security driver is now enabled in debian unstable. Qemu/KVM
 VM can be started properly now, but a bug[1] has been reported that LXC
 containers are failing to start due to the missing lxc_contexts appconfig
 file.
 
 Looking at the fedora policy, it's indeed shipping that file with the 
 following content:
 
 - process = system_u:system_r:svirt_lxc_net_t:s0 content =
 system_u:object_r:virt_var_lib_t:s0 file =
 system_u:object_r:svirt_sandbox_file_t:s0 sandbox_kvm_process =
 system_u:system_r:svirt_qemu_net_t:s0 sandbox_lxc_process =
 system_u:system_r:svirt_lxc_net_t:s0 -
 
 I only see minimal differences between the virt module in the refpolicy and
 the one in the fedora one, and I'm maybe missing something, but it seems
 that some types are missing in both the refpolicy and the fedora policy. I
 find no signs of svirt_qemu_net_t or sandbox_file_t for example.
 
 So an idea how we could make libvirt happy with LXC containers?
 
 Cheers,
 
 Laurent Bigonville
 
 
 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736909
 
 PS: could you please keep the 736909-forwarded CC while replying.
 

There in there,   I have attached the latest qemu policy.  We use
svirt_sandbox_file_t not sandbox_file_t (This is used for the type of sandbox
- -X containers).




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

iEYEARECAAYFAlLo/ocACgkQrlYvE4MpobM7gwCgwzHws/wTFcOry2KGauJ06UIn
1ggAoN2F+xfdaCOvc/rOOm7UpaQL+PQq
=3UGI
-END PGP SIGNATURE-


qemu.tgz
Description: GNU Zip compressed data


Bug#472590: RFC: changing the + in ls -l output to be . or +

2008-10-31 Thread Daniel J Walsh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Meyering wrote:
 Russell Coker [EMAIL PROTECTED] wrote:
 
 On Saturday 25 October 2008 00:19, Mike Edenfield [EMAIL PROTECTED] wrote:
 Jim Meyering wrote:
 A desire for compatibility makes + look good.
 . is appealing for SELinux-only because it's inconspicuous.
 Speaking as a fairly new SELinux user/admin, having a .
 next to every file in my ls output is just as useful or
 non-useful as having a + next to them, so does it really
 buy anything?  I end up needing -Z either way.
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472590

 The above URL has the history of this discussion.  I requested that there be
 no such notification.  I still believe that there should be nothing used in
 the case of SE Linux (although I could be convinced that the . is OK if
 files with the context system_u:object_r:file_t:s0 did not have it).

 But it seems that I have lost this debate.  Using . is better than +, and
 my request to have none of this in Lenny has been accepted so we have some
 time to work on this before Lenny+1.

 Based on the kind of real-world problems I've had, the most
 useful thing ls could tell me about a file on my SELinux
 system would be that it *should* have a label and *doesn't*,
 something like:

 if ( selinux_enabled )
if ( label == NULL || label == fs.defaultlabel )
  use !
else
  use  
 else if ( anything else )
use +
 That sounds quite reasonable.
 
 Actually, I'm leaning your way, now, and agree.
 
 If you, Russell, write the patch (w/NEWS and docs would be really nice)
 I'll make the switch upstream pretty soon.  It'd be nice to give the
 austin group a heads up, too, since this behavior would be contrary to
 POSIX.  I don't think it's worth it to make this depend on the setting
 of the POSIXLY_CORRECT envvar.
 
 --
 This message was distributed to subscribers of the selinux mailing list.
 If you no longer wish to subscribe, send mail to [EMAIL PROTECTED] with
 the words unsubscribe selinux without quotes as the message.
If you really wanted to go wild, you could add a qualifier to check
matchpathcon to indicate it differs from the default for the file
system, although it would be very expensive.  Perhaps find would be a
better source.  find all files not matching the system defaults.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkLCjEACgkQrlYvE4MpobM3ywCfZtVW9cQE8hgLRVCHYqHKLfU1
cWgAn2/cx41bmoFguBEVJXGbUiqsryzH
=+qTw
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]