dhclient-script fails with apparmor

I see this too. To reproduce, the network interface should not be managed by Network Manager:

Then perform the following:
$ sudo /etc/init.d/NetworkManager stop
$ sudo ifconfig eth0 down
$ sudo dhclient eth0

I see the following in dmesg on i386:
[ 1482.018546] type=1503 audit(1247767237.673:10): operation="open" pid=3704 parent=3703 profile="/sbin/dhclient-script" requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0 name="/etc/ld.so.cache"
[ 1482.018681] type=1503 audit(1247767237.673:11): operation="open" pid=3704 parent=3703 profile="/sbin/dhclient-script" requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0 name="/lib/libncurses.so.5.7"

I took a look at this and it is behaving correctly, though I haven't established whether it is due to a deviation in AppArmor's behavior, the scripts or both. The executable /sbin/dhclient3 does a Px transition (as specified in its profile) to /sbin/dhclient-script.

  /sbin/dhclient-script Pxr,

The transition can be seen by putting the /sbin/dhclient3 profile into audit mode
type=APPARMOR_AUDIT msg=audit(1247815097.686:61): operation="exec" pid=4152 comm="dhclient3" parent=4151 profile="/sbin/dhclient3" requested_mask="x::" fsuid=0 ouid=0 name="/sbin/dhclient-script"

The /sbin/dhclient-script then attempts to open the following 2 files without doing an exec to bash
type=APPARMOR_DENIED msg=audit(1247815097.690:62): operation="open" pid=4152 comm="dhclient-script" parent=4151 profile="/sbin/dhclient-script" requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0 name="/etc/ld.so.cache"
type=APPARMOR_DENIED msg=audit(1247816247.944:89): operation="open" pid=4400 comm="dhclient-script" parent=4399 profile="/sbin/dhclient-script" requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0 name="/lib/libncurses.so.5.7"

putting the /sbin/dhclient-script into audit mode doesn't show up any more accesses. I through in some debugging to verify the reported behavior matches what is going on internally and it does.

AppArmor's behavior for scripts, is that it will attach the profile to the script if it is directly invoked. In this case invoking /sbin/dhclient-script will cause dhclient-script to be confined by AppArmor even though it is a bash script. If the script is indirectly invoked through bash then, the bash profile (if it exists) would be used.

Thanks for looking into this John, but I am rather baffled at this point as to why the AppArmor behavior changed dramatically from Jaunty to Karmic, when the script itself is the same. I also checked the full delta between 3.1.1 (jaunty) and 3.1.2 (Karmic) and dhclient3 does not change the way it calls dhclient-script.

Will solve this in dhcp3 profile in another way.

This bug was fixed in the package dhcp3 - 3.1.2-1ubuntu4

---------------
dhcp3 (3.1.2-1ubuntu4) karmic; urgency=low

  * Adjust dhclient AppArmor profile to call dhclient-script with Uxr instead
    of Pxr with its own unrestricted profile. This simplifies the profile,
    does not change the security stance of the profile, and works around an
    AppArmor regression in Ubuntu kernel 2.6.31-3.19. (LP: #400349)
  * debian/dhcp3-client.postinst: adjust to reload only the dhlient3 profile,
    not all of AppArmor
  * debian/dhcp3-server.postinst: adjust to reload only the dhcpd3 profile,
    not all of AppArmor

 -- Jamie Strandboge <email address hidden> Fri, 17 Jul 2009 09:57:19 -0500

This turns out to be a regression in Jaunty, that is now fixed and behaving properly in Karmic

This is a bug in the handling of profile attachment for scripts. The check to test if an attachment has already been applied needs to be reworked for 2.6.28. This regression is mitigated, in that correct attachment is retained if ix is used for the script interpreter which is standard profiling practice.

Marking Jaunty dhcp3 task as Invalid since it is working as designed.

This bug appears in Jaunty if a new kernel is loaded - strace below. Is it really "working as designed" if loading a new kernel causes dhcp to fail?

508 execve("/sbin/dhclient-script", ["/sbin/dhclient-script"], [/* 4 vars */]) = 0
2508 brk(0) = 0x215c000
2508 fcntl(0, F_GETFD) = 0
2508 fcntl(1, F_GETFD) = 0
2508 fcntl(2, F_GETFD) = 0
2508 access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or directory)
2508 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5fa3e92000
2508 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
2508 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5fa3e90000
2508 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
2508 open("/etc/ld.so.cache", O_RDONLY) = -1 EACCES (Permission denied)
2508 open("/lib/tls/x86_64/libncurses.so.5", O_RDONLY) = -1 ENOENT (No such file or directory)
2508 stat("/lib/tls/x86_64", 0x7fffa0d10530) = -1 ENOENT (No such file or directory)
2508 open("/lib/tls/libncurses.so.5", O_RDONLY) = -1 ENOENT (No such file or directory)
2508 stat("/lib/tls", 0x7fffa0d10530) = -1 ENOENT (No such file or directory)
2508 open("/lib/x86_64/libncurses.so.5", O_RDONLY) = -1 ENOENT (No such file or directory)
2508 stat("/lib/x86_64", 0x7fffa0d10530) = -1 ENOENT (No such file or directory)
2508 open("/lib/libncurses.so.5", O_RDONLY) = -1 EACCES (Permission denied)

This bug was nominated against a series that is no longer supported, ie jaunty. The bug task representing the jaunty nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.