[apparmor] [PATCH][next] apparmor: remove useless static inline function is_deleted

[Colin Ian King]

The inlined function is_deleted is redundant, it is not called at all
from any function in security/apparmor/file.c and so it can be removed.

Cleans up clang scan build warning:
security/apparmor/file.c:153:20: warning: unused function
'is_deleted' [-Wunused-function]

Signed-off-by: Colin Ian King 
---
 security/apparmor/file.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/security/apparmor/file.c b/security/apparmor/file.c
index c03eb7c19f16..d52a5b14dad4 100644
--- a/security/apparmor/file.c
+++ b/security/apparmor/file.c
@@ -144,19 +144,6 @@ int aa_audit_file(const struct cred *subj_cred,
return aa_audit(type, profile, , file_audit_cb);
 }
 
-/**
- * is_deleted - test if a file has been completely unlinked
- * @dentry: dentry of file to test for deletion  (NOT NULL)
- *
- * Returns: true if deleted else false
- */
-static inline bool is_deleted(struct dentry *dentry)
-{
-   if (d_unlinked(dentry) && d_backing_inode(dentry)->i_nlink == 0)
-   return true;
-   return false;
-}
-
 static int path_name(const char *op, const struct cred *subj_cred,
 struct aa_label *label,
 const struct path *path, int flags, char *buffer,
-- 
2.39.2

Re: [apparmor] (subset) [PATCH v2 3/8] autofs: set ctime as well when mtime changes on a dir

[Ian Kent]

On 14/6/23 16:30, Christian Brauner wrote:

On Mon, 12 Jun 2023 06:45:19 -0400, Jeff Layton wrote:

When adding entries to a directory, POSIX generally requires that the
ctime also be updated alongside the mtime.



Can't find a tree for this patch, so picking this patch up unless told 
otherwise.


There's relatively few changes to autofs and Linus asked me to send

changes via. Al or Andrew so there's no point in maintaining a tree

anyway.


Ian



---

Applied to the vfs.misc branch of the vfs/vfs.git tree.
Patches in the vfs.misc branch should appear in linux-next soon.

Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.

It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs.misc

[3/8] autofs: set ctime as well when mtime changes on a dir
   https://git.kernel.org/vfs/vfs/c/9b37b3342a98

Re: [apparmor] [PATCH v2 3/8] autofs: set ctime as well when mtime changes on a dir

[Ian Kent]

On 12/6/23 18:45, Jeff Layton wrote:

When adding entries to a directory, POSIX generally requires that the
ctime also be updated alongside the mtime.

Signed-off-by: Jeff Layton 


Acked-by: Ian Kent 



---
  fs/autofs/root.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/autofs/root.c b/fs/autofs/root.c
index 6baf90b08e0e..93046c9dc461 100644
--- a/fs/autofs/root.c
+++ b/fs/autofs/root.c
@@ -600,7 +600,7 @@ static int autofs_dir_symlink(struct mnt_idmap *idmap,
p_ino = autofs_dentry_ino(dentry->d_parent);
p_ino->count++;
  
-	dir->i_mtime = current_time(dir);

+   dir->i_mtime = dir->i_ctime = current_time(dir);
  
  	return 0;

  }
@@ -633,7 +633,7 @@ static int autofs_dir_unlink(struct inode *dir, struct 
dentry *dentry)
d_inode(dentry)->i_size = 0;
clear_nlink(d_inode(dentry));
  
-	dir->i_mtime = current_time(dir);

+   dir->i_mtime = dir->i_ctime = current_time(dir);
  
  	spin_lock(>lookup_lock);

__autofs_add_expiring(dentry);
@@ -749,7 +749,7 @@ static int autofs_dir_mkdir(struct mnt_idmap *idmap,
p_ino = autofs_dentry_ino(dentry->d_parent);
p_ino->count++;
inc_nlink(dir);
-   dir->i_mtime = current_time(dir);
+   dir->i_mtime = dir->i_ctime = current_time(dir);
  
  	return 0;

  }

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

[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...

[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...

[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 
<https://lists.ubuntu.com/mailman/listinfo/apparmor>:/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 ap

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

[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...

[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

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

[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...

[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 -
  

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

[Ian]

I've followed the wiki article here:

https://gitlab.com/apparmor/apparmor/wikis/FullSystemPolicy

However, I've got a number of questions I was hoping someone could help 
clarify for me.
First, let me walk through what I did after step 6 (reboot after 
update-initramfs -u):

From the console during boot:

   Begin: Running /scripts/init-bottom ... Warning from stdin (line 1):
   /sbin/apparmor_parser: cannot use or update cache, disable, or
   forc[   36.264702] audit: type=1400 audit(1558716282.248:2):
   apparmor="STATUS" operation="profile_load" profile="unconfined"
   name="init-systemd"
   e-complain via stdin
   done.
   [   36.380094] audit: type=1400 audit(1558716282.360:3):
   apparmor="ALLOWED" operation="open" profile="init-systemd"
   name="/etc/ld.so.cache" pid=1 comm="init" requested_mask="r"
   denied_mask="r" fsuid=0 ouid=0
   [   36.383988] audit: type=1400 audit(1558716282.364:4):
   apparmor="ALLOWED" operation="open" profile="init-systemd"
   name="/lib/x86_64-linux-gnu/libc-2.27.so" pid=1 comm="init"
   requested_mask="r" denied_mask="r" fsuid=0 ouid=0
   [   36.389412] audit: type=1400 audit(1558716282.372:5):
   apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
   name="/lib/x86_64-linux-gnu/libc-2.27.so" pid=1 comm="init"
   requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
   [   36.393851] audit: type=1400 audit(1558716282.376:6):
   apparmor="ALLOWED" operation="open" profile="init-systemd"
   name="/lib/systemd/libsystemd-shared-237.so" pid=1 comm="init"
   requested_mask="r" denied_mask="r" fsuid=0 ouid=0
   [   36.397457] audit: type=1400 audit(1558716282.380:7):
   apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
   name="/lib/systemd/libsystemd-shared-237.so" pid=1 comm="init"
   requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
   [   36.401758] audit: type=1400 audit(1558716282.384:8):
   apparmor="ALLOWED" operation="open" profile="init-systemd"
   name="/lib/x86_64-linux-gnu/librt-2.27.so" pid=1 comm="init"
   requested_mask="r" denied_mask="r" fsuid=0 ouid=0
   [   36.409685] audit: type=1400 audit(1558716282.392:9):
   apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
   name="/lib/x86_64-linux-gnu/librt-2.27.so" pid=1 comm="init"
   requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
   [   36.413464] audit: type=1400 audit(1558716282.396:10):
   apparmor="ALLOWED" operation="open" profile="init-systemd"
   name="/lib/x86_64-linux-gnu/libseccomp.so.2.3.1" pid=1 comm="init"
   requested_mask="r" denied_mask="r" fsuid=0 ouid=0
   [   36.416835] audit: type=1400 audit(1558716282.400:11):
   apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
   name="/lib/x86_64-linux-gnu/libseccomp.so.2.3.1" pid=1 comm="init"
   requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0


Now, since the init-systemd profile doesn't contain any rules, this is 
expected (and wanted).  However, I tried a number of things to get rid 
of them and only one of them worked.


First, to make sure I understand what those log entries are saying:

the "init" program is attempted to read and/or memory map certain files, 
however due to the init-systemd profile, if it wasn't set to complain, 
these actions would have been blocked.


My first thought was to create a new init profile .. something like:

   profile init /init flags=(complain) {

    # init in initramfs is at the root, not /sbin/

    /etc/ld.so.cache    r,

    /lib/**                    rm,

   }

however after adding a new apparmor_parser command to the apparmor 
script to load this in init-bottom, nothing changed after reboot.


So then I thought I needed to create a sub profile within the 
init-systemd profile for init, however, I probably didn't do this 
correctly, or it just won't work:


   /init        Cx -> init


   profile init flags=(complain) {

    /etc/ld.so.cache r,

    /lib/**                rm,

   }

Again, those same log entries returned.

What worked was to modify the init-systemd profile directly:

   profile init-systemd /lib/systemd/systemd flags=(complain) {

    /etc/ld.so.cache    r,
    /lib/**            rm,

   }

However, this isn't ideal because, I think, it means all things that 
systemd runs inherits these permissions, not just init.


I noticed something else too -- after that worked, I got a new list of 
additional audit messages:


   [   38.840399] audit: type=1400 audit(1558733899.848:5):
   apparmor="ALLOWED" operation="open" profile="init-systemd"
   name="/usr/lib/x86_64-linux-gnu/libip4tc.so.0.1.0" pid=1 comm="init"
   requested_mask="r" denied_mask="r" fsuid=0 ouid=0
   [   38.843656] audit: type=1400 audit(1558733899.848:6):
   apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
   name="/usr/lib/x86_64-linux-gnu/libip4tc.so.0.1.0" pid=1 comm="init"
   requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
   [   38.852170] audit: type=1400 audit(1558733899.860:7):
   apparmor="ALLOWED" 

[apparmor] [Merge] lp:~colin-king/apparmor/fix-arm64-test-builds into lp:apparmor

[Colin Ian King]

Colin Ian King has proposed merging 
lp:~colin-king/apparmor/fix-arm64-test-builds into lp:apparmor.

Requested reviews:
  AppArmor Developers (apparmor-dev)

For more details, see:
https://code.launchpad.net/~colin-king/apparmor/fix-arm64-test-builds/+merge/321876

This fixes build issues for the readdir test for arm64 where getdents(2) is not 
wired up as a system call but gendents64(2) is available.  This changes the 
preference to use the 64 bit system call by default  if it is available on 64 
bit systems.
-- 
Your team AppArmor Developers is requested to review the proposed merge of 
lp:~colin-king/apparmor/fix-arm64-test-builds into lp:apparmor.
=== modified file 'tests/regression/apparmor/readdir.c'
--- tests/regression/apparmor/readdir.c	2010-12-20 20:29:10 +
+++ tests/regression/apparmor/readdir.c	2017-04-04 15:15:48 +
@@ -6,6 +6,7 @@
  *	published by the Free Software Foundation, version 2 of the
  *	License.
  */
+#define _GNU_SOURCE
 
 #include 
 #include 
@@ -20,7 +21,11 @@
 int main(int argc, char *argv[])
 {
 	int fd;
+#if defined(SYS_getdents64)
+	struct dirent64 dir;
+#else
 	struct dirent dir;
+#endif
 
 	if (argc != 2){
 		fprintf(stderr, "usage: %s dir\n",
@@ -42,7 +47,11 @@
 	*/
 
 	/* getdents isn't exported by glibc, so must use syscall() */
+#if defined(SYS_getdents64)
+	if (syscall(SYS_getdents64, fd, , sizeof(struct dirent64)) == -1){
+#else
 	if (syscall(SYS_getdents, fd, , sizeof(struct dirent)) == -1){
+#endif
 		printf("FAIL - getdents  %s\n", strerror(errno));
 		return 1;
 	}

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

Re: [apparmor] AppArmor APIs

[Colin Ian King]

Thanks John,

So far I've been successful from the info you have provided. I've
compiled a policy into a binary blob and got it loaded into a buffer and
successfully loaded this into the kernel.

Colin


On 15/12/15 00:32, John Johansen wrote:
> On 12/14/2015 07:44 AM, Colin Ian King wrote:
>> Hi there,
>>
>> I'm looking at writing some stress tests for AppArmor, so I'd like to
>> construct some simple rules and insert/remove them.  I looked for some
>> API documentation, but all I can find is:
>>
>> http://wiki.apparmor.net/index.php/AppArmorAPIs
>>
>> Are there any API docs, guides or worked examples for libaaparse and
>> libapparmor?
>>
> 
> Hey Colin,
> sorry the interfaces aren't better documented. It is one of those perpetual
> todo items. There is a quick view of the basic apis bellow and I'll work on
> getting you some better docs
> 
> The libapparmor api, is fairly well documented in the man pages (though it
> seems the cross refs to find them could stand to be updated)
> 
>   man aa_change_hat
>   aa_change_hatv
>   aa_change_hat_vargs
> 
>   man aa_change_profile
>   aa_change_onexec
> 
>   man  aa_getprocattr_raw
>aa_getprocattr
>aa_gettaskcon
>aa_getcon
>aa_getpeercon_raw
>aa_getpeercon
> 
>   man aa_splitcon
> 
>   man aa_features
>   aa_features_new
>   aa_features_new_from_string
>   aa_features_new_from_kernel
>   aa_features_ref
>   aa_features_unref
>   aa_features_write_to_file
>   aa_features_is_equal
>   aa_features_supports
> 
>   man aa_is_enabled
>   aa_find_mountpoint
> 
>   man aa_kernel_interface
>   aa_kernel_interface_new
>   aa_kernel_interface_ref
>   aa_kernel_interface_unref
>   aa_kernel_interface_load_policy
>   aa_kernel_interface_load_policy_from_file
>   aa_kernel_interface_load_policy_from_fd
>   aa_kernel_interface_replace_policy
>   aa_kernel_interface_replace_policy_from_file
>   aa_kernel_interface_replace_policy_from_fd
>   aa_kernel_interface_remove_policy
>   aa_kernel_interface_write_policy
> 
>   man aa_policy_cache
>   aa_policy_cache_new
>   aa_policy_cache_ref
>   aa_policy_cache_unref
>   aa_policy_cache_remove
>   aa_policy_cache_replace_all
> 
>   man aa_query_label
>   aa_query_file_path
>   aa_query_file_path_len
>   aa_query_link_path_len
>   aa_query_link_path
> 
> 
> 
> the logparsing doesn't seem to be documented at all :(
> The 2 exported functions are
>   aa_log_record *parse_record(char *str)
>   void free_record(aa_log_record *record)
> 
>   with aa_log_record being defined in include/aalogparse.h
> there are a fair number of log parsing tests in 
>   libraries/libapparmor/testsuite/
> 
> there are a set of private functions that a pseudo exported but being private 
> apis may change at any time
> _aa_is_blacklisted;
> _aa_autofree;
> _aa_autoclose;
> _aa_autofclose;
> _aa_dirat_for_each;
> 
> 
> 
> the apparmor_parser flags are fairly well documented in
>   man apparmor_parser
> 
> 
> 
> the lowlevel interfaces are not well documented at all
>   reading of a sockets label is done via
> getsockopt(fd, SOL_SOCKET, SO_PEERSEC, buf, );
> 
>   read of a tasks label is done via
> /proc//attr/current
> 
>   read of a scheduled change at exec via
> /proc//attr/exec
> 
>   read of parent while in a hat
> /proc//attr/prev
> 
>   setting self label (another tasks label can not be directly set) is done by 
> writing to
> /proc//attr/current
> 
>   setting of self label at exec (again another tasks is not allow) is done 
> via writing to
> /proc//attr/exec
> 
>   the /proc//attr/  fscreate  keycreate sockcreate files are currently 
> not used
> 
>   the sock and proc/attr interface are limited to pagesize reads and writes 
> atm
> 
> 
> 
> the apparmor filesystem used for loading and introspecting policy is usually 
> mounted at
>/sys/kernel/security/apparmor.
> 
> Well its not really the apparmor filesystem anymore as it is a sub of the 
> securityfs
> filesystem.  Under this there is
>   ls apparmor/
>   .access  features  .load  .null  policy  profiles  .remove  .replace
> 
> .access - is a file that allows querying permissions. I'll work on getting 
> you some docs
>   on its format
> 
> profiles - flattened, virtualized view of what policy is visible to the 
> inquiring task.
>   I'll work on some better docs 

Re: [apparmor] AppArmor APIs

[Colin Ian King]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/12/15 18:45, Steve Beattie wrote:
> Hey Colin,
> 
> On Tue, Dec 15, 2015 at 05:29:43PM +0000, Colin Ian King wrote:
>> So far I've been successful from the info you have provided. I've
>> compiled a policy into a binary blob and got it loaded into a buffer 
and
>> successfully loaded this into the kernel.
> 
> That's great!
> 
> I'm  curious which elements of apparmor you're trying to stress with
> what you're adding to stress-ng. The general process outline goes like
> this:
> 
>   policy -> apparmor_parser -> kernel policy load interface -> policy 
enforcement
> 
> The first phase, of turning a textual policy into a binary blob,
> occurs entirely in user space, and is likely of little interest to you
.
> 
> The second phase, where a binary policy blob is loaded into the kernel
> and stored in kernel data structures is certainly a valuable place to
> look for problems[1], though it is at this point in time considered a
> mostly trusted interface (you must have CAP_MAC_ADMIN to make use of
> it). However, future plans include this becoming not true, and there
> currently exist tools that auto-generate policy based on templates,
> so it's still a sensitive interface. It seems that this is the area
> you're focusing on?

Currently, I'm just piling a load of different stressors onto the kernel
interfaces using the aa_kernel* userspace API, I've only just started
today, so it is very early "work in progress", c.f:

http://kernel.ubuntu.com/git/cking/stress-ng.git/tree/stress-apparmor.c?
id=1fdb0ca847db3840ab47daae04384608db0149bf

I'm currently hacking some code to force EPROTO failures by twidding the
data being passed to the kernel, and I'll be focusing on the raw
compiled profile blob for the moment.

> 
> It also seems to me that stressing the enforcement side of things
> is valuable, as well as the related interfaces around policy
> domain transitions (changing policy or not on exec(), change_hat(),
> change_profile()). We also have relatively recently added interfaces
> (which I think John referred to earlier) around querying confinement
> status and querying permissions directly.  Exercising and stressing
> these direct interfaces would be great; stressing access mediation
> would be indirect via regular syscalls (e.g. open()).

OK, that's a good place to focus on.

> 
> There are some known existing performance limitations in some of the
> interfaces; for example, change_hat() on a policy with 5 digits of
> hats is slow, due to the in-kernel data structures used.
> 
> Thanks again for your work on this, both in general for stress-ng
> and for specifically adding apparmor to it!
> 
> [1] For anyone looking for an interesting security relevant project
> to take on, extending one of the (syscall) fuzzing tools out
> there to exercise the policy loading interface and other apparmor
> kernel<->userspace interface layers would be a great thing to do.
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWcGGnAAoJEGjCh9/GqAImZSQP/0zqHXnuHRU/8EMrjESTOfrq
99fSX2xfqjpiNE12FlHuXJiQKmxqToIHOf4/r+meHO9JGD26ssy3+ve+SvLRoAwF
fFrsE7mp0MRNNM49NJEH1YOnkba2qdR0PpoMhXeCd4DL2sQCrw9uvmIag0WGdtrL
d8zSDBm5sNiBSlngrtlKXhhyQqdHVuAMfPMfCbh1QJLXmaWU6J/RAMlZNcCUyQHo
5n+yg/7V5eP10evFlpGzEgpoZWyEZGWew4y3OqRIKDCa1WE/IHKSKzWNO+nU4fMr
jIRP3oNPCJvdub26WSpBGIvzUj8FBCukQsX0RsmNlAOC3EZL0yhqsCSjNXHs7i1t
3X/ofz2bR2n6rkeYMcjCdTo2fsYXMoJ3NrGzAgBMM5sIWOt9SlOjz2NuVAdbrz/z
FAllRQKAV7gnsLtYlWpWOwWmf1ae3o1aa8C7/x1RzOmpIj5s5fn/Ighw6VSmf3ub
iJlSaCqHBmWAa8OQCGPKkfpSIAn/MpVApt6Au7W7xKQSzrVr3nqlKwMRHICChyPt
QrxOqAySYSCyGWEZO0ipcVVorjUp1JSizq+90t0lrrhZZ0NBXLgIMjv2IYRVftsF
bp8sxwbXjMMBBb54PYyf4R0/Xcvbzoe4lvNf7WA38O8FIjtWgbJNI1Rjm8Ky4pOp
t8pIhN9EhZL2UfWVDqea
=reFM
-END PGP SIGNATURE-

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

[apparmor] AppArmor APIs

[Colin Ian King]

Hi there,

I'm looking at writing some stress tests for AppArmor, so I'd like to
construct some simple rules and insert/remove them.  I looked for some
API documentation, but all I can find is:

http://wiki.apparmor.net/index.php/AppArmorAPIs

Are there any API docs, guides or worked examples for libaaparse and
libapparmor?

Colin

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