On Wed, Jun 23, 2010 at 6:39 AM, John Johansen
<email address hidden> wrote:
> this is really distirbing, this is the first I have heard of problems
> with children profiles, what problems where you having with child
> profiles? Where they problems with enforcement, or problems with the
> tools and development?
Most of the profiles I write I do by hand. I've had enough cases of
the tools missing entries, or re-suggesting entries that I had done in
a previous pass, and all the new children null-complain-profile
replacements, that for the most part doing things by hand is faster.
(But I'm not sure I've tried them under 10.04.)
When I used child profiles for /etc/init.d/ushare, they appeared to
work perfectly:
$ cat /etc/apparmor.d/etc.init.d.ushare
# Last Modified: Wed Mar 3 22:29:57 2010
#include <tunables/global>
I was changing a previous all-in-one-big-pile profile into much
smaller pieces. You can see that it obviously still had more work to
go; I was picking pieces to break apart, moving the lines around,
reloading, and trying again. (Probably I used apparmor_parser
--replace.)
(A small tangent: the /usr/bin/taskset is my own addition -- the
kernel sometimes places all four folding at home processes on the same
core or on HT siblings, and wastes processor time. And the kernel
isn't smart enough to rebalance the processes: it'd rather keep CPU
affinity. I wanted to not waste processor time, but I sure didn't want
to grant taskset privs to the entire folding at home client! So I
started breaking it into pieces. This iteration of the profile made my
kernel very unhappy.)
I could not shut down cleanly. I had to remove this profile before I
could boot into X again. Not fun. (I won't test this one again except
under emulation.. got a kvm ubuntu 10.04 image handy? :)
> Also did your problems with the /home/sarnold/Local/Io/** profile occur
> when just enforcing the profile? ie. did you see problems if you loaded
> the profile and didn't replace it/do development on it?
My /home/sarnold/Local/io/** profile appears to have been failing
nearly from the start.
For my Io profile I used aa-autodep on
/home/sarnold/Local/io/build/_build/binaries/io, then changed things
around by hand:
$ cat home.sarnold.Local.Io
# Last Modified: Sun Jun 20 23:58:04 2010
#include <tunables/global>
You can see that it wanted groff, wanted cap_sys_tty_config, probably
intended to run /usr/bin/check-bios-nx, wanted to read
/var/lib/dpkg/status, and again groff. (The last three were me,
unbelieving what I was seeing. :)
On Wed, Jun 23, 2010 at 6:39 AM, John Johansen
<email address hidden> wrote:
> this is really distirbing, this is the first I have heard of problems
> with children profiles, what problems where you having with child
> profiles? Where they problems with enforcement, or problems with the
> tools and development?
Most of the profiles I write I do by hand. I've had enough cases of profile
the tools missing entries, or re-suggesting entries that I had done in
a previous pass, and all the new children null-complain-
replacements, that for the most part doing things by hand is faster.
(But I'm not sure I've tried them under 10.04.)
When I used child profiles for /etc/init.d/ushare, they appeared to
work perfectly:
$ cat /etc/apparmor. d/etc.init. d.ushare
# Last Modified: Wed Mar 3 22:29:57 2010
#include <tunables/global>
/etc/init.d/ushare {
#include <abstractions/base>
capability sys_tty_config,
owner /bin/dash ix,
owner /bin/readlink rix,
owner /etc/init.d/ushare rix, base-logging. sh r,
owner /etc/default/rcS r,
owner /etc/lsb-
owner /etc/ushare.conf r,
owner /sbin/start- stop-daemon cx,
owner /sbin/usplash_write px,
owner /usr/bin/expr cx,
owner /usr/bin/tput px,
owner /bin/touch cx,
owner /var/run/ushare.pid r,
profile /sbin/start- stop-daemon {
#include <abstractions/base>
capability sys_ptrace,
owner /dev/tty rw,
owner /var/run/ushare.pid rw,
owner /usr/bin/ushare px,
}
profile /usr/bin/expr {
#include <abstractions/base>
}
profile /bin/touch {
#include <abstractions/base>
owner /var/run/ushare.pid w,
}
profile /usr/bin/tput {
#include <abstractions/base>
capability sys_tty_config,
}
}
However, my system was _very_ unstable with my /etc/init.d/origami
profile loaded:
$ cat etc.init.d.origami
# Last Modified: Wed Mar 3 22:04:49 2010
#include <tunables/global>
/etc/init.d/origami {
#include <abstractions/base>
#include <abstractions/bash>
capability dac_override,
network inet dgram,
network inet stream,
/bin/pidof cx,
/bin/ps cx,
/bin/su cx,
/sbin/killall5 cx,
/usr/bin/taskset cx,
/bin/bash ix, init.d/ origami r, nsswitch. conf r, sys/kernel/ pid_max r, lib/origami/ ** r, origami/ foldingathome/ CPU*/* r, origami/ foldingathome/ CPU*/Core_ 78.exe mwix, origami/ foldingathome/ CPU*/Core_ 78.fah wk, origami/ foldingathome/ CPU*/Core_ b4.fah wk, origami/ foldingathome/ CPU*/FAHlog- Prev.txt wk, origami/ foldingathome/ CPU*/FAHlog. txt w, origami/ foldingathome/ CPU*/FaH mix, origami/ foldingathome/ CPU*/FahCore_ 78.exe mwkix, origami/ foldingathome/ CPU*/FahCore_ b4.exe mwkix, origami/ foldingathome/ CPU*/MyFolding. html w, origami/ foldingathome/ CPU*/client. cfg wk, origami/ foldingathome/ CPU*/machinedep endent. dat w, origami/ foldingathome/ CPU*/queue. dat w, origami/ foldingathome/ CPU*/unitinfo. txt w, origami/ foldingathome/ CPU*/work/ w, origami/ foldingathome/ CPU*/work/ ** wk, origami/ foldingathome/ fah6 mrix, origami/ foldingathome/ mpiexec mrix,
/bin/dash ix,
/bin/grep mrix,
/bin/sleep mrix,
/bin/which mrix,
/dev/tty rw,
/etc/hosts r,
/etc/
/etc/
/etc/resolv.conf r,
/proc/
/proc/tty/drivers r,
/proc/uptime r,
/proc/version r,
/tmp/fah/ rw,
/tmp/fah/** rw,
/tmp/fah/f* k,
/usr/bin/cut mrix,
/usr/bin/expr mrix,
/usr/bin/getent mrix,
/usr/bin/wc mrix,
/var/
owner /var/lib/
owner /var/lib/
owner /var/lib/
owner /var/lib/
owner /var/lib/
owner /var/lib/
owner /var/lib/
owner /var/lib/
owner /var/lib/
owner /var/lib/
owner /var/lib/
owner /var/lib/
owner /var/lib/
owner /var/lib/
owner /var/lib/
owner /var/lib/
owner /var/lib/
owner /var/lib/
profile /sbin/killall5 {
#include <abstractions/base>
capability kill,
capability sys_ptrace,
/proc/ r, [0-9]*/ cmdline r, [0-9]*/ stat r, [0-9]*/ status r,
/proc/
/proc/
/proc/
/proc/version r,
/proc/uptime r,
}
profile /bin/pidof {
#include <abstractions/base>
capability sys_ptrace,
/proc/ r, [0-9]*/ cmdline r, [0-9]*/ stat r, [0-9]*/ status r,
/proc/
/proc/
/proc/
/proc/version r,
/proc/uptime r,
}
profile /bin/ps {
#include <abstractions/base>
capability sys_ptrace,
/proc/ r, [0-9]*/ cmdline r, [0-9]*/ stat r, [0-9]*/ status r,
/proc/
/proc/
/proc/
/proc/version r,
/proc/uptime r,
}
profile /bin/su {
#include <abstractions/base>
capability setgid,
capability setuid,
owner /etc/default/locale r,
owner /etc/environment r,
owner /etc/group r,
owner /etc/host.conf r,
owner /etc/login.defs r,
owner /etc/pam. d/common- account r, d/common- auth r, d/common- password r, d/common- session r, limits. conf r, pam_env. conf r, pam_*.so m,
owner /etc/pam.
owner /etc/pam.
owner /etc/pam.
owner /etc/pam.d/other r,
owner /etc/pam.d/su r,
owner /etc/passwd r,
owner /etc/security/
owner /etc/security/
owner /etc/shadow r,
owner /etc/shells r,
owner /lib/security/
owner /var/log/lastlog rwk,
owner /var/log/wtmp rwk,
owner /var/run/utmp rwk,
}
profile /usr/bin/taskset {
#include <abstractions/base>
}
}
I was changing a previous all-in-one-big-pile profile into much
smaller pieces. You can see that it obviously still had more work to
go; I was picking pieces to break apart, moving the lines around,
reloading, and trying again. (Probably I used apparmor_parser
--replace.)
(A small tangent: the /usr/bin/taskset is my own addition -- the
kernel sometimes places all four folding at home processes on the same
core or on HT siblings, and wastes processor time. And the kernel
isn't smart enough to rebalance the processes: it'd rather keep CPU
affinity. I wanted to not waste processor time, but I sure didn't want
to grant taskset privs to the entire folding at home client! So I
started breaking it into pieces. This iteration of the profile made my
kernel very unhappy.)
I could not shut down cleanly. I had to remove this profile before I
could boot into X again. Not fun. (I won't test this one again except
under emulation.. got a kvm ubuntu 10.04 image handy? :)
> Also did your problems with the /home/sarnold/ Local/Io/ ** profile occur
> when just enforcing the profile? ie. did you see problems if you loaded
> the profile and didn't replace it/do development on it?
My /home/sarnold/ Local/io/ ** profile appears to have been failing
nearly from the start.
For my Io profile I used aa-autodep on Local/io/ build/_ build/binaries/ io, then changed things
/home/sarnold/
around by hand:
$ cat home.sarnold. Local.Io
# Last Modified: Sun Jun 20 23:58:04 2010
#include <tunables/global>
/home/sarnold/ Local/io/ ** {
#include <abstractions/base>
owner /home/*/Local/io/** mr,
owner /dev/tty rw,
}
Now that I'm reading my logs, I can see that this was also immediately unstable:
$ grep /home/sarnold/ Local/ /var/log/messages 4.764:181) : operation= "profile_ load" pid=19615 home/sarnold/ Local/io/ build/_ build/binaries/ io" 6.554:182) : operation= "profile_ load" pid=19630 home/sarnold/ Local/io/ **" 1.184:183) : operation="open" pid=19675 parent=19673 "/home/ sarnold/ Local/io/ **" requested_ mask=": :r" usr/share/ groff/1. 20.1/font/ devutf8/ DESC" 7.991:182) : operation="capable" pid=7952 parent=7951 "/home/ sarnold/ Local/io/ **" name="sys_ tty_config" 8.223:95) : operation="open" pid=1539 parent=1538 "/home/ sarnold/ Local/io/ **" requested_ mask="r: :" usr/bin/ check-bios- nx" 5.662:11) : operation= "profile_ load" pid=1009 home/sarnold/ Local/io/ **" 7.627:61) : operation="open" pid=2664 parent=2661 "/home/ sarnold/ Local/io/ **" requested_ mask="r: :" var/lib/ dpkg/status" 1.907:75) : operation="open" pid=2861 parent=2859 "/home/ sarnold/ Local/io/ **" requested_ mask=": :r" usr/share/ groff/1. 20.1/font/ devutf8/ DESC" 9.447:76) : operation="open" pid=2878 parent=2876 "/home/ sarnold/ Local/io/ **" requested_ mask=": :r" usr/share/ groff/1. 20.1/font/ devutf8/ DESC" 4.876:77) : operation="open" pid=2896 parent=2894 "/home/ sarnold/ Local/io/ **" requested_ mask=": :r" usr/share/ groff/1. 20.1/font/ devutf8/ DESC" 5.363:78) : operation="open" pid=2915 parent=2913 "/home/ sarnold/ Local/io/ **" requested_ mask=": :r" usr/share/ groff/1. 20.1/font/ devutf8/ DESC"
Jun 20 23:58:04 haig kernel: [18128.952910] type=1505
audit(127710348
name="/
Jun 20 23:59:06 haig kernel: [18190.703695] type=1505
audit(127710354
name="/
Jun 21 00:00:41 haig kernel: [18285.287783] type=1503
audit(127710364
profile=
denied_mask="::r" fsuid=1000 ouid=0
name="/
Jun 22 03:03:17 haig kernel: [36765.256907] type=1503
audit(127720099
profile=
Jun 22 03:07:48 haig kernel: [ 33.699371] type=1503
audit(127720126
profile=
denied_mask="r::" fsuid=0 ouid=0 name="/
Jun 22 03:16:45 haig kernel: [ 14.120115] type=1505
audit(127720180
name="/
Jun 22 03:28:07 haig kernel: [ 695.067408] type=1503
audit(127720248
profile=
denied_mask="r::" fsuid=0 ouid=0 name="/
Jun 22 03:39:01 haig kernel: [ 1348.910026] type=1503
audit(127720314
profile=
denied_mask="::r" fsuid=1000 ouid=0
name="/
Jun 22 03:39:09 haig kernel: [ 1356.443491] type=1503
audit(127720314
profile=
denied_mask="::r" fsuid=1000 ouid=0
name="/
Jun 22 03:39:44 haig kernel: [ 1391.842510] type=1503
audit(127720318
profile=
denied_mask="::r" fsuid=1000 ouid=0
name="/
Jun 22 03:41:55 haig kernel: [ 1522.241724] type=1503
audit(127720331
profile=
denied_mask="::r" fsuid=1000 ouid=0
name="/
You can see that it wanted groff, wanted cap_sys_tty_config, probably check-bios- nx, wanted to read dpkg/status, and again groff. (The last three were me,
intended to run /usr/bin/
/var/lib/
unbelieving what I was seeing. :)
I miss the 'comm' output from our logging. :(
Thanks John! Hope this helps.