SELinux-Refpolicy Archive on lore.kernel.org
 help / color / Atom feed
* [RFC] Purging dead modules
@ 2021-01-11 14:48 Chris PeBenito
  2021-01-11 15:23 ` Dominick Grift
  0 siblings, 1 reply; 7+ messages in thread
From: Chris PeBenito @ 2021-01-11 14:48 UTC (permalink / raw)
  To: refpolicy

I'm looking to remove modules for dead programs, such as hal and consolekit. 
The question is how long to keep modules for dead programs?  I'm thinking 
something like 3-5 years.

Also, please propose other modules that you think should be dropped.

-- 
Chris PeBenito

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] Purging dead modules
  2021-01-11 14:48 [RFC] Purging dead modules Chris PeBenito
@ 2021-01-11 15:23 ` Dominick Grift
  2021-01-11 15:48   ` Russell Coker
  0 siblings, 1 reply; 7+ messages in thread
From: Dominick Grift @ 2021-01-11 15:23 UTC (permalink / raw)
  To: Chris PeBenito; +Cc: refpolicy

Chris PeBenito <pebenito@ieee.org> writes:

> I'm looking to remove modules for dead programs, such as hal and
> consolekit. The question is how long to keep modules for dead
> programs?  I'm thinking something like 3-5 years.

Agree

some suggestions:

sectoolm, kdumpgui, kudzu, readahead, smoltclient, tmpreaper,
firewallgui, gift, podsleuth, ptchown, sambagui, yam, hotplug, pcmcia,
dnssectrigger, kerneloops, keyboardd, rhgb, roundup, speedtouch, w3c,
xprint

>
> Also, please propose other modules that you think should be dropped.

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] Purging dead modules
  2021-01-11 15:23 ` Dominick Grift
@ 2021-01-11 15:48   ` Russell Coker
  2021-01-11 23:52     ` Topi Miettinen
  0 siblings, 1 reply; 7+ messages in thread
From: Russell Coker @ 2021-01-11 15:48 UTC (permalink / raw)
  To: Dominick Grift; +Cc: Chris PeBenito, refpolicy

On Tuesday, 12 January 2021 2:23:47 AM AEDT Dominick Grift wrote:
> > I'm looking to remove modules for dead programs, such as hal and
> > consolekit. The question is how long to keep modules for dead
> > programs?  I'm thinking something like 3-5 years.
> 
> Agree

I think we should drop them when the programs aren't in the latest DEVELOPMENT 
versions of Fedora, Debian, or any other distribution that supports SE Linux.  

The new policy will only be used by new versions of those distributions.  
Running a newer version of policy on an older version will not provide any 
benefits and in some cases won't work properly.  People should NOT expect the 
Git refpolicy to work well on Debian/Buster, if they try it they shouldn't 
expect much help from me.  While I have a general aim that you should be able 
to upgrade kernel, SE Linux policy (and things that get dragged in with it 
like libc), and applications separately this isn't a guarantee.  If Debian/
Unstable doesn't include a daemon then I have no interest in supporting that 
daemon with SE Linux policy in Debian/Unstable.  People can migrate their 
configuration to the replacement daemon as part of the process of upgrading SE 
Linux policy.

Distributions like Fedora have a stronger binding between policy and daemons 
than Debian does, and RHEL has an even stronger binding.

That said, Debian tends to keep daemons longer than most distributions.  If a 
daemon doesn't have known security issues and some people like using it then 
it stays in the archive.  When Debian keeps a daemon that loses support 
upstream your REALLY want good SE Linux policy for it!
 
> some suggestions:
> 
> sectoolm, kdumpgui, kudzu, readahead, smoltclient, tmpreaper,
> firewallgui, gift, podsleuth, ptchown, sambagui, yam, hotplug, pcmcia,
> dnssectrigger, kerneloops, keyboardd, rhgb, roundup, speedtouch, w3c,
> xprint

kerneloops is still in Debian/Unstable and running on some of my Debian/
Unstable machines.

In Debian/Unstable /etc/init.d/mountnfs-bootclean.sh has type 
tmpreaper_exec_t, so this is still being used.  But I am up for a discussion 
about other ways of doing this.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] Purging dead modules
  2021-01-11 15:48   ` Russell Coker
@ 2021-01-11 23:52     ` Topi Miettinen
  2021-01-13 13:21       ` Chris PeBenito
  0 siblings, 1 reply; 7+ messages in thread
From: Topi Miettinen @ 2021-01-11 23:52 UTC (permalink / raw)
  To: Russell Coker, Dominick Grift; +Cc: Chris PeBenito, refpolicy

On 11.1.2021 17.48, Russell Coker wrote:
> On Tuesday, 12 January 2021 2:23:47 AM AEDT Dominick Grift wrote:
>>> I'm looking to remove modules for dead programs, such as hal and
>>> consolekit. The question is how long to keep modules for dead
>>> programs?  I'm thinking something like 3-5 years.
>>
>> Agree
> 
> I think we should drop them when the programs aren't in the latest DEVELOPMENT
> versions of Fedora, Debian, or any other distribution that supports SE Linux.

I think this could be automated. If no file contexts in a module match 
any files in a list of all files of all packages of the selected distros 
concatenated, the module is probably obsolete (which could be also 
verified by looking at old releases) or it's for 3rd party software 
(never found in earlier distro releases). I tried to do this locally to 
disable unused modules, but it took way too long time with shell 
scripts. I suppose with a database or other proper tools it would be 
trivial.

> The new policy will only be used by new versions of those distributions.
> Running a newer version of policy on an older version will not provide any
> benefits and in some cases won't work properly.  People should NOT expect the
> Git refpolicy to work well on Debian/Buster, if they try it they shouldn't
> expect much help from me.  While I have a general aim that you should be able
> to upgrade kernel, SE Linux policy (and things that get dragged in with it
> like libc), and applications separately this isn't a guarantee.  If Debian/
> Unstable doesn't include a daemon then I have no interest in supporting that
> daemon with SE Linux policy in Debian/Unstable.  People can migrate their
> configuration to the replacement daemon as part of the process of upgrading SE
> Linux policy.

As a Debian user, I've actually found that upstream refpolicy works 
somewhat better (as in less need to fix things by adding local rules) 
for unstable and especially when I'm building software myself directly 
from upstream, which may need the latest policy to work. Of course 
developing the reference policy is also easier when using upstream master.

-Topi

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] Purging dead modules
  2021-01-11 23:52     ` Topi Miettinen
@ 2021-01-13 13:21       ` Chris PeBenito
  2021-01-13 13:33         ` Dominick Grift
  0 siblings, 1 reply; 7+ messages in thread
From: Chris PeBenito @ 2021-01-13 13:21 UTC (permalink / raw)
  To: Topi Miettinen, Russell Coker, Dominick Grift; +Cc: refpolicy

On 1/11/21 6:52 PM, Topi Miettinen wrote:
> On 11.1.2021 17.48, Russell Coker wrote:
>> On Tuesday, 12 January 2021 2:23:47 AM AEDT Dominick Grift wrote:
>>>> I'm looking to remove modules for dead programs, such as hal and
>>>> consolekit. The question is how long to keep modules for dead
>>>> programs?  I'm thinking something like 3-5 years.
>>>
>>> Agree
>>
>> I think we should drop them when the programs aren't in the latest DEVELOPMENT
>> versions of Fedora, Debian, or any other distribution that supports SE Linux.
> 
> I think this could be automated. If no file contexts in a module match any files 
> in a list of all files of all packages of the selected distros concatenated, the 
> module is probably obsolete (which could be also verified by looking at old 
> releases) or it's for 3rd party software (never found in earlier distro 
> releases). I tried to do this locally to disable unused modules, but it took way 
> too long time with shell scripts. I suppose with a database or other proper 
> tools it would be trivial.

This is a good idea, but may be a problem for the Gentoo guys.

I'd probably simplify it to only looking at labels for executables, since a 
package's manifest might not hit all of the data files' entries.

-- 
Chris PeBenito

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] Purging dead modules
  2021-01-13 13:21       ` Chris PeBenito
@ 2021-01-13 13:33         ` Dominick Grift
  2021-01-19 15:11           ` Chris PeBenito
  0 siblings, 1 reply; 7+ messages in thread
From: Dominick Grift @ 2021-01-13 13:33 UTC (permalink / raw)
  To: Chris PeBenito; +Cc: Topi Miettinen, Russell Coker, refpolicy

Chris PeBenito <pebenito@ieee.org> writes:

> On 1/11/21 6:52 PM, Topi Miettinen wrote:
>> On 11.1.2021 17.48, Russell Coker wrote:
>>> On Tuesday, 12 January 2021 2:23:47 AM AEDT Dominick Grift wrote:
>>>>> I'm looking to remove modules for dead programs, such as hal and
>>>>> consolekit. The question is how long to keep modules for dead
>>>>> programs?  I'm thinking something like 3-5 years.
>>>>
>>>> Agree
>>>
>>> I think we should drop them when the programs aren't in the latest DEVELOPMENT
>>> versions of Fedora, Debian, or any other distribution that supports SE Linux.
>> I think this could be automated. If no file contexts in a module
>> match any files in a list of all files of all packages of the
>> selected distros concatenated, the module is probably obsolete
>> (which could be also verified by looking at old releases) or it's
>> for 3rd party software (never found in earlier distro releases). I
>> tried to do this locally to disable unused modules, but it took way
>> too long time with shell scripts. I suppose with a database or other
>> proper tools it would be trivial.
>
> This is a good idea, but may be a problem for the Gentoo guys.
>
> I'd probably simplify it to only looking at labels for executables,
> since a package's manifest might not hit all of the data files'
> entries.

Not sure if it is worth the trouble to automate this. The list of candidates I came up with
were also verified by just using `dnf whatprovides /usr/bin/app` to see
if it returns. Most modules though are still relevant and it's is pretty
obvious that they are still relevant. So I would argue that spending
half an hour perusing the refpolicy and looking for candidates, then
verifying is enough to atleast identify the most obvious candidates for
removal.

In reply to Russell Coker and kerneloops: Does kerneloops not depend on
kerneloops.org? AFAIK that site is offline so not sure how Debian still
expects kerneloops to still work?

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] Purging dead modules
  2021-01-13 13:33         ` Dominick Grift
@ 2021-01-19 15:11           ` Chris PeBenito
  0 siblings, 0 replies; 7+ messages in thread
From: Chris PeBenito @ 2021-01-19 15:11 UTC (permalink / raw)
  To: Dominick Grift; +Cc: Topi Miettinen, Russell Coker, refpolicy

On 1/13/21 8:33 AM, Dominick Grift wrote:
> Chris PeBenito <pebenito@ieee.org> writes:
> 
>> On 1/11/21 6:52 PM, Topi Miettinen wrote:
>>> On 11.1.2021 17.48, Russell Coker wrote:
>>>> On Tuesday, 12 January 2021 2:23:47 AM AEDT Dominick Grift wrote:
>>>>>> I'm looking to remove modules for dead programs, such as hal and
>>>>>> consolekit. The question is how long to keep modules for dead
>>>>>> programs?  I'm thinking something like 3-5 years.
>>>>>
>>>>> Agree
>>>>
>>>> I think we should drop them when the programs aren't in the latest DEVELOPMENT
>>>> versions of Fedora, Debian, or any other distribution that supports SE Linux.
>>> I think this could be automated. If no file contexts in a module
>>> match any files in a list of all files of all packages of the
>>> selected distros concatenated, the module is probably obsolete
>>> (which could be also verified by looking at old releases) or it's
>>> for 3rd party software (never found in earlier distro releases). I
>>> tried to do this locally to disable unused modules, but it took way
>>> too long time with shell scripts. I suppose with a database or other
>>> proper tools it would be trivial.
>>
>> This is a good idea, but may be a problem for the Gentoo guys.
>>
>> I'd probably simplify it to only looking at labels for executables,
>> since a package's manifest might not hit all of the data files'
>> entries.
> 
> Not sure if it is worth the trouble to automate this. The list of candidates I came up with
> were also verified by just using `dnf whatprovides /usr/bin/app` to see
> if it returns. Most modules though are still relevant and it's is pretty
> obvious that they are still relevant. So I would argue that spending
> half an hour perusing the refpolicy and looking for candidates, then
> verifying is enough to atleast identify the most obvious candidates for
> removal.
> 
> In reply to Russell Coker and kerneloops: Does kerneloops not depend on
> kerneloops.org? AFAIK that site is offline so not sure how Debian still
> expects kerneloops to still work?

I've created a pull request on GitHub to remove modules:

https://github.com/SELinuxProject/refpolicy/pull/335

I will be merging it at the end of the week unless there are any further objections.

-- 
Chris PeBenito

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, back to index

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-11 14:48 [RFC] Purging dead modules Chris PeBenito
2021-01-11 15:23 ` Dominick Grift
2021-01-11 15:48   ` Russell Coker
2021-01-11 23:52     ` Topi Miettinen
2021-01-13 13:21       ` Chris PeBenito
2021-01-13 13:33         ` Dominick Grift
2021-01-19 15:11           ` Chris PeBenito

SELinux-Refpolicy Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/selinux-refpolicy/0 selinux-refpolicy/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux-refpolicy selinux-refpolicy/ https://lore.kernel.org/selinux-refpolicy \
		selinux-refpolicy@vger.kernel.org
	public-inbox-index selinux-refpolicy

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.selinux-refpolicy


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git