Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

2019-06-03 Thread Ian 

On 11/3/18, /John Johansen/ wrote://

> A task invoking the no_new_privs prct > 
https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt 



Okay, so I just did a strace on 'man' and see that it calls that 
function with the nnp parameter before attempting to execve the child 
processes that fail to execute.


Okay -- I get it now:  While nnp normally works fine if the executable 
is unconstrained, once apparmor assigns a security label to the 
executable, it's game over because the LSM system asks apparmor to do 
something it cannot -- prove the future profile transition has the same 
permissions.  I thought the child processes were asking for additional 
security, but that's not the case.


This means that since all non-kernel processes have a label with the 
FullSystemPolicy setup, this is an unavoidable problem -- there is no 
way to remove a label once assigned.  It's ironic that a function 
designed to help secure a system is what is responsible for preventing 
whitelisting.


I assume I'll run into a similar issue with selinux since this is a LSM 
label transition thing then? Man, this linux whitelisting search is 
turning out to be the holy grail.


-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

2019-06-03 Thread John Johansen 
On 6/3/19 1:40 PM, Ian wrote:
> 
> On 5/31/19 2:59 PM, John wrote:
>> Because when no-new-privs landed it was mandated that the LSMs not over ride 
>> it. No new-privs is not part of apparmor but the broader kernel, and was 
>> provided as a way to for a task to lockdown privileges to the current set.
>>
>> prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
>>
>> It was added with seccomp (3.5) so that the task could do setup and then 
>> lock its sandbox/security env down. At the time the LSMs were told it should 
>> apply to them as well. With seccomp use expanding and systemd now setting it 
>> this has unfortunately caused several problems for LSMs and selinux 
>> successfully added a setprivs ability that allows them to selectively 
>> override. AppArmor does currently allow transitions under no-new-privs but 
>> only when the transition is provable a subset of the tasks confinement (3.5 
>> - 4.12 unconfined is allowed to transition to a profile, 4.13 - 4.16 is 
>> limited to strict subset of current confinement, basically you can extend a 
>> profile stack, 4.17 - 5.2 to a subset of confinement at the time nnp is 
>> set). We do have plans to add our own ability to have a permission to 
>> override no-new-privs but that has not landed upstream yet.
>>
>>
>> >/Running pstree at the same time as apt shows the following order: systemd, 
>> >sshd, sshd, sshd, bash, sudo, bash, apt, gpgv (and http, http), gpgv 
>> >/>//>/root at 1546-w-dev 
>> >:/etc/apparmor.d# cat 
>> >usr.lib.apt.methods.gpgv />/profile usr.lib.apt.methods.gpgv 
>> >/usr/lib/apt/methods/gpgv flags=(complain) { />/    #include 
>> > />/} />//>//>/root at 1546-w-dev 
>> >:/etc/apparmor.d# cat 
>> >usr.bin.apt_key />/profile usr.bin.apt_key /usr/bin/apt-key 
>> >flags=(complain) { />/    #include  />/} />//>//>/Have I 
>> >ran into this?  
>> >https://lists.ubuntu.com/archives/apparmor/2018-November/011846.html />//
>> unfortunately, yes. I can point you at a test kernel for the nnp override 
>> but, I will need
>> to get up a userspace that can work with it. I'll see what I can do this 
>> weekend.
>>
>>
> if I use "/** px" for init-systemd and all other discrete profiles, am I 
> correct in concluding that each child process does a domain transition?  I.E. 
> using that pstree output from above, by the time gpgv executes, the following 
> transitions happen:
> 
> unconfined -> init-systemd -> usr.sbin.sshd -> bin.bash -> usr.bin.sudo -> 
> bin.bash -> and so on?
> 
Hrmmm I would not say a transition is guaranteed, rather a profile lookup is 
guaranteed. That lookup may very well result in the same profile as the current 
confinement (dependent on how attachments are defined). Other than that 
semantic yes.


> Does the nnp issue occur after a certain depth is reached, or is something 
> else triggering this? 

A task invoking the no_new_privs prct

https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt

> What I don't get is that each process should have the same profile permission 
> requests. Are there additional permissions I need to add to my "whitelist" 
> file?

I am not sure I understand the question. But maybe the explanation will help

For apparmor exec transitions you only need to consider the tasks current 
confinement. A parents confinement only matters in that its confinement is used 
inherited at time of fork and used at time of exec. Each profile has full 
control over how transitions are done so its local rule, eg.

  /** px,

is used to determine what transition, if any, should be done. px transitions 
will evaluate the best profile transition for the currently loaded profile set 
based on the attachment conditionals.

It is possible that a single profile will cover multiple different executables 
or be reused multiple times through and exec chain, like you have above.

However you are free to define your policy to do something else, via ix, ux, 
cx, and -> based transitions.

With policy namespaces it is possible to have different sets of profiles with 
different attachment sets. You can keep some exec hierarchy with children 
profiles, etc.

> 
> Also, if nnp locks things down, does that mean ux only works if the parent 
> process is itself unconfined?  I.E. this isn't possible: unconfined -> px -> 
> ux?  If that is possible, maybe I could somehow get apparmor to initially 
> transition to ux before px?
> 

The ux exception for nnp only works based on the current confinement at the 
time of the exec. So if the task doing the exec is unconfined it can transition 
to any profile. It does not depend on the parent tasks confinement beyond that 
in the fork exec model the forked child inherits its parents confinement at the 
time of the fork before doing the exec, but if the parent changed its own 
confinement between the fork and the childs call to exec the parents change of 
confinement would not affect the child's

Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

2019-06-03 Thread Ian 


On 5/31/19 2:59 PM, John wrote:

Because when no-new-privs landed it was mandated that the LSMs not over ride 
it. No new-privs is not part of apparmor but the broader kernel, and was 
provided as a way to for a task to lockdown privileges to the current set.

prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);

It was added with seccomp (3.5) so that the task could do setup and then lock 
its sandbox/security env down. At the time the LSMs were told it should apply 
to them as well. With seccomp use expanding and systemd now setting it this has 
unfortunately caused several problems for LSMs and selinux successfully added a 
setprivs ability that allows them to selectively override. AppArmor does 
currently allow transitions under no-new-privs but only when the transition is 
provable a subset of the tasks confinement (3.5 - 4.12 unconfined is allowed to 
transition to a profile, 4.13 - 4.16 is limited to strict subset of current 
confinement, basically you can extend a profile stack, 4.17 - 5.2 to a subset 
of confinement at the time nnp is set). We do have plans to add our own ability 
to have a permission to override no-new-privs but that has not landed upstream 
yet.


>/Running pstree at the same time as apt shows the following order: 
systemd, sshd, sshd, sshd, bash, sudo, bash, apt, gpgv (and http, 
http), gpgv />//>/root at 1546-w-dev 
:/etc/apparmor.d# 
cat usr.lib.apt.methods.gpgv />/profile usr.lib.apt.methods.gpgv /usr/lib/apt/methods/gpgv 
flags=(complain) { />/    #include  />/} />//>//>/root at 1546-w-dev 
:/etc/apparmor.d# 
cat usr.bin.apt_key />/profile usr.bin.apt_key /usr/bin/apt-key flags=(complain) { />/    #include  />/} />//>//>/Have I ran into this? 
https://lists.ubuntu.com/archives/apparmor/2018-November/011846.html />//

unfortunately, yes. I can point you at a test kernel for the nnp override but, 
I will need
to get up a userspace that can work with it. I'll see what I can do this 
weekend.


if I use "/** px" for init-systemd and all other discrete profiles, am I 
correct in concluding that each child process does a domain transition?  
I.E. using that pstree output from above, by the time gpgv executes, the 
following transitions happen:


unconfined -> init-systemd -> usr.sbin.sshd -> bin.bash -> usr.bin.sudo 
-> bin.bash -> and so on?


Does the nnp issue occur after a certain depth is reached, or is 
something else triggering this?  What I don't get is that each process 
should have the same profile permission requests. Are there additional 
permissions I need to add to my "whitelist" file?


Also, if nnp locks things down, does that mean ux only works if the 
parent process is itself unconfined?  I.E. this isn't possible: 
unconfined -> px -> ux?  If that is possible, maybe I could somehow get 
apparmor to initially transition to ux before px?



-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

2019-05-31 Thread John Johansen 
On 5/31/19 2:59 PM, Ian wrote:
> On Fri, 31 May 2019, Jamie wrote:
>> On Fri, 31 May 2019, Ian wrote:
>>
>>>/The only thing outstanding is some trouble I run into after the initramfs 
>>>/>>/chroot transition but before the apparmor service starts: />>//>>/May 31 
>>>12:10:55 1546-w-dev audit[5162]: AVC apparmor="ALLOWED" />>/operation="exec" 
>>>info="profile transition not found" error=-13 />>/profile="init-sys 
>>>/>>/temd" name="/usr/bin/unshare" pid=5162 comm="(spawn)" 
>>>/>>/requested_mask="x" denied_mask="x" fsuid=0 ouid=0 
>>>/>>/target="/usr/bin/unshare" />>/May 31 12:10:54 1546-w-dev audit[5004]: 
>>>AVC apparmor="ALLOWED" />>/operation="exec" info="profile transition not 
>>>found" error=-13 />>/profile="init-sys />>/temd" name="/usr/bin/unshare" 
>>>pid=5004 comm="(spawn)" />>/requested_mask="x" denied_mask="x" fsuid=0 
>>>ouid=0 />>/target="/usr/bin/unshare" />
>>Notice it is /usr/bin/unshare here, but you mention below that
>>'/usr/sbin/unshare' exists, but what you pasted looks correct. Is this a typo
>>in the email or somewhere else?
>>
>>>/The /usr/sbin/unshare profile exists: />>//>>/root at 1546-w-dev 
>>>:/etc/apparmor.d# cat 
>>>usr.bin.unshare />>/profile usr.bin.unshare /usr/bin/unshare 
>>>/>>/flags=(complain,attach_disconnected) { />>/    #include 
>>> />>/} /
> 
> Jamie,
> 
> That was a typo in the email. There is no /usr/sbin/unshare executable or 
> profile.
> 
> After everything loads, if I restart the "lvm2-pvscan@8:1" service that I 
> think is responsible for those errors during boot (systemctl shows it as 
> failed), it all works correctly.
> 
> ---
> 
> 
> On a different topic, when I attempted to run 'apt update', this happens:
> 
> type=AVC msg=audit(1559334318.936:8850): apparmor="ALLOWED" 
> operation="exec" info="no new privs" error=-1 
> profile="usr.lib.apt.methods.gpgv" name="/usr/bin/apt-key" pid=11011 
> comm="gpgv" requested_mask="x" denied_mask="x" fsuid=104 ouid=0 
> target="usr.bin.apt_key"
> type=AVC msg=audit(1559334319.212:8851): apparmor="ALLOWED" 
> operation="exec" info="no new privs" error=-1 
> profile="usr.lib.apt.methods.gpgv" name="/usr/bin/apt-key" pid=11013 
> comm="gpgv" requested_mask="x" denied_mask="x" fsuid=104 ouid=0 
> target="usr.bin.apt_key"
> type=AVC msg=audit(1559334319.228:8852): apparmor="ALLOWED" 
> operation="exec" info="no new privs" error=-1 
> profile="usr.lib.apt.methods.gpgv" name="/usr/bin/apt-key" pid=11015 
> comm="gpgv" requested_mask="x" denied_mask="x" fsuid=104 ouid=0 
> target="usr.bin.apt_key"
> type=AVC msg=audit(1559334319.332:8853): apparmor="ALLOWED" 
> operation="exec" info="no new privs" error=-1 
> profile="usr.lib.apt.methods.gpgv" name="/usr/bin/apt-key" pid=11017 
> comm="gpgv" requested_mask="x" denied_mask="x" fsuid=104 ouid=0 
> target="usr.bin.apt_key"
> 
> 
> W: An error occurred during the signature verification. The repository is 
> not updated and the previous index files will be used. GPG error: 
> http://us.archive.ubuntu.com/ubuntu bionic InRelease: Couldn't execute 
> /usr/bin/apt-key to check 
> /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_bionic_InRelease
> W: An error occurred during the signature verification. The repository is 
> not updated and the previous index files will be used. GPG error: 
> http://us.archive.ubuntu.com/ubuntu bionic-updates InRelease: Couldn't 
> execute /usr/bin/apt-key to check 
> /var/lib/apt/lists/partial/us.archive.ubuntu.com_ubuntu_dists_bionic-updates_InRelease
> W: An error occurred during the signature verification. The repository is 
> not updated and the previous index files will be used. GPG error: 
> http://security.ubuntu.com/ubuntu bionic-security InRelease: Couldn't execute 
> /usr/bin/apt-key to check 
> /var/lib/apt/lists/partial/security.ubuntu.com_ubuntu_dists_bionic-security_InRelease
> W: An error occurred during the signature verification. The repository is 
> not updated and the previous index files will be used. GPG error: 
> http://us.archive.ubuntu.com/ubuntu bionic-backports InRelease: Couldn't 
> execute /usr/bin/apt-key to check 
> /var/lib/apt/lists/partial/us.archive.ubuntu.com_ubuntu_dists_bionic-backports_InRelease
> 
> 
> It's not clear to me why it thinks I would be requesting new privs when all 
> of the profiles I've created have the exact same priv requests.  It's also 
> odd that apparmor is stating "ALLOWED" but then still blocking the execution?
> 

Because when no-new-privs landed it was mandated that the LSMs not over ride 
it. No new-privs is not part of apparmor but the broader kernel, and was 
provided as a way to for a task to lockdown privileges to the current set.

prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);

It was added with seccomp (3.5) so that the task could do setup and then lock 
its sandbox/security env down. At the time the LSMs were told it should apply 
to them as well. With seccomp use expanding and systemd now

Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

2019-05-31 Thread Ian 

On Fri, 31 May 2019, Jamie wrote:

On Fri, 31 May 2019, Ian wrote:


/The only thing outstanding is some trouble I run into after the initramfs />>/chroot transition but before the apparmor service starts: />>//>>/May 31 12:10:55 1546-w-dev audit[5162]: AVC apparmor="ALLOWED" />>/operation="exec" info="profile transition not found" error=-13 
/>>/profile="init-sys />>/temd" name="/usr/bin/unshare" pid=5162 comm="(spawn)" />>/requested_mask="x" denied_mask="x" fsuid=0 ouid=0 />>/target="/usr/bin/unshare" />>/May 31 12:10:54 1546-w-dev audit[5004]: AVC apparmor="ALLOWED" 
/>>/operation="exec" info="profile transition not found" error=-13 />>/profile="init-sys />>/temd" name="/usr/bin/unshare" pid=5004 comm="(spawn)" />>/requested_mask="x" denied_mask="x" fsuid=0 ouid=0 />>/target="/usr/bin/unshare" />

Notice it is /usr/bin/unshare here, but you mention below that
'/usr/sbin/unshare' exists, but what you pasted looks correct. Is this a typo
in the email or somewhere else?

/The /usr/sbin/unshare profile exists: />>//>>/root at 1546-w-dev 
:/etc/apparmor.d# 
cat usr.bin.unshare />>/profile usr.bin.unshare /usr/bin/unshare />>/flags=(complain,attach_disconnected) { />>/    #include  />>/} /


Jamie,

That was a typo in the email. There is no /usr/sbin/unshare executable 
or profile.


After everything loads, if I restart the "lvm2-pvscan@8:1" service that 
I think is responsible for those errors during boot (systemctl shows it 
as failed), it all works correctly.


---


On a different topic, when I attempted to run 'apt update', this happens:

   type=AVC msg=audit(1559334318.936:8850): apparmor="ALLOWED" operation="exec" info="no new privs" error=-1 
profile="usr.lib.apt.methods.gpgv" name="/usr/bin/apt-key" pid=11011 comm="gpgv" requested_mask="x" denied_mask="x" 
fsuid=104 ouid=0 target="usr.bin.apt_key"
   type=AVC msg=audit(1559334319.212:8851): apparmor="ALLOWED" operation="exec" info="no new privs" error=-1 
profile="usr.lib.apt.methods.gpgv" name="/usr/bin/apt-key" pid=11013 comm="gpgv" requested_mask="x" denied_mask="x" 
fsuid=104 ouid=0 target="usr.bin.apt_key"
   type=AVC msg=audit(1559334319.228:8852): apparmor="ALLOWED" operation="exec" info="no new privs" error=-1 
profile="usr.lib.apt.methods.gpgv" name="/usr/bin/apt-key" pid=11015 comm="gpgv" requested_mask="x" denied_mask="x" 
fsuid=104 ouid=0 target="usr.bin.apt_key"
   type=AVC msg=audit(1559334319.332:8853): apparmor="ALLOWED" operation="exec" info="no new privs" error=-1 
profile="usr.lib.apt.methods.gpgv" name="/usr/bin/apt-key" pid=11017 comm="gpgv" requested_mask="x" denied_mask="x" 
fsuid=104 ouid=0 target="usr.bin.apt_key"


   W: An error occurred during the signature verification. The repository is 
not updated and the previous index files will be used. GPG error: 
http://us.archive.ubuntu.com/ubuntu bionic InRelease: Couldn't execute 
/usr/bin/apt-key to check 
/var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_bionic_InRelease
   W: An error occurred during the signature verification. The repository is 
not updated and the previous index files will be used. GPG error: 
http://us.archive.ubuntu.com/ubuntu bionic-updates InRelease: Couldn't execute 
/usr/bin/apt-key to check 
/var/lib/apt/lists/partial/us.archive.ubuntu.com_ubuntu_dists_bionic-updates_InRelease
   W: An error occurred during the signature verification. The repository is 
not updated and the previous index files will be used. GPG error: 
http://security.ubuntu.com/ubuntu bionic-security InRelease: Couldn't execute 
/usr/bin/apt-key to check 
/var/lib/apt/lists/partial/security.ubuntu.com_ubuntu_dists_bionic-security_InRelease
   W: An error occurred during the signature verification. The repository is 
not updated and the previous index files will be used. GPG error: 
http://us.archive.ubuntu.com/ubuntu bionic-backports InRelease: Couldn't 
execute /usr/bin/apt-key to check 
/var/lib/apt/lists/partial/us.archive.ubuntu.com_ubuntu_dists_bionic-backports_InRelease


It's not clear to me why it thinks I would be requesting new privs when 
all of the profiles I've created have the exact same priv requests.  
It's also odd that apparmor is stating "ALLOWED" but then still blocking 
the execution?


Running pstree at the same time as apt shows the following order: 
systemd, sshd, sshd, sshd, bash, sudo, bash, apt, gpgv (and http, http), 
gpgv


   root@1546-w-dev:/etc/apparmor.d# cat usr.lib.apt.methods.gpgv
   profile usr.lib.apt.methods.gpgv /usr/lib/apt/methods/gpgv
   flags=(complain) {
    #include 
   }


   root@1546-w-dev:/etc/apparmor.d# cat usr.bin.apt_key
   profile usr.bin.apt_key /usr/bin/apt-key flags=(complain) {
    #include 
   }


Have I ran into this? 
https://lists.ubuntu.com/archives/apparmor/2018-November/011846.html


   root@1546-w-dev:/etc/apparmor.d# uname -r
   4.15.0-50-generic

I see this problem with 'man' too.

I'm sooo close to getting this working...

-- 
AppArmor mailing

Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

2019-05-31 Thread Jamie Strandboge 
On Fri, 31 May 2019, Ian wrote:

> The only thing outstanding is some trouble I run into after the initramfs
> chroot transition but before the apparmor service starts:
> 
>May 31 12:10:55 1546-w-dev audit[5162]: AVC apparmor="ALLOWED"
>operation="exec" info="profile transition not found" error=-13
>profile="init-sys
>temd" name="/usr/bin/unshare" pid=5162 comm="(spawn)"
>requested_mask="x" denied_mask="x" fsuid=0 ouid=0
>target="/usr/bin/unshare"
>May 31 12:10:54 1546-w-dev audit[5004]: AVC apparmor="ALLOWED"
>operation="exec" info="profile transition not found" error=-13
>profile="init-sys
>temd" name="/usr/bin/unshare" pid=5004 comm="(spawn)"
>requested_mask="x" denied_mask="x" fsuid=0 ouid=0
>target="/usr/bin/unshare"

Notice it is /usr/bin/unshare here, but you mention below that
'/usr/sbin/unshare' exists, but what you pasted looks correct. Is this a typo
in the email or somewhere else?

> The /usr/sbin/unshare profile exists:
> 
>root@1546-w-dev:/etc/apparmor.d# cat usr.bin.unshare
>profile usr.bin.unshare /usr/bin/unshare
>flags=(complain,attach_disconnected) {
>     #include 
>}

-- 
Jamie Strandboge | http://www.canonical.com


signature.asc
Description: PGP signature
-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

2019-05-31 Thread Ian 


On 5/30/19 12:04 PM, Simon McVittie wrote:

On Thu, 30 May 2019 at 11:47:35 -0700, Ian wrote:

I did notice this in /var/log/syslog:

 May 30 10:46:51 1546-w-dev dbus-daemon[9496]: [system] Activating systemd
 to hand-off: service name='org.freedesktop.hostname1' unit=
 'dbus-org.freedesktop.hostname1.service' requested by ':1.21' (uid=0 pid=
 10058 comm="/usr/sbin/NetworkManager --no-daemon " label=
 "usr.sbin.NetworkManager (complain)"

This does not, in itself, indicate a bug. Whenever dbus-daemon logs an
"interesting" action like service activation, it logs all the information
it knows about the requesting process, which on AppArmor systems includes
the AppArmor label.

(complain) means the usr.sbin.NetworkManager profile is loaded in
"complain" mode, meaning that if NM does anything that would violate its
AppArmor policy, it will be logged as ALLOWED and allowed to happen,
instead of being denied. If this is not what you wanted, please look
more closely at your AppArmor policies.

 smcv


Simon, thanks for clearing that one up.

I was able to get the system to fully boot by changing

  /** Px,

to

  /** px,

in the lib.systemd.systemd post chroot profile.

The only thing outstanding is some trouble I run into after the 
initramfs chroot transition but before the apparmor service starts:


   May 31 12:10:55 1546-w-dev audit[5162]: AVC apparmor="ALLOWED"
   operation="exec" info="profile transition not found" error=-13
   profile="init-sys
   temd" name="/usr/bin/unshare" pid=5162 comm="(spawn)"
   requested_mask="x" denied_mask="x" fsuid=0 ouid=0
   target="/usr/bin/unshare"
   May 31 12:10:54 1546-w-dev audit[5004]: AVC apparmor="ALLOWED"
   operation="exec" info="profile transition not found" error=-13
   profile="init-sys
   temd" name="/usr/bin/unshare" pid=5004 comm="(spawn)"
   requested_mask="x" denied_mask="x" fsuid=0 ouid=0
   target="/usr/bin/unshare"


   [   42.159486] apparmor[635]:  * Starting AppArmor profiles

   [   49.102218] [5004]: failed to execute '/usr/bin/unshare'
   '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/sda1':
   Permission denied
   [   49.106734] systemd-udevd[699]: Process '/usr/bin/unshare -m
   /usr/bin/snap auto-import --mount=/dev/sda1' failed with exit code 2.

   [   49.119734] [5162]: failed to execute '/usr/bin/unshare'
   '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/dm-1':
   Permission denied
   [   49.124361] systemd-udevd[5160]: Process '/usr/bin/unshare -m
   /usr/bin/snap auto-import --mount=/dev/dm-1' failed with exit code 2.

   [  *** ] A start job is running for AppArmor initialization (15s /
   no limit)

   [   56.349850] auditd[753]: Audit daemon rotating log files
   [  OK  ] Started AppArmor initialization.

The /usr/sbin/unshare profile exists:

   root@1546-w-dev:/etc/apparmor.d# cat usr.bin.unshare
   profile usr.bin.unshare /usr/bin/unshare
   flags=(complain,attach_disconnected) {
    #include 
   }


   root@1546-w-dev:/etc/apparmor.d# cat local/whitelist
    network,
    signal,
    mount,
    pivot_root,
    ptrace,
    unix,
    dbus,
    umount,
    capability,
    / mrwlk,
    /** mrwlk,
    /** px,

As does /usr/bin/snap profile:

   root@1546-w-dev:/etc/apparmor.d# cat usr.bin.snap
   profile usr.bin.snap /usr/bin/snap
   flags=(complain,attach_disconnected) {
    #include 
   }

aa-status shows both of these loaded under "complain".

Is this a timing thing?  Something attempting to load as apparmor 
transitions? I.E. apparmor is still loading profiles when 
/usr/bin/unshare is being executed?


-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

2019-05-30 Thread Simon McVittie 
On Thu, 30 May 2019 at 11:47:35 -0700, Ian wrote:
> I did notice this in /var/log/syslog:
> 
> May 30 10:46:51 1546-w-dev dbus-daemon[9496]: [system] Activating systemd
> to hand-off: service name='org.freedesktop.hostname1' unit=
> 'dbus-org.freedesktop.hostname1.service' requested by ':1.21' (uid=0 pid=
> 10058 comm="/usr/sbin/NetworkManager --no-daemon " label=
> "usr.sbin.NetworkManager (complain)"

This does not, in itself, indicate a bug. Whenever dbus-daemon logs an
"interesting" action like service activation, it logs all the information
it knows about the requesting process, which on AppArmor systems includes
the AppArmor label.

(complain) means the usr.sbin.NetworkManager profile is loaded in
"complain" mode, meaning that if NM does anything that would violate its
AppArmor policy, it will be logged as ALLOWED and allowed to happen,
instead of being denied. If this is not what you wanted, please look
more closely at your AppArmor policies.

smcv

-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

2019-05-30 Thread Ian 


On 5/27/19 5:11 PM, Ian wrote:


On 5/27/19 12:08 PM, Ian wrote:


Does apparmor have the same problem as selinux where there are 
"security aware" programs that don't properly honor enforcement 
settings, or is this an inheritance problem that I'm not correctly 
addressing?




Adding "attach_disconnected" to the flags parameter of the 
init-systemd profile was required to get the system to fully boot.  I 
assume this was necessary because of the transition from initramfs, 
however the "ALLOWED" audit log entries really threw me there -- that 
and my ability to run lots of other commands without issue in that 
"emergency" mode didn't make this an obvious fix.


This initramfs transition is a tricky bit of business -- I assume I'll 
want to have a different profile for systemd for the chrooted system 
and that when the apparmor service starts, the profile will get 
replaced, however I thought that profile changes like this aren't seen 
by currently executing processes -- one has to restart the process for 
the change to take effect?  Then there's the timing of when journald 
and auditd starts.  Ideally I'd like to keep the full-permission 
profile I set up in inittamfs for systemd, but then somehow deny any 
type of inheritance once the AppArmor service starts.


Any advice on how to proceed? -- If it is true that all child 
processes will, by default, inherit the permissions from the 
init-systemd profile unless I add deny rules -- I'm back at square one 
with a blacklist setup.



Sorry for not replying to one of your responses John.  I didn't receive 
the emails, but did read the responses from the web archive.



I've made a lot of progress, but am still not quite able to fully boot 
into systemd's version of init 3.
/var/log/audit/audit.log and journalctl -r doesn't show any new 
"ALLOWED" entries.

I did notice this in /var/log/syslog:

   May 30 10:46:51 1546-w-dev dbus-daemon[9496]: [system] Activating
   systemd to hand-off: service name='org.freedesktop.hostname1'
   unit='dbus-org.freedesktop.hostname1.service' requested by ':1.21'
   (uid=0 pid=10058 comm="/usr/sbin/NetworkManager --no-daemon "
   label="usr.sbin.NetworkManager (complain)"

Running systemctl by itself shows no failed services, however there are 
still two that never get out of "activating:"


   NetworkManager.service loaded activating start start Network
   Manager
   systemd-logind.service loaded activating start start Login Service

Here's how I've gotten to where I have:

Running a fresh copy of a minimal install of Ubuntu 18.04.2 LTS with all 
the updates.  It boots into a GUI, so this isn't as minimal as CentOS's 
version... or I did something wrong when installing it.  :)


dpkg-query -W apparmor shows: 2.12-4ubuntu5.1

This is being ran in a vm, and I've attached minicom to the vm's kernel 
"console" so that I can see everything that scrolls past and do things 
like pause the output after disabling rate limiting.  :)


In initramfs, I have this one profile:

   profile init-systemd /lib/systemd/systemd flags=(complain
   attach_disconnected) {
    network,
    signal,
    file,
    mount,
    pivot_root,
    ptrace,
    unix,
    dbus,
    umount,
    capability,

   }

This is the version of that profile after the transition:

   profile init-systemd /lib/systemd/** flags=(complain
   attach_disconnected) {
  capability,
  network,
  dbus,
  mount,
  umount,
  signal,
  ptrace,
  pivot_root,
  unix,
  /** mrwlk,
  /** Px,

   }

My goal with this is to get the system into a state where I can then 
start to whitelist the executables -- to that end I'm hoping this allows 
everything except executing things -- to execute a separate profile must 
exist.  With this said, I created this file:


local/whitelist

    network,
    signal,
    file,
    mount,
    pivot_root,
    ptrace,
    unix,
    dbus,
    umount,
    capability,

and then wrote this little perl script to create stub files for all the 
currently-existing executables:


   #!/usr/bin/perl

   use strict;
   use warnings;

   my @markedAsExecutable = `/usr/bin/find /usr/bin/ -executable -type f`;
   my @applications;

   foreach my $potentialExecutable (@markedAsExecutable)
   {
    chop($potentialExecutable);
    my $isApplicationResult = `/usr/bin/file -i
   '$potentialExecutable'`;
    if ($isApplicationResult =~ m/\/x-/)
    {
    push(@applications, $potentialExecutable);
    #print $isApplicationResult . "\n";
    }
   }

   foreach my $application (@applications)
   {
    my $wlFileName = $application;
    # replace slashes with periods
    $wlFileName =~ s/\//./g;
    # drop leading period if one exists
    $wlFileName =~ s/^\.//;
    # replace special chars with underscores for apparmor profile names
    $wlFileName =~ s/[^0-9A-z.]/_/g;
    #print

Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

2019-05-27 Thread John Johansen 
On 5/27/19 5:11 PM, Ian wrote:
> 
> On 5/27/19 12:08 PM, Ian wrote:
>>
>> Does apparmor have the same problem as selinux where there are "security 
>> aware" programs that don't properly honor enforcement settings, or is this 
>> an inheritance problem that I'm not correctly addressing?
>>
>>
>>
> Adding "attach_disconnected" to the flags parameter of the init-systemd 
> profile was required to get the system to fully boot.  I assume this was 
> necessary because of the transition from initramfs, however the "ALLOWED" 
> audit log entries really threw me there -- that and my ability to run lots of 
> other commands without issue in that "emergency" mode didn't make this an 
> obvious fix.
> 
yes this is a pita, and logs getting dropped make it worse. I don't have a good 
solution in the short term. Long term, the audit parts are getting reworked and 
will be able to do better dedup and caching to reduce auditing load, and allow 
for devs to create a large log buffer to properly profile early boot.


> This initramfs transition is a tricky bit of business --

that it is

> I assume I'll want to have a different profile for systemd for the chrooted 
> system and that when the apparmor service starts,
that is probably best but may not be necessary depending on the privileges you 
are granting

> the profile will get replaced, however I thought that profile changes like 
> this aren't seen by currently executing processes -- one has to restart the 
> process for the change to take effect?

Actually as long as the profile is already attached to the task, profile 
replacement will be picked up. However there is no guarantee that it will be 
atomic across all tasks. That is to say the update happens on a best effort 
case, and the old and new version of the profile may be alive at the same time 
for a window. Exactly how long depends on locking and scheduling etc. Profiles 
for a task will only be updated when the task is running, etc.

What currently can't be done is changing the confinement of a task from one 
profile to another. The task must be either "security aware" and do this it 
self or be re-execed.


> Then there's the timing of when journald and auditd starts.  Ideally I'd like 
> to keep the full-permission profile I set up in inittamfs for systemd, but 
> then somehow deny any type of inheritance once the AppArmor service starts.
> 
you should be able to achieve this with just a profile load in the apparmor 
service. Replacing the existing profiles that were already loaded from the 
initrd. It of course has the above mentioned limitations


> Any advice on how to proceed? -- If it is true that all child processes will, 
> by default, inherit the permissions from the init-systemd profile unless I 
> add deny rules -- I'm back at square one with a blacklist setup.
> 
> 

it will depend on your init-systemd profile. If it uses ix for exec transitions 
then every child will inherit its confinement. However if you use px or even 
pix and have profiles definied for those children then they should have 
different confinement and you should be okay.

-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

2019-05-27 Thread John Johansen 
On 5/27/19 12:08 PM, Ian wrote:
> 
> On 5/24/19 6:16 PM, John Johansen wrote:
>> On 5/24/19 5:10 PM, Seth Arnold wrote:
>>> On Fri, May 24, 2019 at 03:28:21PM -0700, Ian wrote:
 It's like I'm only getting a few of these at a time -- I added this to the
 kernel boot parameter: 'audit_backlog_limit=65536' but that didn't seem to
 affect the number of these that I was shown. I assume some type of
 throttling might be occurring but there was no notice of this happening on
 the console.
>>> Hello Ian,
>>>
>>> The audit_backlog_limit parameter likely only applies to the auditd
>>> daemon. If your audit messages are written to dmesg instead, you'll
>>> reach a different rate limiting method. (Though I thought that one would
>>> include a message about printk rate limits being hit.)
>>>
>>> Regular printk message rate can be controlled via
>>> /proc/sys/kernel/printk_ratelimit
>>> /proc/sys/kernel/printk_ratelimit_burst
>>> details are in the kernel source file Documentation/sysctl/kernel.txt
>>>
>> yes, if auditd isn't registered messages will go to the kernel ring
>> buffer and printk_ratelimit is used.
>>
>> there is a warning message that audit messages are lost, however it
>> may not always trigger. Depending on what triggered the loss, failure
>> mode etc.
> 
> That was what I needed.  I thought I was limited to kernel boot parameters 
> and apparently printk_ratelimit wasn't one of them.
> 
 2) If I want to worry about restricting binaries later, but only want to
 "whitelist" at this point in time, is there a generic profile that I can
 create that will grant all permissions?
>>> We should probably write a tool to generate one appropriate for the system
>>> it's on, since it's not obvious how to do this by hand. But "Allow
>>> Everything" profiles probably shouldn't be the norm, so maybe a little
>>> friction is worthwhile.
>>>
>>> Anyway, it would look something like:
>>>
>>> profile profilename /attachment/specification {
>>>   network,
>>>   signal,
>>>   file,
>>>   mount,
>>>   pivot_root,
>>>   ptrace,
>>>   unix,
>>>   dbus,
>>> }
>>>
>> it happens enough that it is coming as a new feature, you unfortunately
>> just can't use it yet
> 
> No worries, I used that list (plus 'umount', and 'capability') to quiet the 
> audit output for systemd while it was doing things before transitioning.  At 
> this point all I'm trying to do is mimic how the system currently boots 
> without Apparmor enabled.  I'm not currently able to fully boot into the 
> system since two services "systemd-resolved" and "sytemd-udevd" fail to 
> finish loading.
> 
> For instance, if I add the kernel parameter "emergency" so that I boot 
> directly to shell after initramfs, remount root as rw, and attempt to start 
> the resolve service, I get this:
> 
> # systemctl start systemd-resolved
>   
>   
>  
> [  701.817178] systemd[1]: Starting Network Name Resolution...
>   
>   
>  
> [  701.821550] systemd[411]: systemd-resolved.service: Failed to connect 
> stdout to the journal socket, ignoring: No such file or directory 
>   
>   
> [  701.904706] audit: type=1400 audit(1558982354.096:69): 
> apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup - 
> disconnected path" error=-13 profile="init-systemd" name="run/systemd/notify" 
> pid=411 comm="systemd-resolve" requested_mask="w" denied_mask="w" fsuid=10
> [  701.908775] audit: type=1400 audit(1558982354.096:70): 
> apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup - 
> disconnected path" error=-13 profile="init-systemd" name="run/systemd/notify" 
> pid=411 comm="systemd-resolve" requested_mask="r" denied_mask="r" fsuid=10
> [  701.912779] audit: type=1400 audit(1558982354.096:71): 
> apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup - 
> disconnected path" error=-13 profile="init-systemd" name="run/systemd/notify" 
> pid=411 comm="systemd-resolve" requested_mask="w" denied_mask="w" fsuid=10
> [  701.916948] audit: type=1400 audit(1558982354.096:72): 
> apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup - 
> disconnected path" error=-13 profile="init-systemd" name="run/systemd/notify" 
> pid=411 comm="systemd-resolve" requested_mask="r" denied_mask="r" fsuid=10
> [  791.827056] systemd[1]: systemd-resolved.service: Start operation 
> timed out. Terminating.   
>   

Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

2019-05-27 Thread Ian 


On 5/27/19 12:08 PM, Ian wrote:


Does apparmor have the same problem as selinux where there are 
"security aware" programs that don't properly honor enforcement 
settings, or is this an inheritance problem that I'm not correctly 
addressing?




Adding "attach_disconnected" to the flags parameter of the init-systemd 
profile was required to get the system to fully boot.  I assume this was 
necessary because of the transition from initramfs, however the 
"ALLOWED" audit log entries really threw me there -- that and my ability 
to run lots of other commands without issue in that "emergency" mode 
didn't make this an obvious fix.


This initramfs transition is a tricky bit of business -- I assume I'll 
want to have a different profile for systemd for the chrooted system and 
that when the apparmor service starts, the profile will get replaced, 
however I thought that profile changes like this aren't seen by 
currently executing processes -- one has to restart the process for the 
change to take effect?  Then there's the timing of when journald and 
auditd starts.  Ideally I'd like to keep the full-permission profile I 
set up in inittamfs for systemd, but then somehow deny any type of 
inheritance once the AppArmor service starts.


Any advice on how to proceed? -- If it is true that all child processes 
will, by default, inherit the permissions from the init-systemd profile 
unless I add deny rules -- I'm back at square one with a blacklist setup.



--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

2019-05-27 Thread Ian 


On 5/24/19 6:16 PM, John Johansen wrote:

On 5/24/19 5:10 PM, Seth Arnold wrote:

On Fri, May 24, 2019 at 03:28:21PM -0700, Ian wrote:

It's like I'm only getting a few of these at a time -- I added this to the
kernel boot parameter: 'audit_backlog_limit=65536' but that didn't seem to
affect the number of these that I was shown. I assume some type of
throttling might be occurring but there was no notice of this happening on
the console.

Hello Ian,

The audit_backlog_limit parameter likely only applies to the auditd
daemon. If your audit messages are written to dmesg instead, you'll
reach a different rate limiting method. (Though I thought that one would
include a message about printk rate limits being hit.)

Regular printk message rate can be controlled via
/proc/sys/kernel/printk_ratelimit
/proc/sys/kernel/printk_ratelimit_burst
details are in the kernel source file Documentation/sysctl/kernel.txt


yes, if auditd isn't registered messages will go to the kernel ring
buffer and printk_ratelimit is used.

there is a warning message that audit messages are lost, however it
may not always trigger. Depending on what triggered the loss, failure
mode etc.


That was what I needed.  I thought I was limited to kernel boot 
parameters and apparently printk_ratelimit wasn't one of them.



2) If I want to worry about restricting binaries later, but only want to
"whitelist" at this point in time, is there a generic profile that I can
create that will grant all permissions?

We should probably write a tool to generate one appropriate for the system
it's on, since it's not obvious how to do this by hand. But "Allow
Everything" profiles probably shouldn't be the norm, so maybe a little
friction is worthwhile.

Anyway, it would look something like:

profile profilename /attachment/specification {
   network,
   signal,
   file,
   mount,
   pivot_root,
   ptrace,
   unix,
   dbus,
}


it happens enough that it is coming as a new feature, you unfortunately
just can't use it yet


No worries, I used that list (plus 'umount', and 'capability') to quiet 
the audit output for systemd while it was doing things before 
transitioning.  At this point all I'm trying to do is mimic how the 
system currently boots without Apparmor enabled.  I'm not currently able 
to fully boot into the system since two services "systemd-resolved" and 
"sytemd-udevd" fail to finish loading.


For instance, if I add the kernel parameter "emergency" so that I boot 
directly to shell after initramfs, remount root as rw, and attempt to 
start the resolve service, I get this:


   # systemctl start systemd-resolved
   [  701.817178] systemd[1]: Starting Network Name Resolution...
   [  701.821550] systemd[411]: systemd-resolved.service: Failed to
   connect stdout to the journal socket, ignoring: No such file or
   directory
   [  701.904706] audit: type=1400 audit(1558982354.096:69):
   apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
   disconnected path" error=-13 profile="init-systemd"
   name="run/systemd/notify" pid=411 comm="systemd-resolve"
   requested_mask="w" denied_mask="w" fsuid=10
   [  701.908775] audit: type=1400 audit(1558982354.096:70):
   apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
   disconnected path" error=-13 profile="init-systemd"
   name="run/systemd/notify" pid=411 comm="systemd-resolve"
   requested_mask="r" denied_mask="r" fsuid=10
   [  701.912779] audit: type=1400 audit(1558982354.096:71):
   apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
   disconnected path" error=-13 profile="init-systemd"
   name="run/systemd/notify" pid=411 comm="systemd-resolve"
   requested_mask="w" denied_mask="w" fsuid=10
   [  701.916948] audit: type=1400 audit(1558982354.096:72):
   apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
   disconnected path" error=-13 profile="init-systemd"
   name="run/systemd/notify" pid=411 comm="systemd-resolve"
   requested_mask="r" denied_mask="r" fsuid=10
   [  791.827056] systemd[1]: systemd-resolved.service: Start operation
   timed out. Terminating.
   [  791.834261] audit: type=1400 audit(1558982444.024:73):
   apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
   disconnected path" error=-13 profile="init-systemd"
   name="run/systemd/notify" pid=411 comm="systemd-resolve"
   requested_mask="w" denied_mask="w" fsuid=10
   [  791.857002] audit: type=1400 audit(1558982444.024:74):
   apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
   disconnected path" error=-13 profile="init-systemd"
   name="run/systemd/notify" pid=411 comm="systemd-resolve"
   requested_mask="r" denied_mask="r" fsuid=10
   [  791.869512] audit: type=1400 audit(1558982444.048:75):
   apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
   disconnected path" error=-13 profile="init-systemd"
   name="run/systemd/notify" pid=411 comm="systemd-resolve"
   requested_mask="w" denied_mask="w" fsuid=10
   [  791.874754] audit:

Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

2019-05-24 Thread John Johansen 
On 5/24/19 5:10 PM, Seth Arnold wrote:
> On Fri, May 24, 2019 at 03:28:21PM -0700, Ian wrote:
>> It's like I'm only getting a few of these at a time -- I added this to the
>> kernel boot parameter: 'audit_backlog_limit=65536' but that didn't seem to
>> affect the number of these that I was shown. I assume some type of
>> throttling might be occurring but there was no notice of this happening on
>> the console.
> 
> Hello Ian,
> 
> The audit_backlog_limit parameter likely only applies to the auditd
> daemon. If your audit messages are written to dmesg instead, you'll
> reach a different rate limiting method. (Though I thought that one would
> include a message about printk rate limits being hit.)
> 
> Regular printk message rate can be controlled via
> /proc/sys/kernel/printk_ratelimit
> /proc/sys/kernel/printk_ratelimit_burst
> details are in the kernel source file Documentation/sysctl/kernel.txt
> 

yes, if auditd isn't registered messages will go to the kernel ring
buffer and printk_ratelimit is used.

there is a warning message that audit messages are lost, however it
may not always trigger. Depending on what triggered the loss, failure
mode etc.


>> 1) Can I separate out the different "comm" matches into different profile
>> files or do I need to maintain one monolithic file?
> 
> You can't filter directly on comm. (You can do the profile transitions on
> exec, though, as you already know.)
> 
>> 2) If I want to worry about restricting binaries later, but only want to
>> "whitelist" at this point in time, is there a generic profile that I can
>> create that will grant all permissions?
> 
> We should probably write a tool to generate one appropriate for the system
> it's on, since it's not obvious how to do this by hand. But "Allow
> Everything" profiles probably shouldn't be the norm, so maybe a little
> friction is worthwhile.
> 
> Anyway, it would look something like:
> 
> profile profilename /attachment/specification {
>   network,
>   signal,
>   file,
>   mount,
>   pivot_root,
>   ptrace,
>   unix,
>   dbus,
> }
> 

it happens enough that it is coming as a new feature, you unfortunately
just can't use it yet


>> 3) Why did this "Warning from stdin (line 1): /sbin/apparmor_parser: cannot
>> use or update cache, disable, or for" disappear when I started to use
>> profile files instead of echo for apparmor_parser?
> 
> The filename used for the compiled cache files is based on the filename of
> the input files.
> 

really using the parser from the initrd is a bad idea. Ideally you 
bundle just the cache necessary for that initrd's kernel. And instead of
doing a regular profile load you do a binary load.

currently there isn't a good way to do this. But you can do it with
the parser

apparmor_parser --binary /dir/to/cache/*


>> 4) Will I be able to retain the apparmor profile files that come with
>> Ubuntu?  I assume I'll need to duplicate most of the stuff I've done in
>> initramfs into /etc/apparmor.d somewhere?
> 
> Likely these will need some changes. You'll probably want more strict
> profiles than we've provided, anyway, since we've written the profiles
> with the contrasting goals of providing some safety but without too
> much compromise in useability. If you're doing this full-system policy
> investigation you'll probably want to make different tradeoffs than
> we have.
> 

Indeed, even the current abstractions are not designed for stricter
policies

>> 5) How does apparmor handle multiple profiles that match on the same file? 
>> Is the reason why my separate init profile file ignored because the
>> init-systemd one already matched on it?
> 
> This is a bit involved.
> 
it helps to think about it from a profile point of view

> There's attachments using attachment specifications from unconfined
> processes and Px rules with wildcards, then there's profile-directed
> transitions.
> 
> When going from unconfined to confined, or when using a Px rule where at
> least some of the pathname is written with wildcards or other globbing,
> then AppArmor will try to apply policy in the order of most specific to
> least specific name. A profile attachment without wildcards should beat a
> profile with wildcards or globbing. Multiple profile attachments with
> wildcards or globs should pick the longest match.
> 

The profile always controls the transition. There are different rules
to determine which transition type to use.

First the profile rule pattern that matches the executable is used

1. /a/**  ux,
2. /a/b/* Px,
3. /a/b/c ix,

any overlap between rules with different permissions have to resolved
at policy compile time, otherwise the policy compile will fail.

the general rule is exact match wins, then longest left match. The
compiler can't currently deal with dominance for overlapping expressions
so conflicting overllapping exec rules may cause the compile to fail.

but in the above set of rules, 3 is an exact match and would win if
it matces the exec, then 2, and then 1.

Once you know which

Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

2019-05-24 Thread Seth Arnold 
On Fri, May 24, 2019 at 03:28:21PM -0700, Ian wrote:
> It's like I'm only getting a few of these at a time -- I added this to the
> kernel boot parameter: 'audit_backlog_limit=65536' but that didn't seem to
> affect the number of these that I was shown. I assume some type of
> throttling might be occurring but there was no notice of this happening on
> the console.

Hello Ian,

The audit_backlog_limit parameter likely only applies to the auditd
daemon. If your audit messages are written to dmesg instead, you'll
reach a different rate limiting method. (Though I thought that one would
include a message about printk rate limits being hit.)

Regular printk message rate can be controlled via
/proc/sys/kernel/printk_ratelimit
/proc/sys/kernel/printk_ratelimit_burst
details are in the kernel source file Documentation/sysctl/kernel.txt

> 1) Can I separate out the different "comm" matches into different profile
> files or do I need to maintain one monolithic file?

You can't filter directly on comm. (You can do the profile transitions on
exec, though, as you already know.)

> 2) If I want to worry about restricting binaries later, but only want to
> "whitelist" at this point in time, is there a generic profile that I can
> create that will grant all permissions?

We should probably write a tool to generate one appropriate for the system
it's on, since it's not obvious how to do this by hand. But "Allow
Everything" profiles probably shouldn't be the norm, so maybe a little
friction is worthwhile.

Anyway, it would look something like:

profile profilename /attachment/specification {
  network,
  signal,
  file,
  mount,
  pivot_root,
  ptrace,
  unix,
  dbus,
}

> 3) Why did this "Warning from stdin (line 1): /sbin/apparmor_parser: cannot
> use or update cache, disable, or for" disappear when I started to use
> profile files instead of echo for apparmor_parser?

The filename used for the compiled cache files is based on the filename of
the input files.

> 4) Will I be able to retain the apparmor profile files that come with
> Ubuntu?  I assume I'll need to duplicate most of the stuff I've done in
> initramfs into /etc/apparmor.d somewhere?

Likely these will need some changes. You'll probably want more strict
profiles than we've provided, anyway, since we've written the profiles
with the contrasting goals of providing some safety but without too
much compromise in useability. If you're doing this full-system policy
investigation you'll probably want to make different tradeoffs than
we have.

> 5) How does apparmor handle multiple profiles that match on the same file? 
> Is the reason why my separate init profile file ignored because the
> init-systemd one already matched on it?

This is a bit involved.

There's attachments using attachment specifications from unconfined
processes and Px rules with wildcards, then there's profile-directed
transitions.

When going from unconfined to confined, or when using a Px rule where at
least some of the pathname is written with wildcards or other globbing,
then AppArmor will try to apply policy in the order of most specific to
least specific name. A profile attachment without wildcards should beat a
profile with wildcards or globbing. Multiple profile attachments with
wildcards or globs should pick the longest match.

Profile-directed transitions (-> in the rules) will take precedence
over the attachment-directed transitions. I believe in this case every
execution must have exactly one possible outcome but I'm less sure
of this.

I hope this helps.

Thanks


signature.asc
Description: PGP signature
-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor