From: Laurent Bigonville <[email protected]>
---
rtkit.fc | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/rtkit.fc b/rtkit.fc
index 52c441e..fd82305 100644
--- a/rtkit.fc
+++ b/rtkit.fc
@@ -1 +1,5 @@
/usr/libexec/rtkit-daemon -- gen_context(system_u:object_r:rtkit_daemon_exec_t,s0)
+
+ifdef(`distro_debian',`
+/usr/lib/rtkit/rtkit-daemon -- gen_context(system_u:object_r:rtkit_daemon_exec_t,s0)
+')
--
1.7.10.4
On Thu, 2012-09-13 at 00:14 +0200, Laurent Bigonville wrote:
> From: Laurent Bigonville <[email protected]>
>
> ---
> rtkit.fc | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/rtkit.fc b/rtkit.fc
> index 52c441e..fd82305 100644
> --- a/rtkit.fc
> +++ b/rtkit.fc
> @@ -1 +1,5 @@
> /usr/libexec/rtkit-daemon -- gen_context(system_u:object_r:rtkit_daemon_exec_t,s0)
> +
> +ifdef(`distro_debian',`
> +/usr/lib/rtkit/rtkit-daemon -- gen_context(system_u:object_r:rtkit_daemon_exec_t,s0)
> +')
This was merged. Thanks
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/13/2012 08:19 AM, Dominick Grift wrote:
>
>
> On Thu, 2012-09-13 at 00:14 +0200, Laurent Bigonville wrote:
>> From: Laurent Bigonville <[email protected]>
>>
>> --- rtkit.fc | 4 ++++ 1 file changed, 4 insertions(+)
>>
>> diff --git a/rtkit.fc b/rtkit.fc index 52c441e..fd82305 100644 ---
>> a/rtkit.fc +++ b/rtkit.fc @@ -1 +1,5 @@ /usr/libexec/rtkit-daemon --
>> gen_context(system_u:object_r:rtkit_daemon_exec_t,s0) +
>> +ifdef(`distro_debian',` +/usr/lib/rtkit/rtkit-daemon --
>> gen_context(system_u:object_r:rtkit_daemon_exec_t,s0) +')
>
> This was merged. Thanks
>
> _______________________________________________ refpolicy mailing list
> refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
>
I have never been a big fan of the ifdef(DISTRO) stuff in the fc files. Why is
it necessary hear? Only reason for this would be if another distro had a file
here named /usr/lib/rtkit/rtkit-daemon that they wanted to label differently.
Lets not flood the fc files with these macros. I could definitely see Fedora
moving to this location. Driven by systemd.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBSAhMACgkQrlYvE4MpobPSZwCcCR2+DEOBscaO5+tAW8MVeh/1
v54AoLQLibo8L9y6id4oXH1ukQJJ3SLC
=GfgV
-----END PGP SIGNATURE-----
On Thu, 2012-09-13 at 11:56 -0400, Daniel J Walsh wrote:
> On 09/13/2012 08:19 AM, Dominick Grift wrote:
> >
> >
> > On Thu, 2012-09-13 at 00:14 +0200, Laurent Bigonville wrote:
> >> From: Laurent Bigonville <[email protected]>
> >>
> >> --- rtkit.fc | 4 ++++ 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/rtkit.fc b/rtkit.fc index 52c441e..fd82305 100644 ---
> >> a/rtkit.fc +++ b/rtkit.fc @@ -1 +1,5 @@ /usr/libexec/rtkit-daemon --
> >> gen_context(system_u:object_r:rtkit_daemon_exec_t,s0) +
> >> +ifdef(`distro_debian',` +/usr/lib/rtkit/rtkit-daemon --
> >> gen_context(system_u:object_r:rtkit_daemon_exec_t,s0) +')
> >
> > This was merged. Thanks
> >
> > _______________________________________________ refpolicy mailing list
> > refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
> >
> I have never been a big fan of the ifdef(DISTRO) stuff in the fc files. Why is
> it necessary hear? Only reason for this would be if another distro had a file
> here named /usr/lib/rtkit/rtkit-daemon that they wanted to label differently.
> Lets not flood the fc files with these macros. I could definitely see Fedora
> moving to this location. Driven by systemd.
I agree, but until we get consensus cross the board regarding this issue
i don't see any reason to reject these patches.
removing the ifdef wrappers is trivial so as soon as we can all agree
ill remove them.
So i would like to hear opinions of at least pebenito. bigon and swift
about this as well (which i cc'd)
Le Thu, 13 Sep 2012 18:06:14 +0200,
Dominick Grift <[email protected]> a ?crit :
> I agree, but until we get consensus cross the board regarding this
> issue i don't see any reason to reject these patches.
>
> removing the ifdef wrappers is trivial so as soon as we can all agree
> ill remove them.
>
> So i would like to hear opinions of at least pebenito. bigon and swift
> about this as well (which i cc'd)
Shouldn't we add some comments to keep track of distro specific paths?
Otherwise, if at some point, we want to make some cleanup it might
become difficult to track if a path is still required.
Otherwise, I've no strong opinion on this subject.
Cheers
Laurent Bigonville
On Sep 15, 2012 1:35 PM, "Laurent Bigonville" <[email protected]> wrote
> Shouldn't we add some comments to keep track of distro specific paths?
> Otherwise, if at some point, we want to make some cleanup it might
> become difficult to track if a path is still required.
You even have this 'problem' for non-distro specific locations, such as
locations that change with newer program releases. OK, we make it a bit
worse here, but I think this is minor compared to the obsolete locations
due to older software releases.
I think that if we look at locations module by module, we should be able to
clean up things. However, lots of locations are mentioned in corecommands
and libraries. Those might be more difficult to relate. Which was why I
suggested to perhaps allow bin/lib in module specific fc files earlier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20120915/c3179fef/attachment.html
On Sat, 2012-09-15 at 20:08 +0200, Sven Vermeulen wrote:
>
> On Sep 15, 2012 1:35 PM, "Laurent Bigonville" <[email protected]> wrote
> > Shouldn't we add some comments to keep track of distro specific
> paths?
> > Otherwise, if at some point, we want to make some cleanup it might
> > become difficult to track if a path is still required.
>
> You even have this 'problem' for non-distro specific locations, such
> as locations that change with newer program releases. OK, we make it a
> bit worse here, but I think this is minor compared to the obsolete
> locations due to older software releases.
>
> I think that if we look at locations module by module, we should be
> able to clean up things. However, lots of locations are mentioned in
> corecommands and libraries. Those might be more difficult to relate.
> Which was why I suggested to perhaps allow bin/lib in module specific
> fc files earlier.
I just encountered something related today when i was porting stuff from
fedora to contrib.
The afs module was basically not used in fedora because fedora has the
entry files in a location that was not in the file context file.
Anyways i just added those and left the old stuff because we need to
consider backwards compatibility.
So i am saying, for now not to worry about obsolete file contexts, you
never know who still have files in old locations.
Thats also another thing that sucks, the chances we find such issues
that i described above are slim because by default anything that initrc
runs get run in a unconfined domain if it has a generic executable file
type.
So if you dont know where to look, its hard to determine whether policy
is actually enforced or whether the app runs unprotected.
The only way to figure that out is to disable the unconfined module.
or to review each policy module carefully as i am doing.
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
If you like to hear a luser, more or less, opinion mostly the problem
that today the refpolicy have is because exists other project that
forked it, right or wrong it is not important. And apparently none
care. And none care where someone have to send patches, improvment ,
new policy. Is it a good thing ? Perhaps i have missed something ?
Dunno
2012/9/15, Dominick Grift <[email protected]>:
>
>
> On Sat, 2012-09-15 at 20:08 +0200, Sven Vermeulen wrote:
>>
>> On Sep 15, 2012 1:35 PM, "Laurent Bigonville" <[email protected]> wrote
>> > Shouldn't we add some comments to keep track of distro specific
>> paths?
>> > Otherwise, if at some point, we want to make some cleanup it might
>> > become difficult to track if a path is still required.
>>
>> You even have this 'problem' for non-distro specific locations, such
>> as locations that change with newer program releases. OK, we make it a
>> bit worse here, but I think this is minor compared to the obsolete
>> locations due to older software releases.
>>
>> I think that if we look at locations module by module, we should be
>> able to clean up things. However, lots of locations are mentioned in
>> corecommands and libraries. Those might be more difficult to relate.
>> Which was why I suggested to perhaps allow bin/lib in module specific
>> fc files earlier.
>
>
> I just encountered something related today when i was porting stuff from
> fedora to contrib.
>
> The afs module was basically not used in fedora because fedora has the
> entry files in a location that was not in the file context file.
>
> Anyways i just added those and left the old stuff because we need to
> consider backwards compatibility.
>
> So i am saying, for now not to worry about obsolete file contexts, you
> never know who still have files in old locations.
>
> Thats also another thing that sucks, the chances we find such issues
> that i described above are slim because by default anything that initrc
> runs get run in a unconfined domain if it has a generic executable file
> type.
>
> So if you dont know where to look, its hard to determine whether policy
> is actually enforced or whether the app runs unprotected.
>
> The only way to figure that out is to disable the unconfined module.
>
> or to review each policy module carefully as i am doing.
>
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
--
Inviato dal mio dispositivo mobile
On Sun, 2012-09-16 at 21:31 +0200, Elia Pinto wrote:
> If you like to hear a luser, more or less, opinion mostly the problem
> that today the refpolicy have is because exists other project that
> forked it, right or wrong it is not important. And apparently none
> care. And none care where someone have to send patches, improvment ,
> new policy. Is it a good thing ? Perhaps i have missed something ?
> Dunno
I do not believe that it is true that no one cares but distributions do
sometimes have priorities that do not always align with upstreams'
priorities. It is a tough world out there for businesses that need to
send pay checks to employees.
I think that people understand that working with upstream is probably
the sustainable solution in the long term. It is just easier said than
done when one is facing deadlines et cetera.
Also it is a matter of resources for those community projects that do
not have a commercial incentive i suspect. Many distributions do not
enable selinux by default and do not have many policy authors and
contributors.
Currently we have, in my view, a good impulse. We have SwifT on behalf
of Gentoo contributing and we have bigon contributing on behalf of
debian.
I currently do some porting for and contributing on behalf of Fedora and
hopefully mgrepl will also help out, and help solve remaining issues.
Reference policy is called this way for a reason and so i guess it is
reasonable to expect some changes between policies that distributions
ship and refpolicy. However there does not have to a big difference
since essentially the policy that a distribution ships is also a
reference policy and both are pretty much general purpose policies.
Anyways, this is off topic in my opinion. This topic is about not using
if(n)?def(`') in file context files and i think that it should not be a
big problem to have some possibly redundant file context specs for the
sake of guaranteeing backwards compatibility.
On 09/13/12 12:06, Dominick Grift wrote:
>
>
> On Thu, 2012-09-13 at 11:56 -0400, Daniel J Walsh wrote:
>> On 09/13/2012 08:19 AM, Dominick Grift wrote:
>>>
>>>
>>> On Thu, 2012-09-13 at 00:14 +0200, Laurent Bigonville wrote:
>>>> From: Laurent Bigonville <[email protected]>
>>>>
>>>> --- rtkit.fc | 4 ++++ 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/rtkit.fc b/rtkit.fc index 52c441e..fd82305 100644 ---
>>>> a/rtkit.fc +++ b/rtkit.fc @@ -1 +1,5 @@ /usr/libexec/rtkit-daemon --
>>>> gen_context(system_u:object_r:rtkit_daemon_exec_t,s0) +
>>>> +ifdef(`distro_debian',` +/usr/lib/rtkit/rtkit-daemon --
>>>> gen_context(system_u:object_r:rtkit_daemon_exec_t,s0) +')
>>>
>>> This was merged. Thanks
>>>
>>>
>> I have never been a big fan of the ifdef(DISTRO) stuff in the fc files. Why is
>> it necessary hear? Only reason for this would be if another distro had a file
>> here named /usr/lib/rtkit/rtkit-daemon that they wanted to label differently.
>> Lets not flood the fc files with these macros. I could definitely see Fedora
>> moving to this location. Driven by systemd.
>
> I agree, but until we get consensus cross the board regarding this issue
> i don't see any reason to reject these patches.
>
> removing the ifdef wrappers is trivial so as soon as we can all agree
> ill remove them.
>
> So i would like to hear opinions of at least pebenito. bigon and swift
> about this as well (which i cc'd)
We can always remove the ifdef if Fedora uses that path. But in this case, the fc seems odd to me; why would you put a service's executable in /usr/lib (even as a subdir)?
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
Le Mon, 17 Sep 2012 11:17:17 -0400,
"Christopher J. PeBenito" <[email protected]> a ?crit :
> We can always remove the ifdef if Fedora uses that path. But in this
> case, the fc seems odd to me; why would you put a service's
> executable in /usr/lib (even as a subdir)?
Debian is not using libexec and puts these files in /usr/lib/*/ instead
On 09/17/12 11:22, Laurent Bigonville wrote:
> Le Mon, 17 Sep 2012 11:17:17 -0400,
> "Christopher J. PeBenito" <[email protected]> a ?crit :
>
>> We can always remove the ifdef if Fedora uses that path. But in this
>> case, the fc seems odd to me; why would you put a service's
>> executable in /usr/lib (even as a subdir)?
>
> Debian is not using libexec and puts these files in /usr/lib/*/ instead
To clarify, I wasn't saying the patch should be rejected, but rather that because it seems like a very nontraditional place, I think it would warrant using the ifdef.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/17/2012 11:17 AM, Christopher J. PeBenito wrote:
> On 09/13/12 12:06, Dominick Grift wrote:
>>
>>
>> On Thu, 2012-09-13 at 11:56 -0400, Daniel J Walsh wrote:
>>> On 09/13/2012 08:19 AM, Dominick Grift wrote:
>>>>
>>>>
>>>> On Thu, 2012-09-13 at 00:14 +0200, Laurent Bigonville wrote:
>>>>> From: Laurent Bigonville <[email protected]>
>>>>>
>>>>> --- rtkit.fc | 4 ++++ 1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/rtkit.fc b/rtkit.fc index 52c441e..fd82305 100644 ---
>>>>> a/rtkit.fc +++ b/rtkit.fc @@ -1 +1,5 @@ /usr/libexec/rtkit-daemon
>>>>> -- gen_context(system_u:object_r:rtkit_daemon_exec_t,s0) +
>>>>> +ifdef(`distro_debian',` +/usr/lib/rtkit/rtkit-daemon --
>>>>> gen_context(system_u:object_r:rtkit_daemon_exec_t,s0) +')
>>>>
>>>> This was merged. Thanks
>>>>
>>>>
>>> I have never been a big fan of the ifdef(DISTRO) stuff in the fc files.
>>> Why is it necessary hear? Only reason for this would be if another
>>> distro had a file here named /usr/lib/rtkit/rtkit-daemon that they
>>> wanted to label differently. Lets not flood the fc files with these
>>> macros. I could definitely see Fedora moving to this location. Driven
>>> by systemd.
>>
>> I agree, but until we get consensus cross the board regarding this issue
>> i don't see any reason to reject these patches.
>>
>> removing the ifdef wrappers is trivial so as soon as we can all agree ill
>> remove them.
>>
>> So i would like to hear opinions of at least pebenito. bigon and swift
>> about this as well (which i cc'd)
>
> We can always remove the ifdef if Fedora uses that path. But in this case,
> the fc seems odd to me; why would you put a service's executable in
> /usr/lib (even as a subdir)?
>
Systemd is pushing the idea that you put apps that are to be run as a service
or by a library into /usr/lib/PACKAGENAME (This apps should never be run using
multilib). As opposed to /usr/libexec.
These are the directories I have in Fedora 18
/usr/lib/gconv
/usr/lib/sse2
/usr/lib/jvm
/usr/lib/cups
/usr/lib/udev
/usr/lib/debug
/usr/lib/alsa
/usr/lib/krb5
/usr/lib/dracut
/usr/lib/kbd
/usr/lib/jvm-private
/usr/lib/jvm-exports
/usr/lib/rtkaio
/usr/lib/bonobo
/usr/lib/games
/usr/lib/binfmt.d
/usr/lib/grub
/usr/lib/security
/usr/lib/crda
/usr/lib/gcc
/usr/lib/udisks2
/usr/lib/modprobe.d
/usr/lib/systemd
/usr/lib/python2.7
/usr/lib/mozilla
/usr/lib/locale
/usr/lib/python3.3
/usr/lib/audit
/usr/lib/gems
/usr/lib/jvm-commmon
/usr/lib/modules
/usr/lib/firmware
/usr/lib/tmpfiles.d
/usr/lib/xen
/usr/lib/modules-load.d
/usr/lib/i686
/usr/lib/polkit-1
/usr/lib/yum-plugins
/usr/lib/sysctl.d
/usr/lib/man2html
/usr/lib/rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBXQNwACgkQrlYvE4MpobNk2gCeLJAykDVtnEfo7NMYut308v/z
LQgAn2+Tibfah9G9+LsbOhSB9W4P0RAf
=uwrK
-----END PGP SIGNATURE-----
On Sep 17, 2012 5:25 PM, "Daniel J Walsh" <[email protected]> wrote:
> Systemd is pushing the idea that you put apps that are to be run as a
service
> or by a library into /usr/lib/PACKAGENAME (This apps should never be run
using
> multilib). As opposed to /usr/libexec.
Wouldn't it be a good idea to use a different label for these? They aren't
meant to be executed by individuals xirectly are they? So bin_t might not
be as good. What about a service_exec_t or so?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20120917/a8cdf2d6/attachment-0001.html
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/17/2012 11:30 AM, Sven Vermeulen wrote:
>
> On Sep 17, 2012 5:25 PM, "Daniel J Walsh" <[email protected]
> <mailto:[email protected]>> wrote:
>> Systemd is pushing the idea that you put apps that are to be run as a
>> service or by a library into /usr/lib/PACKAGENAME (This apps should never
>> be run using multilib). As opposed to /usr/libexec.
>
> Wouldn't it be a good idea to use a different label for these? They aren't
> meant to be executed by individuals xirectly are they? So bin_t might not
> be as good. What about a service_exec_t or so?
>
>
>
> _______________________________________________ refpolicy mailing list
> refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
>
Most of these would not be labeled bin_t, they would be labeled
systemd_exec_t, init_exec_t, udev_exec_t ...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBXQmQACgkQrlYvE4MpobMWogCeKCh6zMIAq9nIPHGmaG2zwIUR
NWgAoOTJzR4FRiPoVxHnlBeWDFX7FNIm
=oPMB
-----END PGP SIGNATURE-----