| 1 |
On Wed, 4 Mar 2015 20:21:08 +0000 |
| 2 |
Sven Vermeulen <swift@g.o> wrote: |
| 3 |
|
| 4 |
> 1. I can temporarily ignore the issue, perhaps hiding the cosmetic |
| 5 |
> denial behind dontaudit statements |
| 6 |
> 2. I can restrictively add to kernel_t those rules that do not |
| 7 |
> trigger the neverallow rules and ignore/dontaudit the rest |
| 8 |
> 3. I can break isolation a bit and explicitly add kernel_t to the |
| 9 |
> neverallow rule exemption |
| 10 |
> 4. I can move the necessary attributes and statements into the devices |
| 11 |
> module (which is part of the base) |
| 12 |
> 5. I can move forward with the storage-becomes-base approach |
| 13 |
|
| 14 |
I've been allowing this in my local policy since 2013. I'm sure it was |
| 15 |
neccessary for something to work, however I don't recall what for. But |
| 16 |
that means 1. is not really an option. |
| 17 |
|
| 18 |
For now, I'd just wait for more feedback on the refpolicy ML. This is |
| 19 |
not an urgent problem, so I'd prefer not to diverge further from |
| 20 |
upstream if we can avoid it. |
| 21 |
|
| 22 |
5. seems to be the cleanest solution, but I've got to dig around a bit |
| 23 |
in the refpolicy to estimate the amount of work it'd require. |
| 24 |
|
| 25 |
If we want a temporary fix, I'd go with 3. It's only a tiny change, so |
| 26 |
it wouldn't cause too much confusing upstream divergence. |
| 27 |
|
| 28 |
|
| 29 |
|
| 30 |
-- |
| 31 |
Luis Ressel <aranea@×××××.de> |
| 32 |
GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD |
Archives