: patch to allow networkmanager dbus chat

This patch allows dbus chat between networkmanager and dbus and between networkmanager and xdm. It also adds a missing permission (sysnet_read_dhcpc_state) to the networkmanager module.

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/dbus.te refpolicy-git-15022011-new-modified/policy/modules/services/dbus.te

policy/modules/services/dbus.te +4 -0

@@ -156,6 +156,10 @@ optional_policy(`
 ')
 
 optional_policy(`
+	networkmanager_dbus_chat(system_dbusd_t)
+')
+
+optional_policy(`
 	policykit_dbus_chat(system_dbusd_t)
 	policykit_domtrans_auth(system_dbusd_t)
 	policykit_search_lib(system_dbusd_t)

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/networkmanager.te refpolicy-git-15022011-new-modified/policy/modules/services/networkmanager.te

policy/modules/services/networkmanager.te +1 -0

@@ -141,6 +141,7 @@ sysnet_domtrans_ifconfig(NetworkManager_
 sysnet_domtrans_dhcpc(NetworkManager_t)
 sysnet_signal_dhcpc(NetworkManager_t)
 sysnet_read_dhcpc_pid(NetworkManager_t)
+sysnet_read_dhcpc_state(NetworkManager_t)
 sysnet_delete_dhcpc_pid(NetworkManager_t)
 sysnet_search_dhcp_state(NetworkManager_t)
 # in /etc created by NetworkManager will be labelled net_conf_t.

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/xserver.te refpolicy-git-15022011-new-modified/policy/modules/services/xserver.te

Quoted 35 lines · Guido Trentalancia

This patch allows dbus chat between networkmanager and dbus and between networkmanager and xdm. It also adds a missing permission (sysnet_read_dhcpc_state) to the networkmanager module.

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/dbus.te refpolicy-git-15022011-new-modified/policy/modules/services/dbus.te

policy/modules/services/dbus.te +4 -0

@@ -156,6 +156,10 @@ optional_policy(`
 ')
 
 optional_policy(`
+	networkmanager_dbus_chat(system_dbusd_t)
+')
+
+optional_policy(`
 	policykit_dbus_chat(system_dbusd_t)
 	policykit_domtrans_auth(system_dbusd_t)
 	policykit_search_lib(system_dbusd_t)

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/networkmanager.te refpolicy-git-15022011-new-modified/policy/modules/services/networkmanager.te

policy/modules/services/networkmanager.te +1 -0

@@ -141,6 +141,7 @@ sysnet_domtrans_ifconfig(NetworkManager_
 sysnet_domtrans_dhcpc(NetworkManager_t)
 sysnet_signal_dhcpc(NetworkManager_t)
 sysnet_read_dhcpc_pid(NetworkManager_t)
+sysnet_read_dhcpc_state(NetworkManager_t)
 sysnet_delete_dhcpc_pid(NetworkManager_t)
 sysnet_search_dhcp_state(NetworkManager_t)
 # in /etc created by NetworkManager will be labelled net_conf_t.

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/xserver.te refpolicy-git-15022011-new-modified/policy/modules/services/xserver.te

policy/modules/services/xserver.te +0 -0

@@ -548,6 +548,10 @@ optional_policy(`
 ')
 

policy/modules/services/xserver.te optional_policy(` · line 552

Quoted 3 lines

policy/modules/services/xserver.te +2 -0

 optional_policy(`
+	networkmanager_dbus_chat(xdm_t)
+')

Is there something new with xdm? I'm concerned that more dbus communications are added (this patch and others) with seemingly unrelated services.

Hello Christopher !

Quoted 36 lines · Christopher J. PeBenito

Quoted 35 lines · Guido Trentalancia

This patch allows dbus chat between networkmanager and dbus and between networkmanager and xdm. It also adds a missing permission (sysnet_read_dhcpc_state) to the networkmanager module.

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/dbus.te refpolicy-git-15022011-new-modified/policy/modules/services/dbus.te

policy/modules/services/dbus.te +4 -0

@@ -156,6 +156,10 @@ optional_policy(`
 ')
 
 optional_policy(`
+	networkmanager_dbus_chat(system_dbusd_t)
+')
+
+optional_policy(`
 	policykit_dbus_chat(system_dbusd_t)
 	policykit_domtrans_auth(system_dbusd_t)
 	policykit_search_lib(system_dbusd_t)

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/networkmanager.te refpolicy-git-15022011-new-modified/policy/modules/services/networkmanager.te

policy/modules/services/networkmanager.te +1 -0

@@ -141,6 +141,7 @@ sysnet_domtrans_ifconfig(NetworkManager_
 sysnet_domtrans_dhcpc(NetworkManager_t)
 sysnet_signal_dhcpc(NetworkManager_t)
 sysnet_read_dhcpc_pid(NetworkManager_t)
+sysnet_read_dhcpc_state(NetworkManager_t)
 sysnet_delete_dhcpc_pid(NetworkManager_t)
 sysnet_search_dhcp_state(NetworkManager_t)
 # in /etc created by NetworkManager will be labelled net_conf_t.

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/xserver.te refpolicy-git-15022011-new-modified/policy/modules/services/xserver.te

policy/modules/services/xserver.te +0 -0

@@ -548,6 +548,10 @@ optional_policy(`
 ')
 

Quoted 7 lines

policy/modules/services/xserver.te optional_policy(` · line 552

Quoted 3 lines

policy/modules/services/xserver.te +2 -0

 optional_policy(`
+	networkmanager_dbus_chat(xdm_t)
+')

Is there something new with xdm? I'm concerned that more dbus communications are added (this patch and others) with seemingly unrelated services.

What you mean exactly for "something new with xdm" ? Do you mean new features ?

And what do you mean for unrelated services exactly ? NetworkManager not being very much related to xdm ?

Yes, it's not entirely clear to me
either. But could be that due to the applet ?

More or less I have reported back what was being requested (in the form of a patch).

Quoted 47 lines · Guido Trentalancia

Hello Christopher !

Quoted 43 lines · Christopher J. PeBenito

Quoted 33 lines · Guido Trentalancia

This patch allows dbus chat between networkmanager and dbus and between networkmanager and xdm. It also adds a missing permission (sysnet_read_dhcpc_state) to the networkmanager module.

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/dbus.te refpolicy-git-15022011-new-modified/policy/modules/services/dbus.te

policy/modules/services/dbus.te +4 -0

@@ -156,6 +156,10 @@ optional_policy(`
 ')
 
 optional_policy(`
+	networkmanager_dbus_chat(system_dbusd_t)
+')
+
+optional_policy(`
 	policykit_dbus_chat(system_dbusd_t)
 	policykit_domtrans_auth(system_dbusd_t)
 	policykit_search_lib(system_dbusd_t)

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/networkmanager.te refpolicy-git-15022011-new-modified/policy/modules/services/networkmanager.te

policy/modules/services/networkmanager.te +1 -0

@@ -141,6 +141,7 @@ sysnet_domtrans_ifconfig(NetworkManager_
 sysnet_domtrans_dhcpc(NetworkManager_t)
 sysnet_signal_dhcpc(NetworkManager_t)
 sysnet_read_dhcpc_pid(NetworkManager_t)
+sysnet_read_dhcpc_state(NetworkManager_t)
 sysnet_delete_dhcpc_pid(NetworkManager_t)
 sysnet_search_dhcp_state(NetworkManager_t)
 # in /etc created by NetworkManager will be labelled net_conf_t.

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/xserver.te refpolicy-git-15022011-new-modified/policy/modules/services/xserver.te

policy/modules/services/xserver.te optional_policy(` · line 552

Quoted 5 lines

policy/modules/services/xserver.te +2 -0

@@ -548,6 +548,10 @@ optional_policy(`
 ')
 
 optional_policy(`
+	networkmanager_dbus_chat(xdm_t)
+')

Is there something new with xdm? I'm concerned that more dbus communications are added (this patch and others) with seemingly unrelated services.

Quoted 2 lines

What you mean exactly for "something new with xdm" ? Do you mean new features ?

Yes.

Quoted 2 lines

And what do you mean for unrelated services exactly ? NetworkManager not being very much related to xdm ?

Yes.

Quoted 2 lines

Yes, it's not entirely clear to me
either. But could be that due to the applet ?

I assume you mean the one that runs in the gnome panel. If so, I wouldn't think so, since that would be running in the user's domain.

Quoted 2 lines

More or less I have reported back what was being requested (in the form of a patch).

It makes me wonder if everything is running in the right domain.

Quoted 8 lines · Christopher J. PeBenito

Quoted 7 lines · Guido Trentalancia

Hello Christopher !

Quoted 4 lines · Christopher J. PeBenito

Quoted 3 lines · Guido Trentalancia

This patch allows dbus chat between networkmanager and dbus and between networkmanager and xdm. It also adds a missing permission (sysnet_read_dhcpc_state) to the networkmanager module.

Quoted 11 lines

Quoted 11 lines

Quoted 9 lines

policy/modules/services/xserver.te optional_policy(` · line 552

Quoted 9 lines

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/xserver.te refpolicy-git-15022011-new-modified/policy/modules/services/xserver.te

policy/modules/services/xserver.te +2 -0

@@ -548,6 +548,10 @@ optional_policy(`
 ')
 
 optional_policy(`
+	networkmanager_dbus_chat(xdm_t)
+')

More or less I have reported back what was being requested (in the form of a patch).

Quoted 1 line

It makes me wonder if everything is running in the right domain.

That could be. But I have not been provided with a reference. So, can you provide a reference ps auxZ which then I will compare as soon as I can access the test system again ?

Also, what do you think about the idea of providing a make target (say "make check") in refpolicy which runs some minimal checks on that for at least the core processes ?

Quoted 9 lines · Guido Trentalancia

Quoted 8 lines · Christopher J. PeBenito

Quoted 7 lines · Guido Trentalancia

Hello Christopher !

Quoted 4 lines · Christopher J. PeBenito

Quoted 3 lines · Guido Trentalancia

This patch allows dbus chat between networkmanager and dbus and between networkmanager and xdm. It also adds a missing permission (sysnet_read_dhcpc_state) to the networkmanager module.

[cut]

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 9 lines

policy/modules/services/xserver.te optional_policy(` · line 552

Quoted 9 lines

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/xserver.te refpolicy-git-15022011-new-modified/policy/modules/services/xserver.te

policy/modules/services/xserver.te +2 -0

@@ -548,6 +548,10 @@ optional_policy(`
 ')
 
 optional_policy(`
+	networkmanager_dbus_chat(xdm_t)
+')

More or less I have reported back what was being requested (in the form of a patch).

Quoted 4 lines

Quoted 1 line

It makes me wonder if everything is running in the right domain.

That could be. But I have not been provided with a reference. So, can you provide a reference ps auxZ which then I will compare as soon as I can access the test system again ?

It would be simpler if you could provide the ps output. The only process that should be running in xdm_t should be xdm/gdm/kdm. If your nm-applet is running in xdm_t, it is wrong. It should be running in the user's domain.

Quoted 3 lines

Also, what do you think about the idea of providing a make target (say "make check") in refpolicy which runs some minimal checks on that for at least the core processes ?

I can't think of how that would work off the top of my head. If you have ideas, I'd be happy to listen. I'd prefer to not write a script that has all of the checking hard coded in it.

What
I meant for "everything is running as xdm_t" is that as a normal user if
you type "id -Z" from the gnome-terminal, then you get xdm_t (which still looks suspicious to me).

It's just something very simple. A make target which runs ps axZ (as sysadm) and compares a few very basic things:

- if init has properly transitioned to its context (apparently at the moment no one cares if it hasn't, which is quite worrying as everything

By the way, Tresys' SMTP server is blocking some mail from dynamically allocated mobile Internet connections (using barracudanetworks.com). I

think my latest reply was not the proper answer to your question.

Quoted 5 lines

What
I meant for "everything is running as xdm_t" is that as a normal user if
you type "id -Z" from the gnome-terminal, then you get xdm_t (which still looks suspicious to me).

That usually means that you don't have PAM configured correctly. Probably your xdm is not compiled with SE support and you are not using pam_selinux.so .

Quoted 5 lines

It's just something very simple. A make target which runs ps axZ (as sysadm) and compares a few very basic things:

- if init has properly transitioned to its context (apparently at the moment no one cares if it hasn't, which is quite worrying as everything

I am working on test VMs for Debian now and plan to do such things.

Quoted 2 lines

By the way, Tresys' SMTP server is blocking some mail from dynamically allocated mobile Internet connections (using barracudanetworks.com). I

You shoud configure your phone to send through a smart host. I am going to run such a server for SE testing, contact me off list for an account.

Quoted 5 lines

Quoted 5 lines

It's just something very simple. A make target which runs ps axZ (as sysadm) and compares a few very basic things:

- if init has properly transitioned to its context (apparently at

the

Quoted 1 line

Quoted 1 line

moment no one cares if it hasn't, which is quite worrying as

everything

Quoted 2 lines

I am working on test VMs for Debian now and plan to do such things.

Excellent. What do you mean for VMs ? In any case if you have time to do

it then please try to do something which applies to everybody and can then be customized for Debian

Quoted 1 line

You shoud configure your phone to send through a smart host. I am

going to run such a server for SE testing, contact me off list for an account.

Yes, of course if I change my SMTP server... But most people are not bothered of doing that. I think the idea behind stuff such as barracuda is good but unfortunately it does not be apply very well to the case of dynamically assigned addresses.

I had to reply on the list in any case because of the other issues. Perhaps you can send me an account off-list... The same thing happened with your address Russell.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

It's just something very simple. A make target which runs ps axZ (as sysadm) and compares a few very basic things:

- if init has properly transitioned to its context (apparently at

Quoted 8 lines

the

Quoted 1 line

Quoted 1 line

moment no one cares if it hasn't, which is quite worrying as

everything

Quoted 2 lines

I am working on test VMs for Debian now and plan to do such things.

Excellent. What do you mean for VMs ? In any case if you have time to do

I am going to setup virtual machines for testing different configurtions.

Quoted 2 lines

it then please try to do something which applies to everybody and can then be customized for Debian

For domain transitions it is mostly a matter of having a cron job or nagios entry that searches for wrong entries such as processes in kernel_t or initrc_t.

Quoted 8 lines

Quoted 1 line

You shoud configure your phone to send through a smart host. I am

going to run such a server for SE testing, contact me off list for an account.

Yes, of course if I change my SMTP server... But most people are not bothered of doing that. I think the idea behind stuff such as barracuda is good but unfortunately it does not be apply very well to the case of dynamically assigned addresses.

Blocking dynamic addresses is a standard practice. Everyone who is capable of doing free software development is capable of configuring their MUA.

Quoted 3 lines

I had to reply on the list in any case because of the other issues. Perhaps you can send me an account off-list... The same thing happened with your address Russell.

Ok

Quoted 3 lines

For domain transitions it is mostly a matter of having a cron job or nagios entry that searches for wrong entries such as processes in kernel_t or initrc_t.

What's wrong with just a "make check" target in refpolicy ?

There is major limitation with this: reboot and/or restarting of services required. In the simple solution that I was thinking of, this limitation could be documented and printed out: echo $limitation ; sleep 10 ; carry out basic sanity checks.

Quoted 5 lines · Guido Trentalancia

Quoted 3 lines

For domain transitions it is mostly a matter of having a cron job or nagios entry that searches for wrong entries such as processes in kernel_t or initrc_t.

What's wrong with just a "make check" target in refpolicy ?

It just doesn't work.

The main problem I've found in transitions not working is binaries getting renamed, which "make check" can never find.

The next issue is application misconfiguration, such as an xdm program not having the correct PAM configuration, again it's not something that you can check through policy.

Quoted 4 lines

There is major limitation with this: reboot and/or restarting of services required. In the simple solution that I was thinking of, this limitation could be documented and printed out: echo $limitation ; sleep 10 ; carry out basic sanity checks.

Rebooting a VM is no big deal at all. It's something that can be done by a cron job.

Also I'd like to automate the process of an X login and running some applications in KDE and GNOME sessions. Any suggestions of how to do this would be appreciated.

Quoted 2 lines

The main problem I've found in transitions not working is binaries getting renamed, which "make check" can never find.

But do you mean application or daemon binaries ? That would be classified as a labeling problem.

There are infinite degrees of freedom with the naming of executables (not necessary "binaries"). I suppose that the reference policy targets a reference system.

And the reference system is an upstream system.

And
upstream systems should have no degrees of freedom on the naming of executables.

Even if the reference system did not exactly coincide with an upstream system, the reference system would still be unique by definition (I don't know exactly, maybe it's a system being run at Tresys).

Quoted 3 lines

The next issue is application misconfiguration, such as an xdm program not having the correct PAM configuration, again it's not something that you can check through policy.

That's not a problem with refpolicy I think. That's a local misconfiguration (or even intentional).

Quoted 6 lines

Rebooting a VM is no big deal at all. It's something that can be done by a cron job.

Also I'd like to automate the process of an X login and running some applications in KDE and GNOME sessions. Any suggestions of how to do this would be appreciated.

Through xdmcp and/or x11 ports ? But I suppose a bit of compiled code (ideally C) would be required here. The applications could then be started automatically through the session manager (e.g. gnome-session configuration) ? Then after a few seconds the main script checks that everything is running in the proper context. Finally it kills everything and creates the report (or iterates for other configurations).

Quoted 22 lines · Christopher J. PeBenito

Quoted 9 lines · Guido Trentalancia

Quoted 8 lines · Christopher J. PeBenito

Quoted 7 lines · Guido Trentalancia

Hello Christopher !

Quoted 4 lines · Christopher J. PeBenito

Quoted 3 lines · Guido Trentalancia

This patch allows dbus chat between networkmanager and dbus and between networkmanager and xdm. It also adds a missing permission (sysnet_read_dhcpc_state) to the networkmanager module.

[cut]

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 9 lines

policy/modules/services/xserver.te optional_policy(` · line 552

Quoted 9 lines

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/xserver.te refpolicy-git-15022011-new-modified/policy/modules/services/xserver.te

policy/modules/services/xserver.te +2 -0

@@ -548,6 +548,10 @@ optional_policy(`
  ')
 
  optional_policy(`
+	networkmanager_dbus_chat(xdm_t)
+')

More or less I have reported back what was being requested (in the form of a patch).

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

It makes me wonder if everything is running in the right domain.

That could be. But I have not been provided with a reference. So, can you provide a reference ps auxZ which then I will compare as soon as I can access the test system again ?

It would be simpler if you could provide the ps output. The only process that should be running in xdm_t should be xdm/gdm/kdm. If your nm-applet is running in xdm_t, it is wrong. It should be running in the user's domain.

I think my latest reply was not the proper answer to your question. What I meant for "everything is running as xdm_t" is that as a normal user if you type "id -Z" from the gnome-terminal, then you get xdm_t (which still looks suspicious to me).

All the rest is running fine. So, for example,

NetworkManager -> system_u:system_r:NetworkManager_t wpa_supplicant -> -:-:-
ntpd -> -:-:ntpd_t
gdm -> -:-:xdm_t
polkitd -> -:-:policykit_t
hald -> -:-:hald_t
dbus-daemon -> -:-:system_dbusd_t
consolekit -> -:-:consolekit_t
avahi -> -:-:avahi_t

and so on...

Quoted 5 lines

Quoted 3 lines

Also, what do you think about the idea of providing a make target (say "make check") in refpolicy which runs some minimal checks on that for at least the core processes ?

I can't think of how that would work off the top of my head. If you have ideas, I'd be happy to listen. I'd prefer to not write a script that has all of the checking hard coded in it.

It's just something very simple. A make target which runs ps axZ (as sysadm) and compares a few very basic things:

- if init has properly transitioned to its context (apparently at the moment no one cares if it hasn't, which is quite worrying as everything could run in kernel_t without showing any symptom or warning);
- for a few core modules (as long as they are compiled in the policy), that they are running in the proper context: so for example if polkitd is running in policykit_t context (ps axZ | grep polkitd | grep policykit_t).

Of course you can avoid hardcoding the keywords "polkitd" and "policykit_d" as long as you can get that out of policykit.{te,fc} by the means of some other form of regexp matching and string processing (sed, awk) for example: something very simple, something very basic, still quite useful to the inexperienced user.

Quoted 47 lines · Guido Trentalancia

Quoted 22 lines · Christopher J. PeBenito

Quoted 9 lines · Guido Trentalancia

Quoted 8 lines · Christopher J. PeBenito

Quoted 7 lines · Guido Trentalancia

Hello Christopher !

Quoted 4 lines · Christopher J. PeBenito

Quoted 3 lines · Guido Trentalancia

This patch allows dbus chat between networkmanager and dbus and between networkmanager and xdm. It also adds a missing permission (sysnet_read_dhcpc_state) to the networkmanager module.

[cut]

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 9 lines

policy/modules/services/xserver.te optional_policy(` · line 552

Quoted 9 lines

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/xserver.te refpolicy-git-15022011-new-modified/policy/modules/services/xserver.te

policy/modules/services/xserver.te +2 -0

@@ -548,6 +548,10 @@ optional_policy(`
  ')
 
  optional_policy(`
+	networkmanager_dbus_chat(xdm_t)
+')

More or less I have reported back what was being requested (in the form of a patch).

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

It makes me wonder if everything is running in the right domain.

That could be. But I have not been provided with a reference. So, can you provide a reference ps auxZ which then I will compare as soon as I can access the test system again ?

It would be simpler if you could provide the ps output. The only process that should be running in xdm_t should be xdm/gdm/kdm. If your nm-applet is running in xdm_t, it is wrong. It should be running in the user's domain.

I think my latest reply was not the proper answer to your question. What I meant for "everything is running as xdm_t" is that as a normal user if you type "id -Z" from the gnome-terminal, then you get xdm_t (which still looks suspicious to me).

All the rest is running fine. So, for example,

NetworkManager -> system_u:system_r:NetworkManager_t wpa_supplicant -> -:-:-
ntpd -> -:-:ntpd_t
gdm -> -:-:xdm_t
polkitd -> -:-:policykit_t
hald -> -:-:hald_t
dbus-daemon -> -:-:system_dbusd_t
consolekit -> -:-:consolekit_t
avahi -> -:-:avahi_t

Quoted 1 line

and so on...

But what are your user sessions running as? eg. nm-applet, bash, etc.

Quoted 17 lines

Quoted 5 lines

Quoted 3 lines

Also, what do you think about the idea of providing a make target (say "make check") in refpolicy which runs some minimal checks on that for at least the core processes ?

I can't think of how that would work off the top of my head. If you have ideas, I'd be happy to listen. I'd prefer to not write a script that has all of the checking hard coded in it.

It's just something very simple. A make target which runs ps axZ (as sysadm) and compares a few very basic things:

- if init has properly transitioned to its context (apparently at the moment no one cares if it hasn't, which is quite worrying as everything could run in kernel_t without showing any symptom or warning);
- for a few core modules (as long as they are compiled in the policy), that they are running in the proper context: so for example if polkitd is running in policykit_t context (ps axZ | grep polkitd | grep policykit_t).

Quoted 5 lines

Of course you can avoid hardcoding the keywords "polkitd" and "policykit_d" as long as you can get that out of policykit.{te,fc} by the means of some other form of regexp matching and string processing (sed, awk) for example: something very simple, something very basic, still quite useful to the inexperienced user.

What you're describing is a big hardcoded script, which I'm trying to avoid.

Quoted 22 lines · Christopher J. PeBenito

Quoted 21 lines · Guido Trentalancia

Quoted 8 lines · Christopher J. PeBenito

Quoted 5 lines · Guido Trentalancia

Quoted 1 line · Christopher J. PeBenito

On 02/23/11 13:50, Guido Trentalancia wrote:

Also, what do you think about the idea of providing a make target (say "make check") in refpolicy which runs some minimal checks on that for at least the core processes ?

I can't think of how that would work off the top of my head. If you have ideas, I'd be happy to listen. I'd prefer to not write a script that has all of the checking hard coded in it.

It's just something very simple. A make target which runs ps axZ (as sysadm) and compares a few very basic things:

- if init has properly transitioned to its context (apparently at the moment no one cares if it hasn't, which is quite worrying as everything could run in kernel_t without showing any symptom or warning);
- for a few core modules (as long as they are compiled in the policy), that they are running in the proper context: so for example if polkitd is running in policykit_t context (ps axZ | grep polkitd | grep policykit_t).

Quoted 7 lines

Quoted 5 lines

Of course you can avoid hardcoding the keywords "polkitd" and "policykit_d" as long as you can get that out of policykit.{te,fc} by the means of some other form of regexp matching and string processing (sed, awk) for example: something very simple, something very basic, still quite useful to the inexperienced user.

What you're describing is a big hardcoded script, which I'm trying to avoid.

More or less this what I meant:

check:

	ps axZ | grep init | grep -q init_t || echo "FAIL: init has not

transitioned properly to its context"

and so on for the a few other basic first-line context checks.

If you don't like it, it doesn't matter. Any test needs at least to have the reference results "hardcoded".

Quoted 39 lines · Guido Trentalancia

Quoted 22 lines · Christopher J. PeBenito

Quoted 21 lines · Guido Trentalancia

Quoted 8 lines · Christopher J. PeBenito

Quoted 5 lines · Guido Trentalancia

Quoted 1 line · Christopher J. PeBenito

On 02/23/11 13:50, Guido Trentalancia wrote:

Also, what do you think about the idea of providing a make target (say "make check") in refpolicy which runs some minimal checks on that for at least the core processes ?

I can't think of how that would work off the top of my head. If you have ideas, I'd be happy to listen. I'd prefer to not write a script that has all of the checking hard coded in it.

It's just something very simple. A make target which runs ps axZ (as sysadm) and compares a few very basic things:

- if init has properly transitioned to its context (apparently at the moment no one cares if it hasn't, which is quite worrying as everything could run in kernel_t without showing any symptom or warning);
- for a few core modules (as long as they are compiled in the policy), that they are running in the proper context: so for example if polkitd is running in policykit_t context (ps axZ | grep polkitd | grep policykit_t).

Quoted 7 lines

Quoted 5 lines

Of course you can avoid hardcoding the keywords "polkitd" and "policykit_d" as long as you can get that out of policykit.{te,fc} by the means of some other form of regexp matching and string processing (sed, awk) for example: something very simple, something very basic, still quite useful to the inexperienced user.

What you're describing is a big hardcoded script, which I'm trying to avoid.

More or less this what I meant:

check:

	ps axZ | grep init | grep -q init_t || echo "FAIL: init has not

transitioned properly to its context"

and so on for the a few other basic first-line context checks.

Quoted 2 lines

If you don't like it, it doesn't matter. Any test needs at least to have the reference results "hardcoded".

Actually, this is one of the reasons I created the sestatus tool (see sestatus -v): to help people determine certain the context of key files and processes. It doesn't validate that the contexts are correct, but it makes it easy to find them.

Quoted 9 lines · Guido Trentalancia

Quoted 8 lines · Christopher J. PeBenito

Quoted 7 lines · Guido Trentalancia

Hello Christopher !

Quoted 4 lines · Christopher J. PeBenito

Quoted 3 lines · Guido Trentalancia

This patch allows dbus chat between networkmanager and dbus and between networkmanager and xdm. It also adds a missing permission (sysnet_read_dhcpc_state) to the networkmanager module.

[cut]

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 9 lines

policy/modules/services/xserver.te optional_policy(` · line 552

Quoted 9 lines

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/xserver.te refpolicy-git-15022011-new-modified/policy/modules/services/xserver.te

policy/modules/services/xserver.te +2 -0

@@ -548,6 +548,10 @@ optional_policy(`
 ')
 
 optional_policy(`
+	networkmanager_dbus_chat(xdm_t)
+')

More or less I have reported back what was being requested (in the form of a patch).

Quoted 4 lines

Quoted 1 line

It makes me wonder if everything is running in the right domain.

That could be. But I have not been provided with a reference. So, can you provide a reference ps auxZ which then I will compare as soon as I can access the test system again ?

It would be simpler if you could provide the ps output. The only process that should be running in xdm_t should be xdm/gdm/kdm. If your nm-applet is running in xdm_t, it is wrong. It should be running in the user's domain.

Quoted 3 lines

Also, what do you think about the idea of providing a make target (say "make check") in refpolicy which runs some minimal checks on that for at least the core processes ?

I can't think of how that would work off the top of my head. If you have ideas, I'd be happy to listen. I'd prefer to not write a script that has all of the checking hard coded in it.

Quoted 22 lines · Christopher J. PeBenito

Quoted 9 lines · Guido Trentalancia

Quoted 8 lines · Christopher J. PeBenito

Quoted 7 lines · Guido Trentalancia

Hello Christopher !

Quoted 4 lines · Christopher J. PeBenito

Quoted 3 lines · Guido Trentalancia

This patch allows dbus chat between networkmanager and dbus and between networkmanager and xdm. It also adds a missing permission (sysnet_read_dhcpc_state) to the networkmanager module.

[cut]

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 9 lines

policy/modules/services/xserver.te optional_policy(` · line 552

Quoted 9 lines

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/xserver.te refpolicy-git-15022011-new-modified/policy/modules/services/xserver.te

policy/modules/services/xserver.te +2 -0

@@ -548,6 +548,10 @@ optional_policy(`
  ')
 
  optional_policy(`
+	networkmanager_dbus_chat(xdm_t)
+')

More or less I have reported back what was being requested (in the form of a patch).

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

It makes me wonder if everything is running in the right domain.

That could be. But I have not been provided with a reference. So, can you provide a reference ps auxZ which then I will compare as soon as I can access the test system again ?

It would be simpler if you could provide the ps output. The only process that should be running in xdm_t should be xdm/gdm/kdm. If your nm-applet is running in xdm_t, it is wrong. It should be running in the user's domain.

Yes, I can now confirm. Everything past the X login runs in xdm_t because pam_selinux open is disabled for gdm. Enabling pam_selinux open for gdm leads to graphical login failures. I am trying to sort this out now. Is it a known issue ?

Do you believe such a case (gdm not using pam_selinux) should be dropped and not considered as a possible scenario ?

Quoted 35 lines · Guido Trentalancia

Quoted 22 lines · Christopher J. PeBenito

Quoted 9 lines · Guido Trentalancia

Quoted 8 lines · Christopher J. PeBenito

Quoted 7 lines · Guido Trentalancia

Hello Christopher !

Quoted 4 lines · Christopher J. PeBenito

Quoted 3 lines · Guido Trentalancia

This patch allows dbus chat between networkmanager and dbus and between networkmanager and xdm. It also adds a missing permission (sysnet_read_dhcpc_state) to the networkmanager module.

[cut]

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 9 lines

policy/modules/services/xserver.te optional_policy(` · line 552

Quoted 9 lines

diff -pruN refpolicy-git-15022011-new-before-modification/policy/modules/services/xserver.te refpolicy-git-15022011-new-modified/policy/modules/services/xserver.te

policy/modules/services/xserver.te +2 -0

@@ -548,6 +548,10 @@ optional_policy(`
  ')
 
  optional_policy(`
+	networkmanager_dbus_chat(xdm_t)
+')

More or less I have reported back what was being requested (in the form of a patch).

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

It makes me wonder if everything is running in the right domain.

That could be. But I have not been provided with a reference. So, can you provide a reference ps auxZ which then I will compare as soon as I can access the test system again ?

It would be simpler if you could provide the ps output. The only process that should be running in xdm_t should be xdm/gdm/kdm. If your nm-applet is running in xdm_t, it is wrong. It should be running in the user's domain.

Yes, I can now confirm. Everything past the X login runs in xdm_t because pam_selinux open is disabled for gdm. Enabling pam_selinux open for gdm leads to graphical login failures. I am trying to sort this out now. Is it a known issue ?

Quoted 2 lines

Do you believe such a case (gdm not using pam_selinux) should be dropped and not considered as a possible scenario ?

The login application needs to set the right context for the user logging in. A login app that does not do this is malfunctioning w.r.t. SELinux. It is not a valid scenario in the policy. I will remove the xdm_t dbus access that I added from your consolekit patch, and ignore the other patches that have additional xdm_t dbus permissions.