Ubuntu

dhclient-script fails with apparmor

Reported by Marc Deslauriers on 2009-07-16
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
dhcp3 (Ubuntu)
Medium
Jamie Strandboge
Jaunty
Undecided
Unassigned
Karmic
Medium
Jamie Strandboge
linux (Ubuntu)
Medium
John Johansen
Jaunty
Undecided
John Johansen
Karmic
Medium
John Johansen

Bug Description

In Karmic, with the new kernel containing apparmor, using ifdown/ifup on network interfaces will cause dhclient-script to fail with:

/bin/bash: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory

In dmesg, we have a log entry:

[ 605.935709] type=1503 audit(1247755889.015:59): operation="open" pid=3587 parent=3559 profile="/sbin/dhclient-script" requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0 name="/lib/libncurses.so.5.7"

This seems to be caused by apparmor not honoring the "/bin/bash Uxr," line in /etc/apparmor.d/sbin.dhclient3

Related branches

Jamie Strandboge (jdstrand) wrote :

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"

Changed in dhcp3 (Ubuntu):
assignee: nobody → John Johansen (jjohansen)
importance: Undecided → Medium
status: New → Confirmed
milestone: none → ubuntu-9.10-beta
tags: added: regression-potential
John Johansen (jjohansen) wrote :

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.

Jamie Strandboge (jdstrand) wrote :

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.

Jamie Strandboge (jdstrand) wrote :

Will solve this in dhcp3 profile in another way.

Changed in dhcp3 (Ubuntu):
assignee: John Johansen (jjohansen) → Jamie Strandboge (jdstrand)
Changed in linux (Ubuntu):
assignee: nobody → John Johansen (jjohansen)
importance: Undecided → Medium
status: New → Confirmed
Launchpad Janitor (janitor) wrote :

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

Changed in dhcp3 (Ubuntu Karmic):
status: Confirmed → Fix Released
John Johansen (jjohansen) wrote :

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

Changed in linux (Ubuntu Karmic):
status: Confirmed → Invalid
John Johansen (jjohansen) wrote :

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.

Changed in linux (Ubuntu Jaunty):
assignee: nobody → John Johansen (jjohansen)
status: New → Confirmed
Jamie Strandboge (jdstrand) wrote :

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

Changed in dhcp3 (Ubuntu Jaunty):
status: New → Invalid
tags: removed: regression-potential
Alex Bligh (ubuntu-alex-org) wrote :

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.

Changed in linux (Ubuntu Jaunty):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers