1 |
Hi, |
2 |
|
3 |
On Sun, Jun 10, 2007 at 02:32:35PM +0200, Krzysztof Kozłowski wrote: |
4 |
> Marek Wróbel wrote: |
5 |
> > But there are many modules that are included in refpolicy, but they are |
6 |
> > not packaged in gentoo packages and have to be installed by hand. You |
7 |
> > can make local portage overlay and create ebuilds for them. It isn't |
8 |
> > much work, because of selinux-policy-2 eclass. |
9 |
> I figured it out and I still wonder why such easy to write ebuilds are not in |
10 |
> Portage... Is there any reason for that? |
11 |
|
12 |
it's true, it would be easy to add a bunch of new ebuilds for the refpolicy modules. |
13 |
|
14 |
on the other hand it is not easy to make sure that the newly covered software (as installed by gentoo) actually works with the policy. |
15 |
|
16 |
if you have a software package not covered by a sec-policy/selinux-~ ebuild, you are encouraged to do the following: |
17 |
- test if the refpolicy module works with your setup |
18 |
- open a bug report stating that module foo should have a selinux-foo ebuild, assign it to selinux@g.o |
19 |
|
20 |
to accomplish the first task, you can do the following: |
21 |
- see if a module for package foo exists by consulting [1] |
22 |
- create a tiny ebuild that uses the selinux-policy-2 eclass and emerge that |
23 |
- relabel files that belong to package foo (using either `rlpkg foo` or `/usr/sbin/setfiles -v /etc/selinux/strict/contexts/files/file_contexts $PATH`) |
24 |
- use foo as you normally would and look for problems |
25 |
|
26 |
that being said, it's not like you'll need to do any of this for most software, that has been taken care of. but you have to understand that we do not actively use all the available modules on our servers, and thus not all modules have a sec-policy ebuild associated. |
27 |
|
28 |
[1] http://oss.tresys.com/docs/refpolicy/api/ |
29 |
|
30 |
-- |
31 |
petre rodan |
32 |
<kaiowas@g.o> |
33 |
Developer, |
34 |
Hardened Gentoo Linux |