2016-05-26 13:49:32

by Laurent Bigonville

[permalink] [raw]
Subject: [refpolicy] resolv.conf managed by NetworkManager or networkd

Hello,

On systems running NetworkManager or systemd-networkd, the resolv.conf
file is managed by that daemon and written in some private directory
(/var/run/NetworkManager or /run/systemd/resolve/). A symlink
/etc/resolv.conf is then created.

That means that application should be able to read a file that will be
labeled as NetworkManager_var_run_t (or some other private type for
networkd). One of the idea what to modify the sysnet_read_config()
interface but this lead to compilation is due to boolean/optional policy
mix.

An idea how to fix that?

Cheers,

Laurent Bigonville


2016-05-26 14:32:57

by Dominick Grift

[permalink] [raw]
Subject: [refpolicy] resolv.conf managed by NetworkManager or networkd

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/26/2016 03:49 PM, Laurent Bigonville wrote:
> Hello,
>
> On systems running NetworkManager or systemd-networkd, the
> resolv.conf file is managed by that daemon and written in some
> private directory (/var/run/NetworkManager or
> /run/systemd/resolve/). A symlink /etc/resolv.conf is then
> created.
>
> That means that application should be able to read a file that will
> be labeled as NetworkManager_var_run_t (or some other private type
> for networkd). One of the idea what to modify the
> sysnet_read_config() interface but this lead to compilation is due
> to boolean/optional policy mix.
>
> An idea how to fix that?
>

Yes, go down the rabbit hole and make it so that you can have
optionals in the sysnet_read_config() interface. Because sysnet config
can be in:

1. /etc/resolv.conf
2. /var/run/systemd/systemd-resolved/resolv.conf
3. /var/run/NetworkManager/resolv.conf

Start by identifying the conflicts. When you have them all commented
out, and have the compiler happy, start thinking about alternate ways
to get the commented functionality to work in an acceptable manner.

It will probably be tough to get this sorted out, but i think it is
probably inevitable.

> Cheers,
>
> Laurent Bigonville
>
> _______________________________________________ refpolicy mailing
> list refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>


- --
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJXRwkUAAoJECV0jlU3+UdpuzIL/Ra7fv4x8c4YnnWtZAgGGsCb
a3B0FpGdRlxyXjq8r0SRHMZtdmDuki6szkJJmWedtJLzzuRRyIyfwXxoaiqe5/J+
9xODlw0oDj2iKP6yq4Y0awkbuYz0Gs8DfTfJEyHNozauiRzGAXwtfrM4gQFoouhX
baJE/YpWQC7Hu5y0CnClZr+3t2fn5aRfBzj2pClJ2zLbuT3xhRERnOaW1WYOl/Si
SEcm1KmhKJgTHCilVqrMPQ7w4yTmFYSSQt1enYdfxw8RDpPreWt/FDNcEfUbMwQq
aQv3gB+Nf5UTF1hVx4Jx3oa45xFW+ikH22bvypXDNhjUhkN/at9V26/PCYyUIASI
DPM8QVLv188fue7cnrUfziOJTEMRAN2iCJBJPxyJGBjqlOPnMG13xUvFAOMxMNv5
gS0PCuPlfHA/pW9mj66NRb+iiTt4lMFJObGZSJcu1Z62KkpSoiJULQozFZIXZe66
zWJ+BEL82jwT4Uln70j0uzdmuVtI4+NgIoO2o1FHVw==
=E8ZK
-----END PGP SIGNATURE-----

2016-05-27 15:11:00

by cpebenito

[permalink] [raw]
Subject: [refpolicy] resolv.conf managed by NetworkManager or networkd

On 5/26/2016 9:49 AM, Laurent Bigonville wrote:
> Hello,
>
> On systems running NetworkManager or systemd-networkd, the resolv.conf
> file is managed by that daemon and written in some private directory
> (/var/run/NetworkManager or /run/systemd/resolve/). A symlink
> /etc/resolv.conf is then created.
>
> That means that application should be able to read a file that will be
> labeled as NetworkManager_var_run_t (or some other private type for
> networkd). One of the idea what to modify the sysnet_read_config()
> interface but this lead to compilation is due to boolean/optional policy
> mix.
>
> An idea how to fix that?

>From doing a little searching, I assume the problem is with
sysnet_read_config() being in the allow_ypbind conditional? It would
put an optional inside a conditional, which isn't allowed by the compiler.

Is a named filetrans impossible to work for this situation, so when the
two services create it the file it still ends up net_conf_t?

--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com

2016-05-27 15:13:55

by Dominick Grift

[permalink] [raw]
Subject: [refpolicy] resolv.conf managed by NetworkManager or networkd

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/27/2016 05:11 PM, Christopher J. PeBenito wrote:
> On 5/26/2016 9:49 AM, Laurent Bigonville wrote:
>> Hello,
>>
>> On systems running NetworkManager or systemd-networkd, the
>> resolv.conf file is managed by that daemon and written in some
>> private directory (/var/run/NetworkManager or
>> /run/systemd/resolve/). A symlink /etc/resolv.conf is then
>> created.
>>
>> That means that application should be able to read a file that
>> will be labeled as NetworkManager_var_run_t (or some other
>> private type for networkd). One of the idea what to modify the
>> sysnet_read_config() interface but this lead to compilation is
>> due to boolean/optional policy mix.
>>
>> An idea how to fix that?
>
>> From doing a little searching, I assume the problem is with
> sysnet_read_config() being in the allow_ypbind conditional? It
> would put an optional inside a conditional, which isn't allowed by
> the compiler.
>
> Is a named filetrans impossible to work for this situation, so when
> the two services create it the file it still ends up net_conf_t?
>

That still wouldnt work since callers of sysnet_read_config would
still need to traverse NetworkManager and systemd-resolved runtime
dirs to get to /run/NetworkManager/resolv.conf and
/run/systemd/systemd-resolved/resolv.conf

Unless you want to make sysnet depend on the networkmanager and
systemd modules

- --
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJXSGQuAAoJECV0jlU3+UdpUfML/0uOm0CXaNyze5Np0yKHwGyM
k1/ELPjJyOmjQz1bgQCUvpC8XOsAskqAXuHM/c2PrW0KkzzPogFzCCXWWAW6AEsE
zR5bUdUg4LyI7LWHKfBY+H7JMUmIal//D9BLaOjNY6P5UWWl5O6kAYvcgFua5SmL
I5Fo0IicFhNjDBbDzIThjBLyPQuxkmiSPLd2pC1XCLfO5FlB3vQKBc9bvLVD1a/N
cfVTmZbe8VI08BsFB0osyz7jCfSucv9ZMt2jqHVfraq31npK/VxkDlUnK0/rzG4n
S/3yX98QFtWjdGnpdflpLgD22ZnfjQLdT9qxLoWxGysyRpVeJq1vWhXqZk3jJnRs
0q2QTfzCNONxLPtlz2cRz0qxHSRbSXQpUsG7YnRiWsSbn6cf9EAWsWccfsoVLCp5
4wIlYGJ9h7SOuiTA5Yrne7kVlEOz2rwt4fdXzoiaxzUhUFxhvNS/K0vH8N4WUvhy
fBU2uYit0pboeVrwA3WG3ohGKBWoutUWtyZdcHdAKw==
=4zvK
-----END PGP SIGNATURE-----