novotnyllc / Zeroconf

Bonjour support for .NET Core, .NET 4.6, Xamarin, and UWP
MIT License
371 stars 93 forks source link

AVC denied #177

Open SpencerBurgess opened 4 years ago

SpencerBurgess commented 4 years ago

After updating a project from ZeroConf 2.7.2 to 3.4.2 we get the following permission error for Android:

avc: denied { search } for comm=54687265616420506F6F6C20576F72 name="net" dev="sysfs" ino=2748 scontext=u:r:untrusted_app:s0:c88,c256,c512,c768 tcontext=u:object_r:sysfs_net:s0 tclass=dir permissive=0

I do have WifiManager.MulticastLock set up as the wiki mentions, and I do have the permission for ChangeWifiMulticastState.

We are using Xamarin

Any thoughts on what could be causing this?

SpencerBurgess commented 4 years ago

Here is a snippet of our usage:

hubSearchTask = Task.Factory.StartNew(async () => { IReadOnlyList<IZeroconfHost> results = await ZeroconfResolver.ResolveAsync("_thomas:hub._tcp.local", TimeSpan.FromMilliseconds(1000), 3, 2000, (s) =>

clairernovotny commented 4 years ago

I'm not sure, sorry. If you're able debug into it, happy to take a PR that addresses it.

dustinkerstein commented 3 years ago

@SpencerBurgess were you able to resolve this? I'm also seeing the same error on Android (Unity3d).

riccardominato commented 3 years ago

I was facing the same issue and the problem was I mispelled the domain name. Try adding a dot at the end of the string.

In your case it will become "_thomas:hub._tcp.local.".

For some reason it was a problem only on Android, iOS was working fine.

SpencerBurgess commented 3 years ago

@dustinkerstein I have run into this issue again, still no resolution for it yet.

I was facing the same issue and the problem was I mispelled the domain name. Try adding a dot at the end of the string.

In your case it will become "_thomas:hub._tcp.local.".

For some reason it was a problem only on Android, iOS was working fine.

@riccardominato This didn't resolve the issue for me

I will do some debugging and see if I can find out what's causing this.

dustinkerstein commented 3 years ago

Yah, here's the code I'm testing on Unity (direct java calls and using built-in Unity MultiCastLock methods as a test):

private void Awake()
 {
     GetIP();
 }

 public async void GetIP() {
      Permission.RequestUserPermission("android.permission.CHANGE_WIFI_MULTICAST_STATE");
      ApplicationSettingsStatic.discoveredServers.Clear();
      try
      {
          NetworkTransport.SetMulticastLock(true);
          //await ProbeForPanoMoments();
          await EnumerateAllServicesFromAllHosts();
      }
      catch (Exception err)
      {
          Debug.Log(err.ToString());
      }
      finally
      {
          NetworkTransport.SetMulticastLock(false);
      }
      try
     {
        using (AndroidJavaObject activity = new AndroidJavaClass("com.unity3d.player.UnityPlayer").GetStatic<AndroidJavaObject>("currentActivity"))
        {

            using (var wifiManager = activity.Call<AndroidJavaObject>("getSystemService", "wifi"))
            {
                AndroidJavaObject multicastLock = wifiManager.Call<AndroidJavaObject>("createMulticastLock", "Zeroconf lock");
                try {
                    multicastLock.Call("acquire");
                    //await ProbeForPanoMoments();
                    await EnumerateAllServicesFromAllHosts();
                } catch (Exception err) {
                    Debug.Log(err.ToString());
                }
                finally {
                    multicastLock.Call("release");
                }
            }

        }
     }
     catch (Exception err)
     {
        Debug.Log(err.ToString());
     }
 }

 public async Task ProbeForPanoMoments()
 {
     IReadOnlyList<IZeroconfHost> results = await
         ZeroconfResolver.ResolveAsync("_panomoments._tcp.local.");
     if (results != null && !string.IsNullOrEmpty(results[0].Id)) {
         ApplicationSettingsStatic.autoIpAddress = results[0].Id;
         Debug.Log("autoIpAddress: " + ApplicationSettingsStatic.autoIpAddress);
     }
 }

 public async Task EnumerateAllServicesFromAllHosts()
 {
     ILookup<string, string> domains = await ZeroconfResolver.BrowseDomainsAsync();            
     var responses = await ZeroconfResolver.ResolveAsync(domains.Select(g => g.Key));            
     foreach (var resp in responses)
         Debug.Log(resp);
 }

And I have all of these (mostly uncecessary) permissions in the manifest:

<uses-permission android:name="android.permission.INTERNET" />
  <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
  <uses-permission android:name="android.permission.CHANGE_WIFI_MULTICAST_STATE" />
  <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
  <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
  <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
  <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

The MultiCastLocks seem to be working as I see this in logcat:

2021-10-08 16:01:36.125 984-3685/? I/WifiService: acquireMulticastLock uid=10311
2021-10-08 16:01:36.562 984-3685/? I/WifiService: releaseMulticastLock uid=10311
2021-10-08 16:01:36.655 984-3685/? I/WifiService: acquireMulticastLock uid=10311
2021-10-08 16:01:36.665 984-3685/? I/WifiService: releaseMulticastLock uid=10311

But all I get in is these AVC denied messages. Let me know if you figure anything out.

2021-10-08 16:06:58.354 30376-30376/? W/UnityMain: type=1400 audit(0.0:14987): avc: denied { search } for name="net" dev="sysfs" ino=28187 scontext=u:r:untrusted_app:s0:c55,c257,c512,c768 tcontext=u:object_r:sysfs_net:s0 tclass=dir permissive=0
2021-10-08 16:06:58.421 30376-30376/? W/UnityMain: type=1400 audit(0.0:14995): avc: denied { search } for name="net" dev="sysfs" ino=28187 scontext=u:r:untrusted_app:s0:c55,c257,c512,c768 tcontext=u:object_r:sysfs_net:s0 tclass=dir permissive=0
WayneKeenan commented 2 years ago

Did anyone manage to resolve this? TIA

SmartHouseGS commented 2 years ago

Same problem on Android 11

SamanthaDeshazer commented 2 years ago

I am getting the same issue regarding Android in Unity, even upon receiving confirmation that multicast lock is acquired. Is there a work around to the denied permissions issue (untrusted app)? I have all (and some unnecessary) permission granted from within a custom Android manifest for Unity and done at run-time upon initializing the app to see if it was an issue. A theory I have is that its coming up as an untrusted app within SELinux somehow, not sure if anyone else has input on this. Would greatly appreciate it!

2022/08/15 10:33:51.421 25237 25237 Warn UnityMain type=1400 audit(0.0:470): avc: denied { search } for name="net" dev="sysfs" ino=38861 scontext=u:r:untrusted_app:s0:c78,c256,c512,c768 tcontext=u:object_r:sysfs_net:s0 tclass=dir permissive=0

Moe-Baker commented 1 year ago

I am getting the same issue regarding Android in Unity, even upon receiving confirmation that multicast lock is acquired. Is there a work around to the denied permissions issue (untrusted app)? I have all (and some unnecessary) permission granted from within a custom Android manifest for Unity and done at run-time upon initializing the app to see if it was an issue. A theory I have is that its coming up as an untrusted app within SELinux somehow, not sure if anyone else has input on this. Would greatly appreciate it!

2022/08/15 10:33:51.421 25237 25237 Warn UnityMain type=1400 audit(0.0:470): avc: denied { search } for name="net" dev="sysfs" ino=38861 scontext=u:r:untrusted_app:s0:c78,c256,c512,c768 tcontext=u:object_r:sysfs_net:s0 tclass=dir permissive=0

Did you ever git a fix on this issue?

FrameMuse commented 2 weeks ago

Having the same issue, but with USB devices.

As far as I investigate, it's about "untrusted app" from this Stack Overflow answer.

Stack Overflow answer It's depends of SELinux restrictions. You cannot do so much to avoid it. In easy words: it means that there is "someone" that has tried to "{read}" something but SELinux stops it because that App wasn't found in the "trusted" list of SELinux. Usually some specific and dangerous locations of the System are restricted from installed Apps, so SELinux stops to read/wrote/execute things in/from that locations. (1) An Enforcing SELinux writes that Log AND denied the access. (2) A Permissive SELinux writes that Log BUT allow the access. (3) A Disabled SELinux do NOT writes the log AND allow the access. To avoid it you should rebuild the ROM after changed specific files about SELinux where you have to add your App in the "trusted zone". You can install a different Kernel with a different SELinux settings.

I also encountered several others' answers, but unfortunately can't reference the sources, here's what they all were about:

Your android device rejects any untrusted direct access, the only cure to this - rooting your device. So you have to reROM your android device with a ROM that has root privileges to be able to pass this problem.