[apparmor] [Bug 1117804] Re: ausearch doesn't show AppArmor denial messages

[Seth Arnold]

As far as I know, no one has made an effort to try to improve the
situation lately. There's some discussion at
https://lists.ubuntu.com/archives/apparmor/2024-February/013091.html
that may be enlightening, if not encouraging.

Thanks

-- 
You received this bug notification because you are a member of AppArmor
Developers, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1117804

Title:
  ausearch doesn't show AppArmor denial messages

Status in AppArmor:
  Confirmed
Status in audit package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  The following command should display all AVC denials:

  ausearch -m avc

  However, it doesn't work with AppArmor denials. Here's a quick test
  case to generate a denial, search for it with ausearch, and see that
  no messages are displayed:

  $ aa-exec -p /usr/sbin/tcpdump cat /proc/self/attr/current
  cat: /proc/self/attr/current: Permission denied
  $ sudo ausearch -m avc -c cat
  

  ausearch claims that there are no matches, but there's a matching
  audit message if you look in audit.log:

  type=AVC msg=audit(1360193426.539:64): apparmor="DENIED"
  operation="open" parent=8253 profile="/usr/sbin/tcpdump"
  name="/proc/8485/attr/current" pid=8485 comm="cat" requested_mask="r"
  denied_mask="r" fsuid=1000 ouid=1000

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1117804/+subscriptions

Re: [apparmor] apparmor with large profile set

[Seth Arnold]

On Tue, Jul 18, 2023 at 12:28:09AM +0100, Alexandre Pujol wrote:
> Updating the doc to clearly show what is already implemented and what is
> planned would be nice too.

What exactly do you mean with "the doc"? The wiki has a lot of syntax
and semantics around future expansion plans and I've seen dozens, if not
hundreds, of questions from people who found it and tried to use it on
live systems, without success.

In fact I think we've done our users a disservice by having these so
readily available.

I don't really know how to address it, but (a) I'm opposed to putting
*future* work in the manpages (b) even the wiki is weird. If it were in
better shape, it might be easier to mark areas that are hypothetical,
but it's currently just a big dump of 25 years of history.

Thanks


signature.asc
Description: PGP signature

Re: [apparmor] [PATCH v2 08/92] fs: new helper: simple_rename_timestamp

[Seth Arnold]

On Wed, Jul 05, 2023 at 08:04:41PM -0400, Jeff Layton wrote:
> 
> I don't believe it's an issue. I've seen nothing in the POSIX spec that
> mandates that timestamp updates to different inodes involved in an
> operation be set to the _same_ value. It just says they must be updated.
> 
> It's also hard to believe that any software would depend on this either,
> given that it's very inconsistent across filesystems today. AFAICT, this
> was mostly done in the past just as a matter of convenience.

I've seen this assumption in several programs:

mutt buffy.c
https://sources.debian.org/src/mutt/2.2.9-1/buffy.c/?hl=625#L625

  if (mailbox->newly_created &&
  (sb->st_ctime != sb->st_mtime || sb->st_ctime != sb->st_atime))
mailbox->newly_created = 0;


neomutt mbox/mbox.c
https://sources.debian.org/src/neomutt/20220429+dfsg1-4.1/mbox/mbox.c/?hl=1820#L1820

  if (m->newly_created && ((st.st_ctime != st.st_mtime) || (st.st_ctime != 
st.st_atime)))
m->newly_created = false;


screen logfile.c
https://sources.debian.org/src/screen/4.9.0-4/logfile.c/?hl=130#L130

  if ((!s->st_dev && !s->st_ino) || /* stat failed, that's new! */
  !s->st_nlink ||   /* red alert: file unlinked */
  (s->st_size < o.st_size) ||   /*   file truncated */
  (s->st_mtime != o.st_mtime) ||/*file modified */
  ((s->st_ctime != o.st_ctime) &&   /* file changed (moved) */
   !(s->st_mtime == s->st_ctime &&  /*  and it was not a change */
 o.st_ctime < s->st_ctime)))/* due to delayed nfs write */
  {

nemo libnemo-private/nemo-vfs-file.c
https://sources.debian.org/src/nemo/5.6.5-1/libnemo-private/nemo-vfs-file.c/?hl=344#L344

/* mtime is when the contents changed; ctime is when the
 * contents or the permissions (inc. owner/group) changed.
 * So we can only know when the permissions changed if mtime
 * and ctime are different.
 */
if (file->details->mtime == file->details->ctime) {
return FALSE;
}


While looking for more examples, I found a perl test that seems to suggest
that at least Solaris, AFS, AmigaOS, DragonFly BSD do as you suggest:
https://sources.debian.org/src/perl/5.36.0-7/t/op/stat.t/?hl=158#L140


Thanks


signature.asc
Description: PGP signature

Re: [apparmor] Apparmor: global profile queries

[Seth Arnold]

On Wed, Jan 25, 2023 at 01:49:09PM -0500, Murali Selvaraj wrote:
> profile sh_restriction /bin/sh  flags=(attach_disconnected,complain) {
>   /tmp/** r,
> }

If a shell can read it, then a shell can execute it. The only real options
I can think of:

- prevent the shell from reading it
- modify the shell to prevent it from executing anything it reads --
  perhaps require shell scripts to be signed? Disable interactive use?

Do you even need a shell installed on your computer? If you can remove
system(3) and popen(3) calls from all your software, you might be able to
remove the shell, too.

Thanks


signature.asc
Description: PGP signature

Re: [apparmor] Apparmor : Common Query

[Seth Arnold]

On Thu, Sep 22, 2022 at 07:16:32PM -0400, Murali Selvaraj wrote:
> -> How do we approach preparing an Apparmor profile for a shell script as
> the first time I am doing this.
> -> As our embedded device like legacy and many scripts internally invokes
> few other scripts based on the different scenarios.
> -> In such cases, do we have any suggestion to generate an Apparmor profile
> for shell script or any example in our earlier forum queries (If possible,
> please share here as I could not find it).

What will execute your shell script? is it already confined? How you start
to write the profile depends upon how the script is executed.

The easiest is to use complain mode and the interactive tools to get most
of the way there. This can work great if the script is launched via a
systemd service, or by a daemon that accepts on-demand commands to run
it, etc. If it's run via sysv-init or other unusual process supervisor
system it might be a challenge to get the execution environment close
to production use.

If it's run by a systemd service, something like the following might work:

in one terminal:
sudo aa-genprof /path/to/shell/script.sh

in another terminal:
sudo systemctl start servicename
sudo systemctl stop servicename

return to the first terminal and answer the questions.

Then repeat the start process, interact with whatever service it provides
a little bit, then stop it again, and then answer more genprof questions.

Hopefully you can iterate to something that's pretty close to final
quality this way.

If your script isn't started via a 'clean' process supervisor like
systemd, you may need to write a complain mode profile by hand, reboot,
use aa-logprof to get questions / answers; and repeat via repeated
reboots.

I hope this helps.

Thanks


signature.asc
Description: PGP signature

Re: [apparmor] Apparmor : Common Query

[Seth Arnold]

On Thu, Sep 22, 2022 at 02:48:43PM -0400, Murali Selvaraj wrote:
> *foo.sh*
> #!/bin/sh
> if condition
>/bin/sh script_1.sh
> fi
> /bin/sh script_2.sh
> while [ condition ]
> do
>if [ condition ]
> /bin/sh script_3.sh
>else
> /bin/sh script_4.sh
>fi
> done
> 
> *Queries:*
> 
> -  If we create a separate profile for each script (for instance,
> script1_1.sh)  and consolidate to one profile for foo.sh
> -  However, we will try to perform/exercise all possible test cases to
> execute all code paths while running in complain mode to gather logs
>for preparing the profiles.
> -  Do we have any recommendations to prepare an Apparmor profile for Linux
> scripts?

Does your actual software use /bin/sh foo.sh intentionally? Why? executing
foo.sh via direct execution will make domain transitions *vastly* easier.
This is worth re-writing your software to directly execute your other
scripts rather than executing your interpreter to execute the scripts.

> *Question 2:*
> 
> - In my embedded system most of the rootfs files are in READ-ONLY except a
> few directory,files are READ-WRITE (for instance, non-volatile partitions
> and so on).
> - All libraries in my device rootfs are located in READ-ONLY folders (
> /lib/, /usr/lib and so on).
> - While preparing profiles for my applications, I am adding each entry of
> the library as per the application access.
> 
>   /lib/** mr,
>   /usr/lib/** mr,
> 
> - Since all libraries are in READ-ONLY, if we allow all libraries (with
> wild-card) any possible security leak?

Yes, though it's hard to say for sure. It's possible to mount new
filesystems on top of read-only mounts, or on top of read-only files and
directories.

If you use the wildcard, it might be easier to drop in a malicious payload
without affecting the rest of the system.

> - Do we still have command-line injection possible to the library too? I am
> trying to understand here, how do we affect security leaks if we allow all
> libraries (since they are in READ-ONLY directory).

I'm not entirely sure how to approach this question. Any library that
uses system(3) or popen(3) (or implements their own similar functionaliy)
could have command-line injection problems. AppArmor policies could
prevent the shell from executing at all. AppArmor policies could restrict
which executables the shell could start, which files can be accessed,
which signals could be sent, etc.

I hope this helps.

Thanks


signature.asc
Description: PGP signature

Re: [apparmor] Disable apparmor without restart

[Seth Arnold]

On Sun, Jan 02, 2022 at 08:49:05PM -0800, John Johansen wrote:
> On 12/28/21 2:00 AM, Sina Kashipazha wrote:
> > Hey there,
> > 
> > I have two hosts in my setup, one of them uses AppArmor (h1), and
> > another one doesn't have it (h2). I want to use virsh to live migrate
> > my VMs from h1 to h2, but I'm not able to do that because the h2 host
> > doesn't have the AppArmor policy.
> > 
> > I was wondering, is it possible to edit the XML configuration file of
> > the VM and disable AppArmor without restarting the VMs?
> > 
> 
> AFAIK no, but you can manually remove the apparmor protection on the VM
> by unloading the profiles.
> 
> sudo aa-teardown
> 
> will remove apparmor protections from the whole system.
> 
> if you want to be more selective you can just unload the the VMs
> profiles. Using apparmor_parser -R

My guess is that you're probably getting stuck on a *libvirt* check
to make sure that source and destination systems are 'identical', and
actually tearing down the apparmor profiles in place at runtime behind
the back of libvirt will just lead to a very confused libvirt environment.

It's my theory that trying to disable AppArmor itself on the sending
machine isn't going to get you to where you want to go.

I don't have an environment available for testing, but my guess is the
virsh dumpxml --migratable may be able to emit XML that omits the security
information.

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

Re: [apparmor] profile injection

[Seth Arnold]

On Wed, Nov 24, 2021 at 02:01:21PM +0200, beroal wrote:
> into the file referred by $RP. This allegedly replaces the contents of
> profile $NM with $RM which is not what the sysadmin intended.
> 
> Reading the `include_filename` function in `parser/parser_lex.l` and my
> experiment gave me an impression that this attack is totally possible. Is
> there any way to protect from it?

Whoever writes AppArmor policy has complete control over the resulting
rules. There's no equivalent of execv(2) style arrays or sql parameterized
queries -- there's no way to say "the following untrusted input is to be
interpreted as a filename and only a filename".

If you want to accept input from untrusted users and feed it to
apparmor_parser, you'll have to supply the sanitization yourself. Yes,
this is a very high bar.

You'd be a lot better placed to use a template system of some sort that
can have rules placed on smaller pieces of policy -- eg, allow access to:

/path/to/package/data/$PACKAGENAME/ r,
/path/to/package/data/$PACKAGENAME/**/ r,
/path/to/package/data/$PACKAGENAME/** rwlk,

and make sure that $PACKAGENAME matches a regex [a-zA-Z0-9]+ before
rendering the template into policy.

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

Re: [apparmor] [PATCH v2] apparmor: enable raw text policy

[Seth Arnold]

On Wed, Sep 08, 2021 at 11:43:27AM -0300, Georgia Garcia wrote:
> So when there's a call for raw_data and raw_text by the same process,
> the refcount will be increased twice and loaddata will be decompressed
> twice having the result in two different private variables. That
> applies for two or more processes as well.
> 
> Just to be sure, I tested these scenarios and it worked as expected.
> 
> I'm not sure if that's the issues you were concerned about and if I
> made myself clear, so please let me know. I could be missing something
> too :)

Excellent, those were indeed the cases I was worried about -- thanks for
double-checking. (Maybe hold on to those tests so that we can stick them
into our test suite once this is integrated.)

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

Re: [apparmor] [PATCH v2] apparmor: enable raw text policy

[Seth Arnold]

On Fri, Sep 03, 2021 at 06:31:49PM -0300, Georgia Garcia wrote:
> +static const struct file_operations rawtext_fops = {
> + .open = rawdata_open,
> + .read = rawtext_read,
> + .llseek = generic_file_llseek,
> + .release = rawdata_release,
> +};

Hey Georgia, I'm curious if the rawdata_open and rawdata_release here are
correct. If they are correct, is there any problem if the same process
opens both the raw_text and the raw_data files? Is there any problem if
two or more processes open both raw_text and raw_data?

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

Re: [apparmor] [PATCH] apparmor: enable raw text policy

[Seth Arnold]

On Tue, Jul 27, 2021 at 06:51:34PM -0300, Georgia Garcia wrote:
> + if (aa_g_raw_text) {
> + dent = aafs_create_file("raw_text", S_IFREG | 0444, dir,
> + rawdata, _fops);

Cool :) The only thing that stood out to me is the permission: some people
like to store their policy in /etc/apparmor.d/ with restrictive modes for
whatever reason, and this may be more open than they'd like. 0400 might be
a better fit for some.

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

Re: [apparmor] Apparmor profile: mount/umount issue [ non-root application ]

[Seth Arnold]

On Fri, Jul 23, 2021 at 05:07:23PM +0530, Murali Selvaraj wrote:
> -> Since we have required CAPs CAP_SYS_ADMIN in the profile and it
> applied to the process as well but still observing
>that mount and unmount fails [ "must be superuser to mount" and
> "must be superuser to unmount" ].

How did you grant CAP_SYS_ADMIN to the process?

> -> Does mount/umount restriction is done by util-linux package? As per
> our understanding CAP_SYS_ADMIN (capable) check
>would be taken care of in Kernel code. It looks like user space
> (util-linux package) restricts this permission issue.
>Please clarify my understanding.

No, mount(8) is simply reporting the error message from the mount(2)
system call.

> -> What would be ideal options to resolve the issue ( "non-root" user
> does mount/umount operation ).

If you didn't get any DENIED entries from AppArmor in your logs, then I
suspect that your process didn't actually get the CAP_SYS_ADMIN privilege
from its parent.

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

Re: [apparmor] Addressing limitations in DAC

[Seth Arnold]

On Sun, Jun 27, 2021 at 03:01:10AM +0530, Murali Selvaraj wrote:
> - I would like to understand limitations in DAC which are addressed in
> Apparmor. Please share any simple examples to understand this query.

The usual example is users using chmod 777 on their own documents because
they heard once that this solves permissions problems. A MAC tool
restricts what processes can do with this file, even though the DAC
permisssions allow all processes to read and write the file.

A less user-oriented example is something like Apache: you may want it to
serve your website, but not serve your /etc/passwd file (which is
intentionally world readable.)

> - Does command line injection (SECVUL) issue be addressed if we use
> Apparmor?  If so, give a real time example for the reference.

Not really, though it depends upon the specifics of your software: if
your software accepts filenames as command line parameters, AppArmor can
help ensure that it only has permission to open some subset of files on
the system.

> - In other words, by restricting the system resource using Apparmor,
> what are the major security leaks are we avoiding? Pls share
> additional details if available.

You can make sure that your web server can only serve web pages,
your database server can only import and export data through specific
locations, your interactive users over ssh can't perform administrative
actions without using your specific auditing tool, You could make sure
that the software that analyzes photos can't do networking and can't
run anything else that can do networking, either. Or you could make
sure that some proprietary tool that you must run but you can't audit
the source code for can't read your ssh and gpg keys and can only write
into its specific directory.

If you've got a computer that only does one thing, maybe a MAC isn't very
useful. But if your computer does two or more things, you can specify what
interactions are allowed, using which communication channels.

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

Re: [apparmor] apparmor is not getting started

[Seth Arnold]

On Fri, Jun 18, 2021 at 12:56:10PM +0530, Ratan Gupta wrote:
> root@abc:~# systemctl status apparmor
> * apparmor.service - AppArmor initialization
>  Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor
> preset: enabled)
>  Active: inactive (dead)
> 
> *Condition: start condition failed at Thu 1970-01-01 00:00:14 UTC; 51 years
> 5 months ago `- ConditionSecurity=apparmor was not met*

Hello Ratan, I'm not entirely certain about this condition, I get
lost in the systemd sources trying to find where these conditions
are populated. Part of the equation is the value of the file
/sys/module/apparmor/parameters/enabled -- try:

namei -l /sys/module/apparmor/parameters/enabled
cat /sys/module/apparmor/parameters/enabled

and see what the results are, it should look something like:

f: /sys/module/apparmor/parameters/enabled
drwxr-xr-x root root /
dr-xr-xr-x root root sys
drwxr-xr-x root root module
drwxr-xr-x root root apparmor
drwxr-xr-x root root parameters
-r--r--r-- root root enabled

Y

cat /proc/cmdline  may also be useful

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

Re: [apparmor] [Bug 1928360] Re: Switch to Fcitx 5 for Chinese

[Seth Arnold]

On Sat, Jun 05, 2021 at 01:27:19AM -, Gunnar Hjalmarsson wrote:
> It means that it explicitly looks for the fcitx 5 gtk im module, while
> Chromium only has access to the fcitx 4 one.

Oh! Excellent debugging to find the root cause.

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

[apparmor] [Bug 1928360] Re: Switch to Fcitx 5 for Chinese

[Seth Arnold]

Gunnar, indeed, it had much less in it than I expected; I don't know
much about the snap packaging for Chromium, but it looked to me like it
was trying to do bluetooth things and that's all that was denied.

I'm no fcitx expert but I didn't think it looked related.

Thanks

-- 
You received this bug notification because you are a member of AppArmor
Developers, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1928360

Title:
  Switch to Fcitx 5 for Chinese

Status in Lubuntu default settings:
  New
Status in Ubuntu Kylin:
  In Progress
Status in apparmor package in Ubuntu:
  New
Status in language-selector package in Ubuntu:
  Fix Released

Bug description:
  In Debian 11 Fcitx 5 will be the default IM framework for Chinese on
  non-GNOME desktops. I can think it's time to make the equivalent
  changes in Ubuntu 21.10 as well.

  I'd appreciate input on the topic from the Ubuntu Kylin team as well
  as other Chinese speaking users.

To manage notifications about this bug go to:
https://bugs.launchpad.net/lubuntu-default-settings/+bug/1928360/+subscriptions

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

Re: [apparmor] [Bug 1928360] Re: Switch to Fcitx 5 for Chinese

[Seth Arnold]

On Tue, May 18, 2021 at 07:39:48PM -, Gunnar Hjalmarsson wrote:
> On 2021-05-16 22:23, Gunnar Hjalmarsson wrote:
> > As regards apparmor it's possible that no change is needed.
> 
> Well, I simply tested with the Chromium snap. fcitx5 does not work in
> Chromium, while fcitx4 does. So something needs to be done.

Excellent, can you paste the DENIED lines from your test into the bug
report?

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

Re: [apparmor] Apparmor: Profile optimization

[Seth Arnold]

On Mon, Apr 26, 2021 at 08:58:54PM +0530, Murali Selvaraj wrote:
> Hi John/Seth,
> 
> Please clarify the below queries which we are looking for to define
> the profiles for embedded devices.
> Kindly do the needful.

In what way was my response here not clear enough?

https://lists.ubuntu.com/archives/apparmor/2021-April/012261.html

When you don't understand something in one of our responses, *please*
address whatever it is that you didn't understand rather than just
re-asking the same question over and over again.

It's not worth our time to just keep guessing about what you didn't
understand, or why you didnt understand it. You've got to help us out
here, you can't just demand over and over again.

I'm happy to help people who are trying to learn but you've got to at
least *try* what we suggest and respond in kind.

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

Re: [apparmor] Apparmor: Query on adding many capabilities in the custom header file

[Seth Arnold]

On Thu, Apr 22, 2021 at 09:15:27PM +0530, Murali Selvaraj wrote:
> @{default_caps}=chown,dac_override,dac_read_search,fowner,fsetid,kill,ipc_lock,sys_nice,setpcap,pc_owner,sys_ptrace,sys_chroot

Variables don't work for the capabilities. They aren't like files.

Make a new abstraction file with:

capability chown dac_override dac_read_search fowner fsetid kill ipc_lock 
sys_nice setpcap pc_owner sys_ptrace sys_chroot,


as the only contents, and use that. instead.

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

Re: [apparmor] Regarding header file for default capabilities

[Seth Arnold]

On Wed, Apr 21, 2021 at 09:41:23AM -0400, swarna latha wrote:
> Can someone throw lights on how to implement  a set of default
> capabilities to be added in all profiles (preferably in header file)

Hello Swarna, I gave advice to someone else recently that's probably
applicable to your case, too:

https://lists.ubuntu.com/archives/apparmor/2021-April/012264.html

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

Re: [apparmor] Apparmor profile: custom header file query

[Seth Arnold]

On Mon, Apr 19, 2021 at 11:16:11PM +0530, Murali Selvaraj wrote:
> As per our design , we are applying certain capabilities to all my profiles.
> 
> -> created custom include files as follow #include "relative_path"
>
> @{default_caps}=chown,dac_override,dac_read_search,fowner,fsetid,kill,ipc_lock,sys_nice,setpcap,ipc_owner,sys_ptrace,sys_chroot
> 
> -> Adding this header file in the required apparmor profiles.
>#include "relative_path"
>capabilty @{default_caps},
> 
> -> While parsing the apparmor profiles into Kernel, observing below errors.
>syntax error, unexpected TOK_EQUALS, expecting TOK_MODE

The set variables in AppArmor aren't a generic text replacement tool,
they're specialized for managing the combinatorial explosion of different
distributions putting 'the same' files in different locations, managing
typical unix usernames in directory structures, etc.

You could get something very similar by making a new abstraction file just
for your capabilities:

path/to/whatever/abstractions/default_service_capabilities:
capability chown dac_override dac_read_search fowner fsetid kill ipc_lock 
sys_nice setpcap ipc_owner sys_ptrace sys_chroot,

And then in your profiles:

#include "path/to/whatever/abstractions/default_service_capabilities"


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

Re: [apparmor] Apparmor: Queries

[Seth Arnold]

On Tue, Apr 13, 2021 at 11:18:12PM +0530, Murali Selvaraj wrote:
> We have observed few configuration files are present in /tmp which are
> needed for certain processes.
> For example, few of the files are hidden files located in /tmp/.
> 
> In that case, shall we add below entry
> 
> /tmp/** rw,
> 
> or Do we need to add entries for file specific as below
> 
> /tmp/file.txt r,
> /tmp/.init_complete rw,
> 
> Which would be the best way for security concern as well as embedded devices ?
> Please advise.

I'm worried that applications that are writing to /tmp/ using fixed
filenames like this are likely to be susceptible to file /tmp/ races. You
can enable the kernel's mitigations (see sysctl -a | grep fs.protected)
for this but that's only a partial mitigation for the problem.

Better is for the applications to write their temporary files into
per-application directories as appropriate.

Certainly I'd want to give tighter rules than /tmp/** rw, wherever
possible.

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

Re: [apparmor] Apparmor: Queries

[Seth Arnold]

On Mon, Apr 05, 2021 at 01:09:02AM +0530, Murali Selvaraj wrote:
> -> From the aa-log-prof, we are able to generate an apparmor profile
> for the required process. In order to confirm the profile(by
> theoretically)
>if we compare cat /proc//maps | grep -i lib this output will
> it be sufficient or any possibility of the libraries may
>not be in this entry cat /proc//maps?

Hello Murali,

/proc/pid/maps only reflects libraries that are currently in use. It's
possible for applications to use dlopen(3) to dynamically load libraries
at runtime (think "plugins") -- and probably some applications do
something very similar for dynamically loaded libraries but do it
themselves rather than using dlopen(3).

So /proc/pid/maps is good enough for most applications but it is not
comprehensive in the general case.

> -> Like a library, do we have any other way to find the list of
> configuration, temporary files using by process can be identified
>by simple tools or from any /proc entries like above? This is just
> to confirm about our profile.

You could use filesystem auditing rules or syscall auditing rules with
auditd, or you could use ebpf tools like opensnoop from the iovisor
project to catch file and directory opens, reads, writes. There's a lot of
systemcalls that do file IO, though, and it'd be easy to overlook one that
your application uses.

You could use perf to enumerate all the syscalls that your application
uses in its test suite, and then audit all the file-related syscalls.

> -> For example, one of my process is running in "non-root" owner which
> has read/write access to /proc///
>While generate profile for this process, Do I need to add this
> entry /proc///* rw, Or without adding this entry
>will it able to do read/write operation /proc///?

I'm sorry, I don't understand this question.

A confined process needs to have AppArmor rules to allow whatever it is
that you actually want to allow.

> Can you please explain the difference for the below entries in the
> apparmor profile?
> 
> /tmp/lock_file rw,
> /tmp/lock_file rwc,

'c' is how the kernel portion of AppArmor reports a file creation attempt.
'c' is not accepted in the userspace portion of AppArmor policies, so your
second rule will fail to compile:

$ echo "profile p { /a c, }" | apparmor_parser -Qd
AppArmor parser error, in stdin line 1: syntax error, unexpected TOK_ID, 
expecting TOK_MODE


> /tmp/test.css ww,
> /tmp/test.css w
> /tmp/initialized rww,
> /tmp/initialized rw,

The second 'w' is redundant and doesn't do anything. The parser accepts
this without error, though:

$ echo "profile p { /a ww, }" | apparmor_parser -Qd
- Debugging built structures -
Name:   p
Profile Mode:   Enforce
--- Entries ---
Mode:   wa:wa   Name:   (/a)


> /tmp/driver krw,
> /tmp/driver rw,

The version with 'k' lets your application call flock(2) on the file
/tmp/driver.

> By default, while device boots apparmor profiles are loaded to Kernel
> and the corresponding process read from the profile during the process
> execution,
> -> As per our code, the process kills/crashes by unknown reason; we
> have a mechanism to restart by itself.
>  In that case, during the process restart, will it start as per
> profile or without profile?

This depends on how the application was originally started and how you'll
restart it, as well as the application policy that you've written. If the
supervisor that you're using to start the application is responsible for
restarting the application, it'll probably go fine. If a different
mechanism is being used to restart the application, it might not.

> I would like to understand the reason for below DENIED logs, what does
> it really expect?
> Do I need to add the entry like /tmp/test c or /tmp/test rw or
> /tmp/test rwk? Pls share the difference for each mentioned
> possibility?
> 
> 2021 Apr 04 17:35:05 admin kernel: audit: type=1400
> audit(1617557705.711:207): apparmor="DENIED" operation="mknod"
> profile="example" name="/tmp/test" pid=11410 comm="application"
> requested_mask="c" denied_mask="c" fsuid=0 ouid=0
> 
> What is really this log expecting?

For this specific entry two possibilities make sense:

/tmp/test w,
owner /tmp/test w,

The application may need other permissions later; AppArmor can't know when
the file is created if the application will read from it, lock it, execute
it, etc. It won't know those things until the application actually issues
syscalls for that.

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

Re: [apparmor] Apparmor on Embedded devies.

[Seth Arnold]

On Tue, Mar 30, 2021 at 11:41:25PM +0530, Murali Selvaraj wrote:
> -> As we know that code has been merged/updated continuously (day to
> day) on the particular process, Do we have any mechanism to ensure how
> the Apparmor profile  aligns with the latest process/image?

Be sure your continuous integration tests cover everything the product
does, and make adding tests a condition of merging new code into the
tree. Look for DENIED entries in the logs, and fail the tests if there are
new denials.

Also, make it very easy for developers to run the full test suite
themselves on realistic deployment systems -- so they'll be in a position
to spot these problems before they even prepare merge requests.

> -> What is your thought on using embedded device head-set?

Depending upon what you're offering, it might make sense to investigate
compiling the profiles before deploying them to the devices.
(--features-file from the apparmor_parser(8) manpage may be helpful.)

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

Re: [apparmor] Regarding using apparmor to harden container configuration

[Seth Arnold]

On Wed, Nov 04, 2020 at 11:31:54AM -0500, swarna latha wrote:
> 1. My process will be using a set of libraries and these libraries might be
> writing to some files in the rootfs or need some capabs. I dont see this
> files/capabs in my apparmor logs. Is this expected behaviour ?

Hello Swarna, you'll need to give a lot more information for useful
feedback. What kernel are you using? What container system are you using?
How are you loading the profiles? What profiles are you loading? Can you
see the loading messages in the logs? Have you confirmed with simple test
programs that AppArmor is working at all in your environment?

> 2. Is there any limitation for apparmor to monitor applications running in
> container or is it the same as an application running in the host ?

There's some subtlety to working with AppArmor in containers, yes; for
example, the chromium sandbox uses unprivileged user namespaces and then
proceeds to use capabilities 'within' that new user namespace. These
aren't "real" capabilities from the perspective of the outside world, they
shouldn't grant undue privileges to do things outside the container,
but within the container they should kind of work.

Here's some examples:

root@u20:/# mkdir /tmp/foo ; chmod 000 /tmp/foo
root@u20:/# echo "include  profile test { include 
 /usr/bin/* rmix, /etc/** r, }" | apparmor_parser --replace
root@u20:/# aa-exec -p test cat /etc/shadow
root:*:18478:0:9:7:::
[...]
root@u20:/# aa-exec -p test cat /root/.bashrc
cat: /root/.bashrc: Permission denied
root@u20:/# aa-exec -p test ls -l /tmp/foo
ls: cannot open directory '/tmp/foo': Permission denied

Within the container:
root@u20:/# ps auxwZ | grep sleep
test (enforce)  root1348  0.0  0.0   7228   460 pts/0   
 S20:39   0:00 sleep 100
unconfined  root1353  0.0  0.0   8160   576 pts/0   
 S+   20:41   0:00 grep --color=auto sleep

Outside the container:
sarnold@millbarge:~$ ps auxwZ | grep sleep
lxd-u20_//&:lxd-u20_:test 
(enforce) 100 410011 0.0  0.0 7228 460 pts/0 S 20:39   0:00 sleep 100
unconfined  sarnold   410547  0.0  0.0   6772   568 pts/2   
 S+   20:40   0:00 grep --color=auto sleep


And AppArmor has logged these events:

sarnold@millbarge:~$ grep -e 'DENIED.*u20' -e 'operation="profile_load"' 
/var/log/audit/audit.log | tail -4
type=AVC msg=audit(1604521212.527:644468): apparmor="STATUS" 
operation="profile_load" 
label="lxd-u20_//&:lxd-u20_:unconfined"
 name="test" pid=398872 comm="apparmor_parser"
type=AVC msg=audit(1604521274.330:644469): apparmor="DENIED" operation="open" 
namespace="root//lxd-u20_" profile="test" 
name="/root/.bashrc" pid=399475 comm="cat" requested_mask="r" denied_mask="r" 
fsuid=100 ouid=100
type=AVC msg=audit(1604521708.134:644474): apparmor="DENIED" 
operation="capable" namespace="root//lxd-u20_" 
profile="test" pid=403302 comm="ls" capability=2  capname="dac_read_search"
type=AVC msg=audit(1604521708.134:644474): apparmor="DENIED" 
operation="capable" namespace="root//lxd-u20_" 
profile="test" pid=403302 comm="ls" capability=1  capname="dac_override"

sarnold@millbarge:~$ uname -a
Linux millbarge 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux

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

Re: [apparmor] Apparmor profile enforce issue, when changing from root to non-root

[Seth Arnold]

On Mon, Aug 31, 2020 at 10:34:46PM -0400, swarna latha wrote:
> I am getting the complete set of libraries used by my process with status=
> AUDIT, right from /etc/ld.so.cache. It looks to me as though the profile is
> not applied, though i have rules allowing the /etc/ld.so cache access.
> 
> As i have these file entries in my profile, i am not getting
> ALLOWED/DENIED, hence not able to regenerate the profile with these events.

Hello Swarna, so, is it the case that your system works fine when the
'capability,' line is in the profile, but when you remove it and reload
the profile, the application doesn't start *and* doesn't log anything
different?

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

Re: [apparmor] Apparmor profile enforce issue, when changing from root to non-root

[Seth Arnold]

On Mon, Aug 31, 2020 at 08:25:26PM -0400, swarna latha wrote:
> For non-root mode, tried to add the capabilities manually, all the 36
> capabilities it did not work. But if i add the capability, (which is to
> grant all capabilities, the last one highlighted below) the process starts.

What messages do you get in dmesg or audit logs when you run your service
without the 'capability,' line?

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

Re: [apparmor] Confinement inheritance with ix

[Seth Arnold]

On Sat, Aug 15, 2020 at 12:09:55AM +0200, Jonas Große Sundrup wrote:
> The executable in question, in whose profile the ix-confinement did not
> work, was in fact not the executable, but a symlink to it, which I
> didn't directly notice. While htop will then note the process via its
> *executed* name, aka the name of the symlink, AppArmor triggers only
> for the *actual* executable. After realizing this and adapting the
> profiles accordingly, everything now works smoothly according to the
> documentation. :)

Oh, excellent, thanks for reporting back.

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

Re: [apparmor] Apparmor: Query

[Seth Arnold]

On Tue, Aug 04, 2020 at 10:46:46PM -0400, Murali Selvaraj wrote:
> Goal: Converting root process to non-root process by enabling required
> capabilities for the process.
> [...]
> Process (A) will be running in "non-root" but with all enabled capabilities
> and check the apparmor logs.
> Apparmor logs will show the required capabilities.

Yes, this should work fine. There's several ways I can think of to do
this:

- Run the program as root (it sounds like it already runs as root and
  you're converting it) and keep track of AppArmor DENIED or ALLOWED
  entries.

- Run the program via a systemd unit file and add capabilities to the
  program via the AmbientCapabilities= directive. If you know nothing
  about your application or how it works, you could add them all, and
  once you've learned what it requires, trim the list appropriately.

- Run the program via an executable with fscaps and set all the
  capabilities on the file.

If you already know something about the program, you could skip the
capabilities that it will obviously never use.

> In any event, AppArmor will usually see capability requests after the usual
> DAC permissions are handled.
> 
> Can you please explain this above statement with simple example?
> 
> For example, Process (x) tries to open a file (/etc/security) which is root
> permission but the process (x) runs in "non-root mode.
> Pls note, process (x) does not have permission to open this file
> ((/etc/security) )
> 
> open => sys_open() => kernel further code for handing the code.
> 
> sys_open() => will return permission denied error due to permission issue.
> 
> Here, capable() check won't happen. Does DAC take care of this check
> without using capability (CAP_DAC_READ_SEARCH)?
> 
> In such a case, trying to understand when Kernel uses capable() to check
> CAP_DAC_READ_SEARCH/CAP_DAC_OVERRIDE before/after DAC.
> Can you please explain the relation between DAC, apparmor and linux
> capability with this context?

CAP_DAC_READ_SEARCH will only be used if you've changed the permissions on
/etc to forbid owner, group, or world read or execute permissions,
depending upon the owner and group of the file, and fsuid and groups of
the process.

CAP_DAC_OVERRIDE will only be used if /etc/security owner, group, or
world, permissions don't allow the operation to the process's fsuid and
groups.

Unix permissions are flexible -- and indeed, it is their flexiblity that
provides motivation for mandatory access control systems like AppArmor.
Your program may or may not need either of these capabilities, even if it
works with files owned by other users, because the permissions on those
files may also be set to allow your program to use them.

If you're writing an application from scratch it is probably worth taking
some time to decompose your application into smaller pieces determining
the flow of data through your application, and trying to use Unix users
and groups to do what you can to use the Unix permissions model to
enforce the right flow of data.

For example, the qmail suite of programs run with several users and a
strict dataflow through the program. The author, djb, said a dozen years
after writing qmail that he thinks this did not actually contribute to
qmail's better-than-average security record, but I disagree: This approach
also forced a clear understanding of responsibilities, data flows, etc.
(To be clear, I think djb could just as well write a secure qmail without
this restriction, but djb's skills are unique.)

Of course not all applications lend themselves to this kind of
decomposition.

If you are developing an application from scratch rather than porting
an existing application, aim for *no* capabilities. Try to replace every
capability with something else. If you need CAP_NET_BIND_SERVICE to bind
to a low TCP or UDP port, you could use systemd's socket activation
instead. That's two or three extra lines in systemd configuration and
no chance for introducing privilege dropping bugs.

The usual "classic Unix daemon" quite often just needs CAP_NET_BIND_SERVICE,
CAP_SETGID, and CAP_SETUID -- and the latter two, only to drop the
privileges that were required for the initial bind(2) call. systemd socket
activation and User=, Group=, etc directives means this can be done
completely outside of your own application and your application can run
without privileges at all.

AppArmor is a useful tool but standard tools and careful design work may
be able to reduce the amount of privileges an application needs in the
first place.

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

Re: [apparmor] [PATCH] security: apparmor: delete repeated words in comments

[Seth Arnold]

On Fri, Aug 07, 2020 at 09:50:55AM -0700, Randy Dunlap wrote:
> Drop repeated words in comments.
> {a, then, to}
> 
> Signed-off-by: Randy Dunlap 
> Cc: John Johansen 
> Cc: apparmor@lists.ubuntu.com
> Cc: James Morris 
> Cc: "Serge E. Hallyn" 
> Cc: linux-security-mod...@vger.kernel.org

Reviewed-By: Seth Arnold 

Thanks

> ---
>  security/apparmor/include/file.h  |2 +-
>  security/apparmor/path.c  |2 +-
>  security/apparmor/policy_unpack.c |2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> --- linux-next-20200731.orig/security/apparmor/include/file.h
> +++ linux-next-20200731/security/apparmor/include/file.h
> @@ -167,7 +167,7 @@ int aa_audit_file(struct aa_profile *pro
>   * @perms: permission table indexed by the matched state accept entry of @dfa
>   * @trans: transition table for indexed by named x transitions
>   *
> - * File permission are determined by matching a path against @dfa and then
> + * File permission are determined by matching a path against @dfa and
>   * then using the value of the accept entry for the matching state as
>   * an index into @perms.  If a named exec transition is required it is
>   * looked up in the transition table.
> --- linux-next-20200731.orig/security/apparmor/path.c
> +++ linux-next-20200731/security/apparmor/path.c
> @@ -83,7 +83,7 @@ static int disconnect(const struct path
>   *
>   * Returns: %0 else error code if path lookup fails
>   *  When no error the path name is returned in @name which points to
> - *  to a position in @buf
> + *  a position in @buf
>   */
>  static int d_namespace_path(const struct path *path, char *buf, char **name,
>   int flags, const char *disconnected)
> --- linux-next-20200731.orig/security/apparmor/policy_unpack.c
> +++ linux-next-20200731/security/apparmor/policy_unpack.c
> @@ -39,7 +39,7 @@
>  
>  /*
>   * The AppArmor interface treats data as a type byte followed by the
> - * actual data.  The interface has the notion of a a named entry
> + * actual data.  The interface has the notion of a named entry
>   * which has a name (AA_NAME typecode followed by name string) followed by
>   * the entries typecode and data.  Named types allow for optional
>   * elements and extensions to be added and tested for without breaking
> 
> -- 
> AppArmor mailing list
> AppArmor@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/apparmor


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] Apparmor: Query

[Seth Arnold]

Hello Murali,

On Mon, Aug 03, 2020 at 02:03:38PM -0400, Murali Selvaraj wrote:
> Query 1:
> 
> - But I do not see CAP_DAC_OVERRIDE and CAP_KILL in apparmor event logs.

AppArmor does not have a mechanism to grant capabilities that a process
does not already have. The kernel will query LSMs to see if a capability
is allowed to be used if the process already has the capability in
question. (There may be exceptions to this, there's hundreds of these
checks scattered throughout the kernel.)

You'll only see these requests in AppArmor logs if the process had these
capabilities. By using su to switch to the 'nobody' account, you only have
access to whatever privileges the nobody account already has: additional
access to root_squashed files on NFS, any other processes mistakenly
running as user nobody, etc.

Because this doesn't include any capabilities in the process's
capabilities sets, AppArmor won't even see the requests.

> Query 2:
> 
> - How apparmor identities how many capabilities are needed for the process?

The kernel will call capable() in the codepaths as necessary; the security
module interface will get the calls, without context, after the rest of
the kernel's capabilities handling. It's difficult to follow because it's
been heavily optimized for performance.

In any event, AppArmor will usually see capability requests after the
usual DAC permissions are handled.


> Query 3:
> 
> - Does all system calls need capability when it runs in a non-root process,
> how does apparmor mapping the linux capabilities?

"root processes" means both uid 0 as well as having capabilities in the
effective capability set. (Perhaps it'd also make sense to consider the
other capability sets in the process?) A uid 0 process with no
capabilities still has considerable power, since many important files like
/etc/sudoers are owned by uid 0, and modifying these files through DAC
permissions alone could be used to then gain capabilities. However, a uid
0 process with no capabilities couldn't itself initiate a reboot in the
kernel, or override DAC restrictions on files, etc.

A process with capabilities need not be uid 0 though I can't immediately
point any common examples.

Linux's uid namespaces makes things a bit more complicated: a process can
have namespace-level capabilities that do not extend to capabilities in
the init namespace. (Consider something like an LXD guest: there may be
different users within the guest, and the 'root' user with the LXD guest
can do privileged operations over the namespace, eg manage the routing
table used for that network namespace, but not be able to manage the
routing table used by the network namespace for the init process.)

See the user_namespaces(7) and unshare(2) manpages for some more information.

> Can someone please clarify these queries?

I'm afraid my description probably made things worse.

Let me try one quick simple thing:

Run your example with and without root privileges. You'll see the
difference in AppArmor log output. Hopefully that 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

Re: [apparmor] rkhunter profile oddities

[Seth Arnold]

On Thu, Jul 16, 2020 at 09:36:11PM +0200, mailinglis...@posteo.de wrote:
> Instead, as you can see, apparmor reports:
>$
> Name: usr/sbin/ModemManager
> Name: usr/sbin/NetworkManager
>$
>$
> Is this probably an error in rkhunter and not in apparmor?

This is because rkhunter is executing in its own filesystem namespace for
whatever reason, and the LSM interface isn't passing to AppArmor
sufficient information for AppArmor to know the mountpoint that was used
to access those files.

You can add flags=(attach_disconnected) near the start of the profile to
cause these accesses to be treated as if they were mounted at /.

eg

profile rkhunter /usr/bin/rkhunter flags=(attach_disconnected) {
  /** r,
  ...
}

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

Re: [apparmor] Query about AppArmor's Profile Transitions

[Seth Arnold]

On Tue, Oct 01, 2019 at 05:25:21PM +, Abhishek Vijeev wrote:
> Currently, AppArmor allows 'pix' and 'cix' transitions. However, we would 
> like to extend AppArmor to
> allow a 'pcix' transition. To clarify what we mean by 'pcix', we're looking 
> for a way by which we
> can specify the following policy: 'look for a specific profile, but if one 
> doesn't exist, look for a
> child profile, otherwise inherit the current profile'. Are there any 
> challenges to implementing
> this? Also, is this a feature that is planned for release in future versions 
> of AppArmor?

I do have to wonder if whatever you're trying to solve would be better
handled via stacking profiles instead.

What are you trying to achieve?

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

Re: [apparmor] Question about file_mmap/exec in the case of perl/shell scripts

[Seth Arnold]

On Thu, Sep 12, 2019 at 04:20:22PM +0200, Mikhail Morfikov wrote:
> Shouldn't be here some "x" or "m" permissions, or maybe AppArmor assumes 
> this automatically for the confined path, so it's redundant to specify it 
> manually?

Interpreters are handled differently:

https://bugs.launchpad.net/apparmor/+bug/1346553

I'm not sure if we'll be able to change this behaviour in the future or
not.

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

Re: [apparmor] [Merge] ~sdeziel/apparmor-profiles/+git/apparmor-profiles:apt-cacher-ng into apparmor-profiles:master

[Seth Arnold]

The change makes sense to me but I'm not sure if this or 
https://gitlab.com/apparmor/apparmor-profiles is the better place to make the 
change.

Thanks
-- 
https://code.launchpad.net/~sdeziel/apparmor-profiles/+git/apparmor-profiles/+merge/372819
Your team AppArmor Developers is requested to review the proposed merge of 
~sdeziel/apparmor-profiles/+git/apparmor-profiles:apt-cacher-ng into 
apparmor-profiles:master.

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

Re: [apparmor] apparmor & clamav

[Seth Arnold]

On Wed, Sep 04, 2019 at 08:02:56PM +0200, Birger Birger wrote:
> This looks promising to troubleshoot. Any ideas?

Do you know what winbindd does with this pipe? Are there any local
configuration changes that would have put this pipe in this directory?

It feels a lot like a new name for the pipes listed in
:

  /tmp/.winbindd/pipe  rw,
  /var/{lib,run}/samba/winbindd_privileged/pipe rw,

Does this sound right? Or is this pipe something different from these?

Thanks

> > On Sep 4, 2019, at 03:01, Birger Birger via clamav-users <
> clamav-us...@lists.clamav.net> wrote:
> >
> 
> From Ubuntu syslog:
> > Sep 4 08:40:01 zentyal kernel: [345190.998397] audit: type=1400
> audit(1567579201.044:83): apparmor="DENIED" operation="connect"
> profile="/usr/bin/freshclam" name="/run/samba/winbindd/pipe" pid=1269
> comm="freshclam" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0



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] Apparmor

[Seth Arnold]

On Thu, Aug 29, 2019 at 04:02:52PM +0300, Олександр Нещадим wrote:
> I want to limit the users of my computer so that they cannot transfer their
> files to other users. I limited the chmod command.
> But through the Nautilus program, users can change the properties of files.
> 
> Tell me how to limit users who own files.
> 
> I wanted to do this through the Apparmore profile for Nautilus, but I don’t
> know how.

Hello Олександр,

I'm not sure what your security goals are but it's quite possible that
what you want to do isn't possible with AppArmor today.

> I read that there is a chmod rule in Apparmore syntax (
> https://web.archive.org/web/20171230174731/http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference#Chmod_rules
> )
> But for some reason it does not work. Help me please.

I'm sorry, this wiki page isn't documentation -- it was used to sketch out
what new features may look like, how those features could interact, etc.

It was a mistake to put these notes on the public internet.

The apparmor.d(5) manpage is better at documenting what exists;
not all features are available everywhere. On Ubuntu it should be
comprehensive, on other distributions less good. We're working on
upstreaming features so it should improve over time. For today, you can
use this table to help determine what features may exist on your system:
https://gitlab.com/apparmor/apparmor/wikis/Kernel_Feature_Matrix

Alright, back to your problem.

Two users can communicate via files, sockets, shared memory segments,
semaphores, process titles, etc.

AppArmor can help you block sockets, but if you let your users get to the
internet or off the computer at all, they can communicate that way. If
a user can bind a socket and another connect, they can communicate
without getting to the internet.

We currently don't mediate shared memory segments or semaphores.

Process titles can be blocked via procfs(5) mount flag hidepid.

AppArmor can help with files but in a different fashion than mediating
chmod: the 'owner' flag on files. It applies on path. However, rather
than preventing a user from making their files too visible, the 'owner'
flag is a restriction on a potential reading (or writing) process. Here's
a rough, untested, example:

#include 
profile users {
  #include 

  /bin/** rmix,
  /usr/bin/** rmix,

  owner @{HOME}/** rwlk,
  owner /tmp/** rwlk,
}

It would take some effort to ensure all your user processes are confined
with this profile. (This is also something we intend to make easier in
the future.)

Processes confined with this profile would not be able to read files
owned by other users within their home directories. Executables (and
libraries, other files via abstractions/base) can by owned by anyone
and still be read.

There's no sockets in this, so that route is out. Shared memory segments,
semaphores, and process titles would still work for inter-process
communication.

If this is applied to all user processes, then no user would be able to
change their passwords. They couldn't use any setuid executables owned by
other users. It wouldn't be a standard Unix-like system by a long shot.
But it might be good enough for your use.

I hope this helps.

Дякую


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] Help with AppArmor Full System Policy

[Seth Arnold]

On Wed, Aug 21, 2019 at 06:10:30AM +, Abhishek Vijeev wrote:
> profile init-systemd /lib/systemd/** flags=(complain) {
>   /usr/bin/colord/**  cx ->  colord_profile,
>   profile colord_profile flags=(complain) {
>   }
> }

> However the dmesg audit logs show the profile name for colord-sane as:
> 'init-systemd//colord_profile//null-/usr/lib/colord/colord-sane' (sample
> logs are attached for reference). We don't understand where the suffix
> 'null-/usr/lib/colord/colord-sane' originates from, since we have
> specified an explicit 'cx' transition for all files within
> /usr/bin/colord/. Due to this problem, we are unable to confine colord
> and a bunch of other processes.

Your logs start after the profile transitions involved; the profile name
here shows the chain of execs that were taken to reach this point:

init-systemd//colord_profile//null-/usr/lib/colord/colord-sane

your init-system profile executed something in /usr/bin/colord/** and then
transitioned into the colord_profile child profile

that process then executed /usr/lib/colord/colord-sane

Because the init-systemd//colord_profile profile is in complain mode,
AppArmor ALLOWED the execution and created a new //null- profile.

If you take the profile out of complain mode, you'll get a DENIED when
the process tries to execute a program that isn't in the profile. You
can decide what profile the process should use after the exec by adding
appropriate Px, Cx, ix, etc rules to the init-systemd//colord_profile
profile.

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

Re: [apparmor] Question about "Failed name lookup - disconnected path"

[Seth Arnold]

On Tue, Aug 06, 2019 at 01:36:23PM +0200, Mikhail Morfikov wrote:
> apparmor="DENIED" operation="getattr" info="Failed name lookup -
> disconnected path" error=-13 profile="app2" \ name="apparmor/.null"
> pid=55644 comm="app2" requested_mask="r" denied_mask="r" fsuid=1 ouid=0
> 
> So when the confined *app1* calls the confined *app2*, I get the "Failed 
> name lookup - disconnected path" error, but when the unconfined *app1* 
> calls the confined *app2*, I don't get this error. Also when I execute 
> the *app2* manually, I don't get the error.

I believe this case, app1 is opening a file descriptor and giving that
file descriptor to app2. There's some amount of filesystem namespace
operations in play -- app2's view of the filesystem doesn't include that
file.

This means that when a file with a name in the filesystem like etc/shadow
is resolved, apparmor can't tell you if it's from /var/chroot/ or from /.

You've got several approaches possible:

- run both processes in the same filesystem namespace, so files have names
  that are meaningful to both

- use the flags=(attach_disconnected) modifier to your second profile;
  this will cause apparmor to 're-root' files on / and give them a name.
  You might get a new DENIED message after this to report which file
  you'll need to add to your profile.

Hopefully we'll have something more pleasing in the future, but this is
where it's at today.

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

Re: [apparmor] Questions about AppArmor's Kernel Code

[Seth Arnold]

On Tue, Jul 30, 2019 at 12:42:48PM +, Abhishek Vijeev wrote:
> Thank you for the correction John.
> 
> Despite changing the code to use strdup( ), the kernel still crashes. I
> have attached the modified file for reference.
> 
> Is there anything else that might be causing the crash?

Hello Abhishek,

Please consider sharing your modification via diffs; passing along entire
files is pretty difficult to read and understand your changes.

Also be sure to include the full kernel messages when trying to debug
crashes. That's the best lever any has to prise apart the problem.

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

Re: [apparmor] Questions about AppArmor's Code

[Seth Arnold]

On Wed, Jun 12, 2019 at 12:32:53PM +, Abhishek Vijeev wrote:
> Hi,
> 
> I have a few questions about AppArmor's code and would be grateful if
> you could kindly answer them.

[I've stripped your urls of some get-mail-spring style links]

> 1) The documentation at this link
> https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#address-expr
> mentions the possibility of specifying a network rule as "network tcp
> src 192.168.1.1:80 dst 170.1.1.0:80". However this doesn't work, and
> after a little digging, I found out that the productions rules for this
> policy were available only in the grammar specification of AppArmor 2.1
> (line number 670 of
> https://gitlab.com/apparmor/apparmor/blob/apparmor-2.1/parser/parser_yacc.y
> ). I find this extremely useful, and am considering trying to add this
> to AppArmor as part of a larger project. Could you kindly clarify the
> reason for its removal? Were there any hurdles that made it difficult to
> accomplish this?

Fine-grained networking controls have been on the most often desired
features for perhaps fifteen years.

Some small portions of fine-grained networking may be simple enough to
implement as a project. Controlling bind, listen, and connect might be
straight forward enough. However, a more fully-featured implementation
that mediates sockets passed in, or sockets shared among multiple domains,
etc., would require significantly more work to implement.

Quite a lot of the mediation points available in the Linux kernel aren't
in process context. There's mechanisms available to cope with this, but
they're not nearly as easy to use as doing the mediation when running in
process context.

I'm rusty on this at this point, but if you search lwn for secmark, secid,
you'll probably find some useful articles. (Figuring out which ones are
useful is left as an exercise for the reader. :)

> 2) At what stage during the kernel boot process does AppArmor load the
> profiles? And from where does it obtain them? (am I correct in
> understanding that the profiles are stored in
> /sys/kernel/security/apparmor/policy ?)

The kernel boot process does not load any apparmor policy. Policy is
loaded by userspace.

If you want to have a confined init, you'll need to modify your initramfs
to load policy before switching to the system init.

Most distributions use the sysv-initscripts, or a fork from them from
years ago, and some systemd unit files to call the initscripts. These
usually load policy from /etc/apparmor.d/ but packaging systems like click
and snap loaded policy from elsewhere, and libvirt and snapd (among
others) will dynamically generate and load policy as needed.

> 3) Why does function 'aa_alloc_profile( )' allocate extra memory ? It
> seems to be allocating memory for 3 objects of type 'struct aa_profile'.
> (line number 262 of
> https://github.com/torvalds/linux/blob/master/security/apparmor/policy.c
> )

This is allocating space for a single struct aa_profile and two pointers:

https://github.com/torvalds/linux/blob/master/security/apparmor/include/policy.h#L162

struct aa_profile {
struct aa_policy base;
struct aa_profile __rcu *parent;
/* ... */
aa_label label;
};

https://github.com/torvalds/linux/blob/master/security/apparmor/include/label.h#L134

struct aa_label {
struct kref count;
struct rb_node node;
/* ... */
struct aa_profile *vec[];
};

The pointers are for the final vec: 
https://en.wikipedia.org/wiki/Flexible_array_member

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

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

[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

Re: [apparmor] [profile] logrotate: new rules needed.

[Seth Arnold]

On Wed, Apr 10, 2019 at 06:31:59PM +, daniel curtis wrote:
> Two years ago, Mr Seth Arnold, Mr Christian Boltz and I, started to work on
> Logrotate profile updates, because profile, which was then available did
> not have many necessary rules etc. However,  We managed to achieve a
> satisfactory result (see 1.)

Hello Daniel,

> # apparmor="DENIED" operation="open"
> # profile="/etc/cron.daily/logrotate"
> # name="/proc/sys/kernel/osrelease" comm="systemctl"
> # requested_mask="r" denied_mask="r" fsuid=0 ouid=0

I think a mistake was made here, and it influenced nearly everything
beyond this point. systemctl should not be an 'ix' rule. It requires way
more privileges for it to do its work than logrotate needs to do its work.

Cx, maybe. Ux, maybe. But ix is setting yourself up for adding so many
privileges to logrotate that the profile isn't actually confining
logrotate much. It's just a maintenance hassle.

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

Re: [apparmor] KUnit and experimental e2e tests

[Seth Arnold]

On Thu, Mar 28, 2019 at 01:13:54PM -0700, Eric Chiang wrote:
> Would anyone be opposed to setting up a gitlab.com/apparmor/linux
> mirror, creating a kunit branch and configuring GitLab CI? Short term,

I really like this idea.

> Separately, I've been working on an experimental tool for writing e2e
> tests for arbitrary apparmor_parser / kernel combinations leveraging
> QEMU. I'd like to start some discussion if it'd be a good addition to
> the existing tests/regression/apparmor suite. Would it be okay to open
> source that under gitlab.com/apparmor/apparmor_e2e?

I also really like this idea. (This is something I've wanted to do for
years but I'm too easily distracted by shiny things.)

I've thought that there's several axes that would be worthwhile testing:

Starting from a distro that has *no* apparmor:
- testing "arbitrary" apparmor versions (master, maybe tips of a few
  branches)
- testing "arbitrary" kernel versions (linux-next, linus, maybe a stable
  or two)

A full N*M layout would be awesome.

Starting from the distros that have strong apparmor support:
- testing their kernels with "arbitrary" apparmor versions
- testing their apparmor versions with "arbitrary" kernels

D*N*1 and D*1*M layouts ought to be good.

The arbitrary kernels version would address the most likely way for most
apparmor users to experience problems.

Maybe these don't all fit into the same tool, but I thought I'd mention it
just in case they do.

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

Re: [apparmor] Developing an Apparmor profile for PostgreSQL 10

[Seth Arnold]

On Fri, Mar 22, 2019 at 10:07:49AM -0400, Espresso Beanies wrote:
> I'm trying to develop an Apparmor profile for PostgreSQL 10 based on the
> existing profile here (
> https://gitlab.com/apparmor/apparmor-profiles/blob/master/ubuntu/18.04/usr.lib.postgresql.bin.postgres)
> however when I go to generate the profile based on the postgres executable
> location, I get the following results:
> >
> >
> > # Last Modified: Fri Mar 22 09:59:25 2019
> > #include 
> > /usr/lib/postgresql/10/bin/postgres {
> >   #include 
> >   /lib/x86_64-linux-gnu/ld-*.so mr,
> >   /usr/lib/postgresql/10/bin/postgres mr,
> >   owner /etc/postgresql/10/main/postgresql.conf r,
> > }
> 
> 
> There seems to be a number of things absent from the profile itself and
> since PostgreSQL 10, there also appear to be a number of new locations that
> contains resources that the program uses. I find these fun and I'd like to
> do more, but I want to make sure they're created properly.

Hello,

Yes, this new profile is missing quite a lot from the previous profile
that looks very important. However, I'm surprised it's even needed. The
version I retrieved from the URL you gave looks like it has an attachment
specification that should also match the filename you gave:


#include 

/usr/lib/postgresql/[0-9.]*/bin/postgres {
  #include 
  #include 
  #include 

  /etc/postgresql/** r,
  /usr/share/postgresql/** r,
  /var/lib/postgresql/** rwl,
  /{,var/}run/postgresql/** rw,
  owner @{PROC}/[0-9]*/oom_adj rw,
}

/usr/lib/postgresql/10/bin/postgres should match this, unless I'm missing
something too subtle for a Friday.

Did you have problems using the profile from the repository?

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

Re: [apparmor] AppArmor Digest, Vol 105, Issue 2

[Seth Arnold]

On Fri, Feb 15, 2019 at 03:11:08PM -0500, Espresso Beanies wrote:
> Thanks Seth. Well, I installed both the 'mysql-server' and mariadb-server'
> packages, but didn't see the usr.sbin.mysqld profile appear in Apparmor or
> anywhere on my system when I ran a 'locate' search.

Be very careful how you switch between mariadb and mysql. It's best to
*purge* the old packages when you want to try the other. Just "remove"ing
the packages will leave old config files around, and the mariadb packaging
throws away the apparmor profile entirely.

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

Re: [apparmor] Not seeing apparmor profile for SSHD service in Ubuntu 18.04

[Seth Arnold]

On Wed, Feb 13, 2019 at 10:48:23AM -0500, Espresso Beanies wrote:
> I'm not seeing the Apparmor profile for the SSHD service in Ubuntu 18.04
> when I go to install Apparmor and all the profiles. Was it taken out from
> this release? I saw MySQL was also cut out from the 18.04 release as well.

There hasn't been an opensshd profile for a long time: it would really
only make sense as a change_hat- or change_profile-aware variant,
since some sshd processes should have almost no privileges, and other
sshd processes need to be able to start root-owned shells to support
admin logins.

We had one, but it probably hasn't been built in a very long time.

mysql though is surprising. At least the mysql-5.7 package version
5.7.25-0ubuntu0.18.04.2 appears to have a profile. How did you install
your mysql?

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

Re: [apparmor] Interesting mmap denies for /tmp/# produces by libpcre2

[Seth Arnold]

On Tue, Jan 29, 2019 at 08:25:04PM +0200, Vincas Dargis wrote:
> While developing some profile, I've discovered spam of denies:

> type=AVC msg=audit(1548784267.275:2162): apparmor="DENIED"
> operation="file_mmap" profile="qtox" name="/tmp/#13288" pid=6316 comm="qtox"
> requested_mask="m" denied_mask="m" fsuid=1000 ouid=1000

> Interestingly, so far this reproduced only on openSUSE Tumbleweed (compared
> to Debian Sid, Ubuntu 18.04). Maybe only openSUSE libpcre is built with
> regex jitting or smth..?

I believe you're right; I reviewed this code just a few days ago:
https://sources.debian.org/src/pcre2/10.32-3/src/sljit/sljitProtExecAllocator.c/?hl=2#L143

> Anyway, these /some/path/#number denies are kind.. slowly growing here and
> there. It would be nice to have some way to tackle them explicitly in
> AppArmor policy files. For now, I would probably deny mmaping
> /tmp/#[0-9][0 as application seems to work fine so far.
> 
> Maybe library developers could implement these mmaps "differently" to
> avoid "problems" with MACs?
> 
> Or we "just" need some new rules to handle these cases that becomes more
> "popular" with time..?

Ideally, some future AppArmor work will allow us to keep these separate.
In the meantime we're probably better off allowing the accesses. Afterall,
denying them means you won't get the benefit of the JIT, and the
error-handling code in the processes in question may not be particularly
well tested. If it exists at all.

The code uses TMPDIR to discover where to put the files. This is both good
and bad. You can leverage it to put the files elsewhere if you want, but
users with unexpected settings could get failures that we don't see.

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

Re: [apparmor] Adding custom profiles to Apparmor

[Seth Arnold]

Hello,

On Fri, Jan 18, 2019 at 11:32:40AM -0500, Espresso Beanies wrote:
> I like to add my custom profiles to the Apparmor profiles package and I
> just wanted to ask how to go about submitting them to this mailing list. I
> saw some examples that had additions and subtractions, so I don't know if
> you're looking for the raw git output or a clean file with everything laid
> out.

If they are new additions, then you can do either pasting the files into
the list or a gitlib merge request or whatever you wish. It'll be easy
enough to work with many choices for new files.

> I also wanted to mention the wiki on GitLab doesn't appear to have been
> built out yet:
> https://gitlab.com/apparmor/apparmor/wikis/home/index.php/CommitPolicy
> 

The wiki issue is probably a busted URL forwarded from the old wiki
location, which was hosted elsewhere. We haven't had success getting
those old links correctly forwarded. The Commit Policy for example is on:

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

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

Re: [apparmor] Question about defining a profile name via @{exec_path} variable

[Seth Arnold]

On Wed, Jan 09, 2019 at 11:48:44PM +0100, Mikhail Morfikov wrote:
> @{exec_path} = /usr/bin/keepassxc
> profile keepassxc @{exec_path} {
> }

> # aa-complain usr.bin.keepassxc
> ERROR: Profile for @{exec_path} exists in /etc/apparmor.d/some-app and 
> /etc/apparmor.d/some-other-app

> Should this happen? Should I avoid using the code 
> snipped to make profiles and use regular paths instead?

I guess you'll have to decide if your abstraction to make it easy to
change the location of binaries saves you enough trouble that it's worth
no longer being able to use the python-based utilities. If you've built
enough infrastructure around your tooling it might be easy to extend it to
do whatever the python-based tooling does and you're missing. If you've
not yet built much infrastructure around your abstraction, this might not
be quite as compelling.

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

Re: [apparmor] Apache2 Profile Building Failure

[Seth Arnold]

On Sat, Dec 29, 2018 at 06:03:25PM +, Moody, David Alan (dam8u) wrote:
> 
> Dec 29 07:21:41 ip-172-31-9-2 kernel: [225623.487271] audit: type=1400
> audit(1546068101.318:6846): apparmor="ALLOWED" operation="connect"
> info="Failed name lookup - disconnected path" error=-13
> profile="/usr/sbin/apache2" name="run/mysqld/mysqld.sock" pid=30086
> comm="apache2" requested_mask="wr" denied_mask="wr" fsuid=33 ouid=106
> 
> Here is the user.sbin.apache2 AppArmor config that aa-genprof created
> 
> # Last Modified: Sat Dec 29 03:30:28 2018
> #include 
> 
> /usr/sbin/apache2 flags=(attach_disconnected,complain) {

Hello David, I'm surprised that you've hit this issue -- the "fix" is to
add the attach_disconnected flag to the profile.

Is it possible that the profile was modified after this specific log line?

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

Re: [apparmor] [PATCH V2] security/apparmor: fix matching on presence of extended attributes

[Seth Arnold]

On Thu, Dec 20, 2018 at 01:28:38PM -0800, Eric Chiang wrote:
> --- a/security/apparmor/policy_unpack.c
> +++ b/security/apparmor/policy_unpack.c
> @@ -535,6 +535,24 @@ static bool unpack_xattrs(struct aa_ext *e, struct 
> aa_profile *profile)
>   goto fail;
>   }
>  
> + if (unpack_nameX(e, AA_STRUCT, "xattr_keys")) {
> + int i, size;
> +
> + size = unpack_array(e, NULL);
> + profile->xattr_keys_count = size;
> + profile->xattr_keys = kcalloc(size, sizeof(char *), GFP_KERNEL);

Do we need to worry about a zero-size array here?

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

Re: [apparmor] [PATCH 1/2] dnsmasq: Update NetworkManager pid and configs paths

[Seth Arnold]

On Tue, Nov 20, 2018 at 09:11:55AM +0100, Petr Vorel wrote:
> Hi Seth,
> > +  /{,var/}run/NetworkManager/NetworkManager.pid w,
> I guess I should send v2, where I just add NetworkManager.pid (and keep
> nm-dns-dnsmasq.conf and nm-dnsmasq-*.pid).

Hello Petr,

Yes, please, that'd be the quickest way to make sure these aren't lost. :)

And the dnsmasq:
+  /var/log/dnsmasq*.log w,

change also.

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

Re: [apparmor] [PATCH 1/1] dnsmasq: Remove lxd-bridge

[Seth Arnold]

On Mon, Nov 19, 2018 at 06:17:23PM +0100, Petr Vorel wrote:
> lxd-bridge was removed in lxd 2.3
> -  /{,var/}run/lxd-bridge/dnsmasq.pid   rw,

On Mon, Nov 19, 2018 at 08:17:21PM +0100, Petr Vorel wrote:
> -  /{,var/}run/sendsigs.omit.d/*dnsmasq.pid w,

On Mon, Nov 19, 2018 at 08:17:20PM +0100, Petr Vorel wrote:
> NetworkManager moved dnsmasq config files from /var/run/ into
> /var/run/NetworkManager/ long time ago in 0.9.8 in commit d82669d3f

> -  /{,var/}run/nm-dns-dnsmasq.conf r,
> -  /{,var/}run/nm-dnsmasq-*.pid rw,

Hello Petr,

Thanks for the profile patches; however, I don't think we want to apply
these changes just yet. We rarely *remove* rules from AppArmor profiles
because we do not want to break deployed users. (The python 2 -> python 3
transition pain is still very fresh in our minds.)

I'd only be comfortable removing these perhaps a decade after their
upstreams stopped using them.

Sure it's unlikely for someone to take a newish AppArmor and deploy it on
an Ubuntu 12.04 LTS-era host, but I don't want AppArmor to be known as a
project where you *can't* do that.

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

[apparmor] [Bug 1800789] Re: Syntax Error in Firefox Profile Generation makes Firefox-ESR run unconfined although Profile is enforced

[Seth Arnold]

** Information type changed from Private Security to Public

-- 
You received this bug notification because you are a member of AppArmor
Developers, which is subscribed to AppArmor Profiles.
https://bugs.launchpad.net/bugs/1800789

Title:
  Syntax Error in Firefox Profile Generation makes Firefox-ESR run
  unconfined although Profile is enforced

Status in AppArmor Profiles:
  New

Bug description:
  First of all I'd like to apologize in advance if this is the wrong
  place to report this, since I don't know where the "usr.bin.firefox-
  esr" apparmor-profile stems from and if I should report this to the
  apparmor-profiles Launchpad or Gitlab repository or the official
  Mozilla Firefox-ESR PPA. If this is the wrong place, feel free to
  close this issue. I also posted this bug on the Gitlab repository:
  (https://gitlab.com/apparmor/apparmor-profiles/issues/3).

  System Information:

  - Up-to-date stable release of Ubuntu 18.10 (Problem also persisted in 
18.04 LTS)
  - Newest stable release of Firefox-ESR from the official Mozilla PPA 
(https://launchpad.net/~mozillateam/+archive/ubuntu/ppa)
      - apparmor, apparmor-utils and apparmor-profiles installed

  Description of Problem:

  Firefox-ESR is succesfully set to enforce mode with "$ sudo aa-enforce
  usr.bin.firefox-esr". By checking "$ sudo aa-status" and looking under
  "X profiles are in enforce mode" you see the enforced profiles for
  Firefox and Firefox-ESR (Firefox was also set to enforce-mode):

     /usr/lib/firefox-esr/firefox{,*[^s][^h]}
     /usr/lib/firefox-esr/firefox{,*[^s][^h]}//browser_java
     /usr/lib/firefox-esr/firefox{,*[^s][^h]}//browser_openjdk
     /usr/lib/firefox-esr/firefox{,*[^s][^h]}//lsb_release
     /usr/lib/firefox-esr/firefox{,*[^s][^h]}//sanitized_helper
     /usr/lib/firefox/firefox{,*[^s][^h]}
     /usr/lib/firefox/firefox{,*[^s][^h]}//browser_java
     /usr/lib/firefox/firefox{,*[^s][^h]}//browser_openjdk
     /usr/lib/firefox/firefox{,*[^s][^h]}//lsb_release
     /usr/lib/firefox/firefox{,*[^s][^h]}//sanitized_helper

  But if you run Firefox-ESR you don't see its process(es) listed under
  "X processes are in enforce mode". Also the perceivable start-up slow-
  down due to apparmor is missing. Saving files in custom defined
  forbidden file paths is also possible. Firefox-ESR is apparently
  running without apparmor enforced.

  Possible Solution of the Problem:

  If you compare the apparmor-profiles under "/etc/apparmor.d/" of
  Firefox and Firefox-ESR you notice that they are very similar:

  Firefox

  # We want to confine the binaries that match:
  #  /usr/lib/firefox/firefox
  #  /usr/lib/firefox/firefox
  # but not:
  #  /usr/lib/firefox/firefox.sh
  /usr/lib/firefox/firefox{,*[^s][^h]} {

  Firefox-ESR

  # We want to confine the binaries that match:
  #  /usr/lib/firefox-esr/firefox-esr
  #  /usr/lib/firefox-esr/firefox
  # but not:
  #  /usr/lib/firefox-esr/firefox.sh
  /usr/lib/firefox-esr/firefox{,*[^s][^h]} {

  If you check "/usr/lib/firefox/" you will find the "firefox"
  application file and the "firefox.sh" script. But if you check
  "/usr/lib/firefox-esr/" you will find the application file is named
  "firefox-esr" not "firefox", but the script is still "firefox.sh".

  Therefore line 14 "/usr/lib/firefox-esr/firefox{,*[^s][^h]} {" in
  "usr.bin.firefox-esr" isn't working, since it should be "/usr/lib
  /firefox-esr/firefox-esr{,*[^s][^h]} {" or even just "/usr/lib
  /firefox-esr/firefox-esr {".

  By manually correcting the apparmor profile and reinforcing it,
  Firefox-ESR successfully runs in enforced mode and its process(es) are
  listed under "X processes are in enforce mode". Everything seems to be
  working correctly.

  Checking "X profiles are in enforce mode" again shows the old and new
  profile enforced simultaneously:

     /usr/lib/firefox-esr/firefox-esr{,*[^s][^h]}
     /usr/lib/firefox-esr/firefox-esr{,*[^s][^h]}//browser_java
     /usr/lib/firefox-esr/firefox-esr{,*[^s][^h]}//browser_openjdk
     /usr/lib/firefox-esr/firefox-esr{,*[^s][^h]}//lsb_release
     /usr/lib/firefox-esr/firefox-esr{,*[^s][^h]}//sanitized_helper
     /usr/lib/firefox-esr/firefox{,*[^s][^h]}
     /usr/lib/firefox-esr/firefox{,*[^s][^h]}//browser_java
     /usr/lib/firefox-esr/firefox{,*[^s][^h]}//browser_openjdk
     /usr/lib/firefox-esr/firefox{,*[^s][^h]}//lsb_release
     /usr/lib/firefox-esr/firefox{,*[^s][^h]}//sanitized_helper
     /usr/lib/firefox/firefox{,*[^s][^h]}
     /usr/lib/firefox/firefox{,*[^s][^h]}//browser_java
     /usr/lib/firefox/firefox{,*[^s][^h]}//browser_openjdk
     /usr/lib/firefox/firefox{,*[^s][^h]}//lsb_release
     /usr/lib/firefox/firefox{,*[^s][^h]}//sanitized_helper

  After setting Firefox-ESR to complain-mode and then again to enforce-
  mode the old enforced profile is removed:

     /usr/lib/firefox-esr/firefox-esr{,*[^s][^h]}
     /usr/lib/firefox-esr/firefox-esr{,*[^s][^h]}//browser_java
     

Re: [apparmor] Working principle of alias rules

[Seth Arnold]

On Wed, Jul 18, 2018 at 02:14:08PM -, roc...@openmailbox.org wrote:
> I have some questions for apparmor alias rules. Is it correct that an
> alias rule won't directly have an influence on which files can be
> accessed  on a certain rewritten path, i.e. the actual profile for the
> program is what matters more?

If I've understood the question correctly, you have to consider both a
profile and whatever alias rules the profile may load when determining
what resources the profiles allows processes to access.

> Could you make a program less confined
> just by alias rules? Sure you add another path, but on this path you are
> still allowed to only access files as described in the original profile
> of the program. Is this correct?

There's two ways of looking at this:
- "yes", even when "alias" rules are used, the profile is still confining
  any processes running within the profile, and all their access control
  decisions are made by consulting the profile.
- "no", the "alias" rules *are* a loosening of privileges, since one path
  given in the profile can grant access to more files.

I think you've got the correct understanding.

> What is the reason a rewrite path for
> "/" -> "/rw/" does not apply to all the rules, i.e. you have to
> specifically rewrite other paths too, like "/var/" -> "/rw/var/" ?

Are you sure about this? I couldn't find anything in the code that would
forbid / -> /rw from working, and a simple test (using / -> / instead,
so that it would stand out clearly in the dumps) seems to show it working
as I expect:

sarnold@hunt:~$ echo "alias / -> /, profile p { / r,}" | apparmor_parser -Q 
--dump=dfa-states
Warning from stdin (line 1): apparmor_parser: cannot use or update cache, 
disable, or force-complain via stdin
{1} <== (allow/deny/audit/quiet)
{2} (0x 10004/0/0/0)
{6} (0x 10004/0/0/0)

{1} -> {2}: 0x2f /
{2}  (0x 10004/0/0/0) -> {3}: 0x41 A
{3} -> {4}: 0x41 A
{4} -> {5}: 0x41 A
{5} -> {6}: 0x41 A

{1} <== (allow/deny/audit/quiet)
{2} (0x 4/0/0/0)

{1} -> {2}: 0x2
{1} -> {2}: 0x4
{1} -> {2}: 0x7
{1} -> {2}: 0x9
{1} -> {2}: 0xa
{1} -> {2}: 0x20 \
{1} -> {3}: 0x34 4
{3} -> {4}: 0x0
{4} -> {2}: 0x31 1

Note that the compiled policy looks the same as what I would expect it to
expand to:

sarnold@hunt:~$ echo "profile p { / r, / r,}" | apparmor_parser -Q 
--dump=dfa-states
Warning from stdin (line 1): apparmor_parser: cannot use or update cache, 
disable, or force-complain via stdin
{1} <== (allow/deny/audit/quiet)
{2} (0x 10004/0/0/0)
{6} (0x 10004/0/0/0)

{1} -> {2}: 0x2f /
{2}  (0x 10004/0/0/0) -> {3}: 0x41 A
{3} -> {4}: 0x41 A
{4} -> {5}: 0x41 A
{5} -> {6}: 0x41 A

{1} <== (allow/deny/audit/quiet)
{2} (0x 4/0/0/0)

{1} -> {2}: 0x2
{1} -> {2}: 0x4
{1} -> {2}: 0x7
{1} -> {2}: 0x9
{1} -> {2}: 0xa
{1} -> {2}: 0x20 \
{1} -> {3}: 0x34 4
{3} -> {4}: 0x0
{4} -> {2}: 0x31 1


If you have found a counter example, please share. :)

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

Re: [apparmor] apparmor="DENIED" operation="rename_src

[Seth Arnold]

On Tue, Jun 26, 2018 at 05:52:50PM -0500, Chris wrote:
> Since last Tuesday, 19 June, I've been seeing this in my syslog every
> time freshclam is run - https://pastebin.com/vyjqMJwb I was out of town
> when this started. The output of apparmor_parser -p usr.bin.freshclam
> is here - https://pastebin.com/X2b31V8h This is Ubuntu 16.04.4,
> freshclam version:

Hello Chris, thanks for this report. I've filed a bug to get the clamav
profile extended:

https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1778812

in the meantime you could add a new line:

  /var/log/clamav/* r,

to your /etc/apparmor.d/local/usr.bin.freshclam file, then reload the
profile with:

sudo apparmor_parser --replace /etc/apparmor.d/usr.bin.freshclam

If there are new DENIED lines fter this is loaded, please let us know.

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

Re: [apparmor] AppArmor's new logo

[Seth Arnold]

On Thu, Jun 14, 2018 at 12:38:00PM -0700, John Johansen wrote:
> Also I would like to add a special thanks to Noah Davis who provided the
> designs.

Thanks Noah!



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] [RFC] Refactoring apparmor-profiles repository

[Seth Arnold]

[Sorry Vincas, I accidentally sent my first message directly to you
rather than the list.]

On Sat, Jun 09, 2018 at 03:38:48PM +0300, Vincas Dargis wrote:
> profiles or should it backport it's rules inline? If it would be known that
> Ubuntu 18.10 will not have AppArmor 4.13, what if someone from OpenSUSE
> Tumbleweed would like to introduce new profile with 4.13 features? It can't
> go into ubuntu/18.10...

I think the intention was profiles for other distributions might get their
own top-level directory.. e.g. opensuse/ and so on.

So while the Ubuntu ones are split apart by version, rolling-release
distros might just edit their profiles in place.

Does this change your thinking?

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

Re: [apparmor] [profile] Update profile: /etc/cron.daily/logrotate.

[Seth Arnold]

On Wed, May 23, 2018 at 04:00:36PM +, daniel curtis wrote:
> Next thing I would like to ask and clarify is an 'Ux' access mode for
> two files:
> '/{usr/,}sbin/initctl' and '/{usr/,}sbin/runlevel' (for a reason for

> I would like to ask if 'Ux' could be changed, for example, with 'PUx'
> mode? Would not it be a better solution? And what about 'rPUx' (if I

Hello Daniel,

PUx would indeed be more secure if you were to go to the effort to confine
these two programs.

However, the system's proper functioning relies upon these two programs to
do their task, and you run a very high risk of making your computer
non-functional if you screw up these profiles.

These profiles would need to include a great deal of privilege. While you
could reduce the privileges they have, I'm not sure it is a meaninful
reduction.

So, yes, you *can* confine these programs. But please be sure to have a
recovery plan in place in case you find you cannot reboot your computer.

I think you would be better served to spend your time confining programs
that have open network sockets but do not yet have profiles.

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

Re: [apparmor] AppArmor Logo Vote

[Seth Arnold]

On Wed, May 30, 2018 at 11:57:14AM -0700, John Johansen wrote:
> 1. Vote for the logos basic form
> 
> a) Vertical split
> 
> b) split at an angle that mirrors the angle of the inner
> sides of the 'A's

The mirrored angle is my favourite.

> c) 45 degree split
> 
> d) other (please specify)
> 
> 
> 
> 2. For default logo color.
> 
> a) cyan

Cyan is my favourite.

> b) red
> 
> c) other (please specify)

Specifically apparmor-cyan-diag_1w2h.svg

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

Re: [apparmor] How to setup apparmor for calling an executable from another executable with a profile

[Seth Arnold]

On Tue, May 29, 2018 at 09:49:45PM +0700, Germán Diago Gómez wrote:
> sudo apparmor_parser -r -W myprofile-file
> 
> And run the docker machine like this:
> 
> docker run ... --security-opt apparmor=my-profile ...
> 
> if I execute /usr/bin/myexe I get permission denied

Hello,

If you check your audit logs or dmesg you will find an AppArmor DENIED
line with full details about the denied request. Once you've got those,
then it'll be easier to make concrete suggestions for changes.

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

Re: [apparmor] Proposal for a new AppArmor logo

[Seth Arnold]

On Thu, May 24, 2018 at 05:56:51AM -0400, Noah Davis wrote:
> Here are 2 different versions. One has a 45 degree split while the
> other has a split at an angle that mirrors the angle of the inner
> sides of the 'A's.

I like the red too; I prefer the cyan but that just might be a holdover
from my BBS days.. I think my 'ideal' use of these icons would be cyan for
nearly everything, and red in the i3bar or notification area when there's
recent DENIED lines in my audit logs.

I think I prefer the symmetric split vs the 45 degree split but honestly
they're both really sharp. :)

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

Re: [apparmor] Proposal for a new AppArmor logo

[Seth Arnold]

On Tue, May 22, 2018 at 09:27:58PM -0400, Noah Davis wrote:
> Whoops, I accidentally sent an older 32x32 version. I've attached the
> 64x64 version with some slight adjustments to the size of the 'A's,
> inner shield and height of the shadow on the leg of the white 'A'.
> This kind of logo isn't really suitable for icon resolutions smaller
> than 32x32, so I could make an alternative logo specifically for 22x22
> and 16x16.

This is really cool :) thanks!

I think my sense of symmetry would prefer if the lower, left-side shadow
would reach a point at the same level of the right-side inverted A,
to match the pointy shadow at the top on the upper left side... have
you tried more symmetry? or is the asymmetry important to the design?

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

Re: [apparmor] [PATCH] apparmor: Add support for audit rule filtering

[Seth Arnold]

On Fri, Apr 13, 2018 at 11:22:11AM -0700, Matthew Garrett wrote:
> +int aa_audit_rule_init(u32 field, u32 op, char *rulestr, void **vrule)
> +{
> + struct aa_audit_rule *rule;
> +
> + switch (field) {
> + case AUDIT_SUBJ_ROLE:
> + if (op != Audit_equal && op != Audit_not_equal)
> + return -EINVAL;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + rule = kzalloc(sizeof(struct aa_audit_rule), GFP_KERNEL);
> +
> + if (!rule)
> + return -ENOMEM;
> +
> + rule->profile = kstrdup(rulestr, GFP_KERNEL);

Hi Matthew, if this allocation fails, 'rule' is returned malformed; is
this intentional?

> + *vrule = rule;
> +
> + return 0;
> +}

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

Re: [apparmor] Let's enable AppArmor by default (why not?)

[Seth Arnold]

On Mon, Mar 19, 2018 at 10:10:02AM -0400, Marvin Renich wrote:
> Is there a way that an app (e.g. smbd) whose file access requirements
> change dynamically through admin and user configuration can at least
> inspect its own apparmor profile and give the user a clue that the admin
> must update the profile?

Our friends at SUSE have a script that automatically generates portions of
an AppArmor profile for Samba based on the Samba configuration:
https://bugzilla.novell.com/show_bug.cgi?id=688040

I'm not entirely sold on the idea, as a hand-authored security policy
can serve as belt-and-suspenders against misconfiguration or a broken
management system that allows unauthenticated users to create too-wide
shares.

The usability gain is undeniable.

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

Re: [apparmor] AA and VirtualBox ptrace issue

[Seth Arnold]

On Fri, Mar 02, 2018 at 01:07:55AM +0100, Malte Gell wrote:
> Hi there,
> when starting VirtualBox AA complains about lacking ptrace access:
> 
> Profile: /usr/lib/virtualbox/VirtualBox
> Operation: ptrace
> Denied: trace
> 
> Though, I have granted ptrace rights in the profile:
> 
> audit capability sys_ptrace,

Hello Malte, what is the message directly from the kernel audit system?

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

Re: [apparmor] IPC and sockets

[Seth Arnold]

Hi Slava,

On Thu, Feb 15, 2018 at 05:21:43PM +0200, Viacheslav Salnikov wrote:
> does AppArmor complain about communication through the unix domain
> sockets into dmesg?

AppArmor's kernel mediation uses the audit facility, which on most systems
does go through dmesg, but with lossy rate-limiting output. Probably
"yes" is the answer you're looking for here :) but I wanted to give a
fuller picture.

> All I've got - AppArmor can restrict access to named unix socket as a
> file - because it is a file - without using "deny unix". Actually, deny
> unix does not work for me with named sockets.

Correct; the sockets in the filesystem have course rules compared to
the sockets in the abstract and unnamed namespaces:

   Unix socket rules
   AppArmor supports fine grained mediation of unix domain
   abstract and anonymous sockets. Unix domain sockets with file
   system paths are mediated via file access rules.
   [...]

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

Re: [apparmor] [PATCH 1/3] apparmor: Add support for attaching profiles via xattr, presence and value

[Seth Arnold]

On Thu, Feb 08, 2018 at 04:04:37PM -0800, John Johansen wrote:
> > If this step fails before completion, the xattrs array may have some
> > entries that weren't properly initialized; I suspect the free operation
> > will cause serious trouble in this case.
> > 
> yep we can switch the kmalloc_array for a kcalloc, and that will fix it
> 

Ah I like the sound of that better than zeroing the arrays manually.

With this change,

Acked-by: Seth Arnold <seth.arn...@canonical.com>

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

Re: [apparmor] [PATCH 2/3] apparmor: convert attaching profiles via xattrs to use, dfa matching

[Seth Arnold]

On Thu, Feb 08, 2018 at 12:38:57PM -0800, John Johansen wrote:
> This converts profile attachment based on xattrs to a fixed extended
> conditional using dfa matching.
> 
> This has a couple of advantages
> - pattern matching can be used for the xattr match
> 
> - xattrs can be optional for an attachment or marked as required
> 
> - the xattr attachment conditional will be able to be combined with
>   other extended conditionals when the flexible extended conditional
>   work lands.
> 
> The xattr fixed extended conditional is appended to the xmatch
> conditional. If an xattr attachment is specified the profile xmatch
> will be generated regardless of whether there is a pattern match on
> the executable name.
> 
> Signed-off-by: John Johansen <john.johan...@canonical.com>

Acked-by: Seth Arnold <seth.arn...@canonical.com>

Thanks

> ---
>  security/apparmor/apparmorfs.c |  5 
>  security/apparmor/domain.c | 52 
> ++
>  security/apparmor/include/policy.h |  2 --
>  security/apparmor/policy.c |  6 +
>  security/apparmor/policy_unpack.c  | 32 ---
>  5 files changed, 42 insertions(+), 55 deletions(-)
> 
> diff --git a/security/apparmor/apparmorfs.c b/security/apparmor/apparmorfs.c
> index 1e63ff2e5b85..35e6b240fb14 100644
> --- a/security/apparmor/apparmorfs.c
> +++ b/security/apparmor/apparmorfs.c
> @@ -2147,6 +2147,10 @@ static struct aa_sfs_entry aa_sfs_entry_signal[] = {
>   { }
>  };
>  
> +static struct aa_sfs_entry aa_sfs_entry_attach[] = {
> + AA_SFS_FILE_BOOLEAN("xattr", 1),
> + { }
> +};
>  static struct aa_sfs_entry aa_sfs_entry_domain[] = {
>   AA_SFS_FILE_BOOLEAN("change_hat",   1),
>   AA_SFS_FILE_BOOLEAN("change_hatv",  1),
> @@ -2155,6 +2159,7 @@ static struct aa_sfs_entry aa_sfs_entry_domain[] = {
>   AA_SFS_FILE_BOOLEAN("stack",1),
>   AA_SFS_FILE_BOOLEAN("fix_binfmt_elf_mmap",  1),
>   AA_SFS_FILE_BOOLEAN("post_nnp_subset",  1),
> + AA_SFS_DIR("attach_conditions", aa_sfs_entry_attach),
>   AA_SFS_FILE_STRING("version", "1.2"),
>   { }
>  };
> diff --git a/security/apparmor/domain.c b/security/apparmor/domain.c
> index ca8353f3e7a0..9651e18cbae5 100644
> --- a/security/apparmor/domain.c
> +++ b/security/apparmor/domain.c
> @@ -306,11 +306,12 @@ static int change_profile_perms(struct aa_profile 
> *profile,
>   * aa_xattrs_match - check whether a file matches the xattrs defined in 
> profile
>   * @bprm: binprm struct for the process to validate
>   * @profile: profile to match against (NOT NULL)
> + * @state: state to start match in
>   *
>   * Returns: number of extended attributes that matched, or < 0 on error
>   */
>  static int aa_xattrs_match(const struct linux_binprm *bprm,
> -struct aa_profile *profile)
> +struct aa_profile *profile, unsigned int state)
>  {
>   int i;
>   size_t size;
> @@ -321,27 +322,40 @@ static int aa_xattrs_match(const struct linux_binprm 
> *bprm,
>   if (!bprm || !profile->xattr_count)
>   return 0;
>  
> + /* transition from exec match to xattr set */
> + state = aa_dfa_null_transition(profile->xmatch, state);
> +
>   d = bprm->file->f_path.dentry;
>  
>   for (i = 0; i < profile->xattr_count; i++) {
>   size = vfs_getxattr_alloc(d, profile->xattrs[i], ,
> value_size, GFP_KERNEL);
> - if (size < 0) {
> - ret = -EINVAL;
> - goto out;
> - }
> + if (size >= 0) {
> + u32 perm;
>  
> - /* Check the xattr value, not just presence */
> - if (profile->xattr_lens[i]) {
> - if (profile->xattr_lens[i] != size) {
> + /* Check the xattr value, not just presence */
> + state = aa_dfa_match_len(profile->xmatch, state, value,
> +  size);
> + perm = dfa_user_allow(profile->xmatch, state);
> + if (!(perm & MAY_EXEC)) {
>   ret = -EINVAL;
>   goto out;
>   }
> -
> - if (memcmp(value, profile->xattr_values[i], size)) {
> + }
> + /* transition to next element */
> + state = aa_dfa_null_transition(profile->xmatch, state);
> +  

Re: [apparmor] [PATCH 1/3] apparmor: Add support for attaching profiles via xattr, presence and value

[Seth Arnold]

Hello,

On Thu, Feb 08, 2018 at 12:37:19PM -0800, John Johansen wrote:
> +static bool unpack_xattrs(struct aa_ext *e, struct aa_profile *profile)
> +{
> + void *pos = e->pos;
> +
> + if (unpack_nameX(e, AA_STRUCT, "xattrs")) {
> + int i, size;
> +
> + size = unpack_array(e, NULL);
> + profile->xattr_count = size;
> + profile->xattrs = kmalloc_array(size, sizeof(char *),
> + GFP_KERNEL);
> + if (!profile->xattrs)
> + goto fail;
> + for (i = 0; i < size; i++) {
> + if (!unpack_strdup(e, >xattrs[i], NULL))
> + goto fail;

If this step fails before completion, the xattrs array may have some
entries that weren't properly initialized; I suspect the free operation
will cause serious trouble in this case.

> + }
> + if (!unpack_nameX(e, AA_ARRAYEND, NULL))
> + goto fail;
> + if (!unpack_nameX(e, AA_STRUCTEND, NULL))
> + goto fail;
> + }
> +
> + if (unpack_nameX(e, AA_STRUCT, "xattr_values")) {
> + int i, size;
> +
> + size = unpack_array(e, NULL);
> +
> + /* Must be the same number of xattr values as xattrs */
> + if (size != profile->xattr_count)
> + goto fail;
> +
> + profile->xattr_lens = kmalloc_array(size, sizeof(size_t),
> + GFP_KERNEL);
> + if (!profile->xattr_lens)
> + goto fail;
> +
> + profile->xattr_values = kmalloc_array(size, sizeof(char *),
> +   GFP_KERNEL);

Same thing here with the xattr_lens and xattr_values arrays.

> + if (!profile->xattr_values)
> + goto fail;
> +
> + for (i = 0; i < size; i++) {
> + profile->xattr_lens[i] = unpack_blob(e,
> +   >xattr_values[i], NULL);
> + profile->xattr_values[i] =
> + kvmemdup(profile->xattr_values[i],
> +  profile->xattr_lens[i]);
> + }
> +
> + if (!unpack_nameX(e, AA_ARRAYEND, NULL))
> + goto fail;
> + if (!unpack_nameX(e, AA_STRUCTEND, NULL))
> + goto fail;
> + }
> + return 1;
> +
> +fail:
> + e->pos = pos;
> + return 0;
> +}

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

Re: [apparmor] Comments within a Variable Assignment lines

[Seth Arnold]

On Fri, Jan 05, 2018 at 08:32:02PM -0300, Nibaldo González wrote:
> Hello. I developed syntax highlighting for AppArmor profiles, in KDE's text
> editors (KSyntaxHighlighting Framework). I have been updating the
> highlighting and I have some questions about the comments in AppArmor.

That's cool, thanks!

> Checking the AppArmor parser and doing some tests, I have drawn some
> conclusions:
> [...]
> In this case, AppArmor grants write and read permissions to files with
> extension: '.#.txt', '.#All', '.the', '.format', '.#.xml', '.and',
> etc. Clearly, the profile must be fixed.

Wow. Thanks.

https://bugs.launchpad.net/ubuntu/+source/libreoffice-l10n/+bug/1741581

> Finally, is this a bug? Should AppArmor consider comments on the variable
> assignment?

This does feel like something we should address in the parser.

https://bugs.launchpad.net/apparmor/+bug/1741584

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

Re: [apparmor] logs with name="not an absolute path" or name=HEXSTRING

[Seth Arnold]

On Wed, Dec 20, 2017 at 02:00:34AM -0800, John Johansen wrote:
> iirc there are a couple of cases that need to be fixed.

There's a patch for supporting the proctitle lines at
https://bugs.launchpad.net/apparmor/+bug/1736841

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

Re: [apparmor] Help needed - Apparmor usage

[Seth Arnold]

On Sat, Dec 09, 2017 at 07:08:32PM +0530, harshad wadkar wrote:
> I am trying to solve a problem wherein I would like to give (read, write)
> access to file X, if it is accessed by only application Y and again if the
> application Y is invoked by root user.
> 
> I do not want file X can be accessed (read, write, delete etc) using
> application Z - even if Z is invoked by root user.

Hello Harshad, thanks for your interest in AppArmor.

AppArmor's mediation is best understood from the perspective of processes:
You provide profiles that apply to processes. Confined processes carry
their policy into their children across fork() or clone() systemcalls,
the policy may change on execve() systemcalls, or an application may
drive its own policy changes with the aa_change_hat(), aa_change_hatv(),
aa_change_profile() or aa_change_onexec() library calls.

Depending upon what you mean by "using application Z" above, the policy
might be trivial to write or might be extremely difficult to write.

If the question is, "can root processes be confined?" then the answer is
"yes".

If the question is, "can I write file-oriented policy rather than
process-oriented policy?", it's probably best to assume the answer is
"probably not".

(Correctly enumerating everything else that all processes on the system is
allowed to do, and successfully putting all processes into that profile,
is extremely difficult.)

If you can fill in the details of what exactly you're trying to accomplish
then we can probably give more useful answers. It's hard to respond to
hypothetical questions.

> 2)
> is there any firefox profile for Apparmor available?

This profile is shipped in the Ubuntu 16.04 LTS package for Firefox:


# vim:syntax=apparmor
# Author: Jamie Strandboge 

# Declare an apparmor variable to help with overrides
@{MOZ_LIBDIR}=/usr/lib/firefox

#include 

# We want to confine the binaries that match:
#  /usr/lib/firefox/firefox
#  /usr/lib/firefox/firefox
# but not:
#  /usr/lib/firefox/firefox.sh
/usr/lib/firefox/firefox{,*[^s][^h]} {
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  #include 
  dbus (send)
   bus=session
   peer=(name=org.a11y.Bus),
  dbus (receive)
   bus=session
   interface=org.a11y.atspi**,
  dbus (receive, send)
   bus=accessibility,

  # for networking
  network inet stream,
  network inet6 stream,
  @{PROC}/[0-9]*/net/arp r,
  @{PROC}/[0-9]*/net/if_inet6 r,
  @{PROC}/[0-9]*/net/ipv6_route r,
  @{PROC}/[0-9]*/net/dev r,
  @{PROC}/[0-9]*/net/wireless r,
  dbus (send)
   bus=system
   path=/org/freedesktop/NetworkManager
   member=state,
  dbus (receive)
   bus=system
   path=/org/freedesktop/NetworkManager,

  # should maybe be in abstractions
  /etc/ r,
  /etc/mime.types r,
  /etc/mailcap r,
  /etc/xdg/*buntu/applications/defaults.listr, # for all derivatives
  /etc/xfce4/defaults.list r,
  /usr/share/xubuntu/applications/defaults.list r,
  owner @{HOME}/.local/share/applications/defaults.list r,
  owner @{HOME}/.local/share/applications/mimeapps.list r,
  owner @{HOME}/.local/share/applications/mimeinfo.cache r,
  /var/lib/snapd/desktop/applications/mimeinfo.cache r,
  /var/lib/snapd/desktop/applications/*.desktop r,
  owner /tmp/** m,
  owner /var/tmp/** m,
  owner /{,var/}run/shm/shmfd-* rw,
  owner /{dev,run}/shm/org.chromium.* rwk,
  /tmp/.X[0-9]*-lock r,
  /etc/udev/udev.conf r,
  # Doesn't seem to be required, but noisy. Maybe allow 'r' for 'b*' if needed.
  # Possibly move to an abstraction if anything else needs it.
  deny /run/udev/data/** r,
  # let the shell know we launched something
  dbus (send)
 bus=session
 interface=org.gtk.gio.DesktopAppInfo
 member=Launched,

  /etc/timezone r,
  /etc/wildmidi/wildmidi.cfg r,

  # firefox specific
  /etc/firefox*/ r,
  /etc/firefox*/** r,
  /etc/xul-ext/** r,
  /etc/xulrunner-2.0*/ r,
  /etc/xulrunner-2.0*/** r,
  /etc/gre.d/ r,
  /etc/gre.d/* r,

  # noisy
  deny @{MOZ_LIBDIR}/** w,
  deny /usr/lib/firefox-addons/** w,
  deny /usr/lib/xulrunner-addons/** w,
  deny /usr/lib/xulrunner-*/components/*.tmp w,
  deny /.suspended r,
  deny /boot/initrd.img* r,
  deny /boot/vmlinuz* r,
  deny /var/cache/fontconfig/ w,
  deny @{HOME}/.local/share/recently-used.xbel r,

  # TODO: investigate
  deny /usr/bin/gconftool-2 x,

  # These are needed when a new user starts firefox and firefox.sh is used
  @{MOZ_LIBDIR}/** ixr,
  /usr/bin/basename ixr,
  /usr/bin/dirname ixr,
  /usr/bin/pwd ixr,
  /sbin/killall5 ixr,
  /bin/which ixr,
  /usr/bin/tr ixr,
  @{PROC}/ r,
  @{PROC}/[0-9]*/cmdline r,
  @{PROC}/[0-9]*/mountinfo r,
  @{PROC}/[0-9]*/stat r,
  owner @{PROC}/[0-9]*/task/[0-9]*/stat r,
  @{PROC}/[0-9]*/status r,
  @{PROC}/filesystems r,
  @{PROC}/sys/vm/overcommit_memory r,
  /sys/devices/pci[0-9]*/**/uevent r,
  /sys/devices/platform/**/uevent r,
  /sys/devices/pci*/**/{busnum,idVendor,idProduct} r,

Re: [apparmor] IPC and sockets

[Seth Arnold]

On Fri, Dec 08, 2017 at 06:20:01PM +0200, Viacheslav Salnikov wrote:
> I want to ensure that communication through unix socket is monitored by
> apparmor.
> What should I do to make this happen?

Hello Viacheslav,

This is actually slightly complicated to answer:

- Different kernels will have different kinds of mediation available.
  Hopefully this problem will be getting better in the future, but in the
  meantime, it's best to check the advertised features of the system in
  question:

  $ cat /sys/kernel/security/apparmor/features/network/af_unix
  yes

- Different parsers will have different kinds of mediation available. The
  easy test is to try:

  $ echo "profile p { unix, }" | apparmor_parser -Qd
  Warning from stdin (line 1): apparmor_parser: cannot use or update
  cache, disable, or force-complain via stdin
  - Debugging built structures -
  Name: p
  Profile Mode: Enforce
  unix (),

- Policy pinning via apparmor_parser's --features-file (-M) setting may
  influence what is actually compiled.

I hope this helps, please don't hesitate to ask for further help.

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

Re: [apparmor] [profile] netstat: cannot open /proc/net/dev (permission denied.) Limited output.

[Seth Arnold]

On Wed, Dec 06, 2017 at 07:14:05PM +, daniel curtis wrote:
> ✗ apparmor="DENIED" operation="open" profile="/bin/netstat"
> name="/proc/2513/net/dev" pid=4084 comm="netstat" requested_mask="r"
> denied_mask="r" fsuid=0 ouid=0
>$
> As we can see, there is a simple "DENIED" action referring to the {PROC}
> folder. What all of you thinks about adding something like this to the
> netstat profile? (Which one is a better choice? I would like to use the
> first rule, because it uses a new '@{pid}' type.)
>$
> @{PROC}/@{pid}/net/dev r,
> @{PROC}/[0-9]*/net/dev r,

Hello Daniel, nice find.

I strongly recommend using:

@{PROC}/@{pids}/net/dev r,

@{pid} will probably mean "this specific process's pid" at some point in
the future. @{pids} will remain "all valid pids".

> And what about an "owner" prefix? Is it needed here? Because of a "missing
> interface information" line found in error, I decided to add an interface
> (an example: '$ sudo netstat -ni enp0s11') but an error message was exactly
> the same as above. Log file entry was also the same, of course except PIDs
> numbers.

Don't add 'owner' to netstat rules: an administrator needs to inspect all
processes owned by all users.

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

Re: [apparmor] [profile] Evince: the lack of "private-files-strict" and a lenient, dangerous rules related to @{HOME} folder.

[Seth Arnold]

On Sat, Dec 02, 2017 at 03:40:52PM +, daniel curtis wrote:
> Thank You for an answer and sorry for my naive, stupid questions and other
> things.

Hello Daniel, please don't think your questions are naive or stupid! You
just have the luxury of not seeing evince bugs over many years. :)

> [1] http://www.morbo.org/2017/11/linux-sandboxing-improvements-in.html

This is good news indeed, thanks for sharing the link.



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] [profile] Evince: the lack of "private-files-strict" and a lenient, dangerous rules related to @{HOME} folder.

[Seth Arnold]

Hello Daniel,

On Wed, Nov 29, 2017 at 05:02:25PM +, daniel curtis wrote:
> I'm asking, because Evince is a document viewer (PostScript, PDF).
> Of course it allows e.g. printing PS files, EPS etc., text searching, 
> hypertext
> navigation and bookmarks with index when it is available in the document
> and so on. So, are these rules above necessary?

Believe me, we get _so many bug reports_ about various pieces of evince
that don't work due to AppArmor profiles that you're going to have a very
hard time selling us on removing rules from the default profile.

Distro-provided profiles will always be too permissive for some users. The
long-term vision for these users involves stacking profiles together
to further restrict operations. You can do this today, sortof, but it
takes some work.

> I would like to remove all unnecessary rules. Just like with Firefox
> profile where, by default, files can be downloaded to every folder in
> @{HOME}. I'd to make some changes: add about 6 rules to the Firefox profile
> and edit "/abstractions/ubuntu browsers.d/user-files"
> (that's a place with rules that allow write access everywhere in  $HOME
> etc.)
> 
> After mentioned changes, users can download only to the "Download" folder,
> not everywhere. Oh, and I added an abstractions "private-files" rule. (Plus
> two more needed rules, because of a "DENIED" entry.) I think it's a safer
> solution, but maybe I'm wrong.

Strictly speaking, even if you remove the ~/** rw, kinds of rules from
firefox's profile, you'll still be able to download to any writable
location in the profile. Doing any different would require modifications
to Firefox.

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

Re: [apparmor] [RFC] Apparmor: Add support for attaching profiles via xattr presence and value

[Seth Arnold]

Hello Matthew, thanks for this; I'll let John comment on the larger design
of the patch, I'll just nitpick one little piece:

On Tue, Nov 28, 2017 at 04:08:15PM -0800, Matthew Garrett wrote:
> --- a/security/apparmor/include/policy.h
> +++ b/security/apparmor/include/policy.h
> @@ -148,6 +148,12 @@ struct aa_profile {
>   struct aa_policydb policy;
>   struct aa_file_rules file;
>   struct aa_caps caps;
> +
> + int xattr_count;
> + const char **xattrs;
> + size_t *xattr_lens;
> + char **xattr_values;
> +
>   struct aa_rlimit rlimits;
>  
>   struct aa_loaddata *rawdata;
> diff --git a/security/apparmor/policy.c b/security/apparmor/policy.c
> index b0b58848c248..168b1d5272d9 100644
> --- a/security/apparmor/policy.c
> +++ b/security/apparmor/policy.c
> @@ -227,6 +227,9 @@ void aa_free_profile(struct aa_profile *profile)
>   aa_free_cap_rules(>caps);
>   aa_free_rlimit_rules(>rlimits);
>  
> + kzfree(profile->xattrs);
> + kzfree(profile->xattr_lens);
> + kzfree(profile->xattr_values);
>   kzfree(profile->dirname);
>   aa_put_dfa(profile->xmatch);
>   aa_put_dfa(profile->policy.dfa);

profile->xattr_values is a vector of strings, but only the pointers are
cleaned up here, leaking all the xattr values themselves when the profile
is freed.

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

Re: [apparmor] Syntax Error: Unknown line found in file /etc/apparmor.d/usr.lib.snapd.snap-confine.real.

[Seth Arnold]

On Thu, Nov 23, 2017 at 09:33:45AM +, daniel curtis wrote:
> ✗ ERROR: Syntax Error: Unknown line found in file
> /etc/apparmor.d/usr.lib.snapd.snap-confine.real line 15:
> include "/var/lib/snapd/apparmor/snap-confine.d" /etc/ld.so.cache r,
> 
> >> So either you're going to be hand-editing your other profiles
> >> to do what you want or hand-editing the broken profile.
> 
> So, what should I do? What do You think? If hand-editing is a good method
> then I have to remove/comment "include" line? (That's the place, which
> create above error.) Or maybe there is another way?

Hello Daniel, it looks like the 'source' of this issue has been found:
https://github.com/snapcore/snapd/pull/4306/files

I don't know how long until this update lands in a downloadable tool.

> I would like to ask one more question: if I'm not using snap, can I disable
> services such like: snapd.service, snapd.refresh.timer, snapd.socket and so
> on? Of course via systemctl(1) If I can do this, then I can also remove
> "usr.lib.snapd.snap-confine.real" profile.

If you have any trouble using these tools to disable snapd, please do file
bugs about it. You can of course also purge snapd if you're not using any
snaps.

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

Re: [apparmor] Syntax Error: Unknown line found in file /etc/apparmor.d/usr.lib.snapd.snap-confine.real.

[Seth Arnold]

On Wed, Nov 22, 2017 at 07:32:39PM +, daniel curtis wrote:
> /usr/lib/snapd/snap-confine (attach_disconnected) {
> [...]
> include "/var/lib/snapd/apparmor/snap-confine.d"
> 
> # We run privileged, so be fanatical about (...)
> /etc/ld.so.cache r,

Hello Daniel, I'm having trouble finding this profile. Can you report
where it came from? I have a vague feeling that this isn't the first bug
report I've seen to include it, but I just can't find the thing to
investigate further.

> aa-enforce(8) command produces the same error as above. As we can see, the
> error is the same. So it seems, that I'm unable to work with AppArmor
> profiles!

The Python-based utilities all assume that the AppArmor profiles always
parse properly. Any bug in any profile makes all the Python tools useless
on all profiles.

We cannot address this limitiation in any reasonable way.

When a profile is broken in a way that prevents the tools from parsing
the profile, you have no choice but to fix the broken profile if you wish
to use any of the Python tools. Of course, that may have consequences:

- Debian packages often will only upgrade a "configuration file"
  automatically if it is unchanged. So fixing a bug in a profile that
  was shipped in a Debian package may mean you do not get updates to
  the configuration file in the future. Worse yet you will have no
  notification of this most of the time.

- Tools that automatically modify the profile may not recognize the
  profile after you fix it. Hopefully this is rare. Hopefully such
  hypothetical tools are more resilient to small changes than this.

So either you're going to be hand-editing your other profiles to do what
you want or hand-editing the broken profile. I don't see other choices.

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

Re: [apparmor] [administrivia] git conversion complete; gitlab projects set up

[Seth Arnold]

On Wed, Nov 01, 2017 at 03:46:17PM -0500, Tyler Hicks wrote:
> What the maintainer did for the GitHub contribution that I mentioned
> above was to merge my pull request into a local branch, interactive
> rebase to add his Signed-off-by, and then push the resulting branch to
> to the master branch on GitHub.

This sounds like a lot of overhead and extra work. What does the extra
annotation buy that is lacking from a more simplistic merge?

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

Re: [apparmor] [PATCH 1/2] Introduce UI_Changes functions.

[Seth Arnold]

On Thu, Oct 26, 2017 at 12:12:25AM +0200, Christian Boltz wrote:
> Hello,
> 
> Am Montag, 23. Oktober 2017, 12:38:33 CEST schrieb Goldwyn Rodrigues:
> > From: Goldwyn Rodrigues <rgold...@suse.com>
> > 
> > This is a preparation patch to use for JSON mode of conveying
> > diff filename. In this patch we move diff generation functions to UI.
> > In the process, I have cleaned up the code to reduce code and enable
> > reuse.
> > 
> > Remove unused function get_profile_diff().
> > 
> > Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com>
> 
> Acked-by: Christian Boltz <appar...@cboltz.de>
> 
> on the condition that someone acks this small patch to avoid breaking 
> aa-mergeprof.

Acked-by: Seth Arnold <seth.arn...@canonical.com>

Thanks

> Hint: Whenever you delete a function, grep -r for it ;-)
> 
> 
> === modified file 'utils/aa-mergeprof'
> --- utils/aa-mergeprof  2017-03-02 21:21:53 +
> +++ utils/aa-mergeprof  2017-10-25 22:01:19 +
> @@ -128,7 +128,7 @@
>  apparmor.aa.original_aa[program] = 
> apparmor.aa.deepcopy(apparmor.aa.aa[program])
>  #oldprofile = 
> apparmor.serialize_profile(apparmor.original_aa[program], program, '')
>  newprofile = 
> apparmor.aa.serialize_profile(mergeprofiles.user.aa[program], program, '')
> -
> apparmor.aa.display_changes_with_comments(mergeprofiles.user.filename, 
> newprofile)
> +aaui.UI_Changes(mergeprofiles.user.filename, newprofile, 
> comments=True)
>  elif ans == 'CMD_IGNORE_ENTRY':
>  break
> 
>  
> (I'll commit this together with the main patch.)


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] [PATCH] Update nscd profile to add /etc/netconfig

[Seth Arnold]

On Wed, Oct 18, 2017 at 05:22:52PM +0200, Christian Boltz wrote:
> Am Mittwoch, 18. Oktober 2017, 16:10:20 CEST schrieb Goldwyn Rodrigues:
> > References: https://bugzilla.suse.com/show_bug.cgi?id=1062244
> The funny thing is that I submitted a similar patch to Tumbleweed 
> yesterday after a discussion on the opensuse-factory mailinglist:
> https://build.opensuse.org/request/show/534597
> https://lists.opensuse.org/opensuse-factory/2017-10/msg00401.html )

> I propose this patch for 2.9..trunk.

Thanks for the copious documentation :)

Acked-by: Seth Arnold <seth.arn...@canonical.com>
acked for all

Thanks

> 
> +=== modified file 'profiles/apparmor.d/abstractions/nameservice'
> +--- profiles/apparmor.d/abstractions/nameservice 2017-09-15 20:47:26 
> +
>  profiles/apparmor.d/abstractions/nameservice 2017-10-17 21:29:36 
> +
> +@@ -21,6 +21,9 @@
> +   /etc/passwd r,
> +   /etc/protocols  r,
> + 
> ++  # libtirpc (used for NIS/YP login) needs this
> ++  /etc/netconfig r,
> ++
> +   # When using libnss-extrausers, the passwd and group files are merged from
> +   # an alternate path
> +   /var/lib/extrausers/group  r,



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] [patch] Allow /var/run/dovecot/login-master-notify* in dovecot imap-login profiles

[Seth Arnold]

On Thu, Sep 28, 2017 at 01:19:30PM +0200, Christian Boltz wrote:
> Hello,
> 
> $subject.
> 
> Note that Dovecot really uses /var/run/ ;-)
> 
> 
> I propose this patch for trunk, 2.11, 2.10 and 2.9.

Acked for all three.

Acked-by: Seth Arnold <seth.arn...@canonical.com>

Thanks

> 
> [ dovecot-imap-login.diff ]
> 
> === modified file 'profiles/apparmor.d/usr.lib.dovecot.imap-login'
> --- profiles/apparmor.d/usr.lib.dovecot.imap-login  2017-01-26 20:41:38 
> +
> +++ profiles/apparmor.d/usr.lib.dovecot.imap-login  2017-09-28 11:18:29 
> +
> @@ -26,6 +26,7 @@
>  
>/usr/lib/dovecot/imap-login mr,
>/{,var/}run/dovecot/anvil rw,
> +  /{,var/}run/dovecot/login-master-notify* rw,
>/{,var/}run/dovecot/login/ r,
>/{,var/}run/dovecot/login/* rw,
>  


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] [Merge] ~sdeziel/apparmor-profiles/+git/apparmor-profiles:thunderbird-icedove-debian into apparmor-profiles:master

[Seth Arnold]

On Fri, Sep 22, 2017 at 04:00:19PM -, Vincas Dargis wrote:
> > and use @{pid} and @{pids} accordingly
> These work in kernel? 

Not yet, but it is something we'd like to do eventually.

Thanks

-- 
https://code.launchpad.net/~sdeziel/apparmor-profiles/+git/apparmor-profiles/+merge/330183
Your team AppArmor Developers is subscribed to branch apparmor-profiles:master.

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

Re: [apparmor] What to do about bubblewrap started from apps confined with AppArmor?

[Seth Arnold]

On Wed, Sep 20, 2017 at 01:15:20PM +0200, intrigeri wrote:
> At this point I wonder if it's worth our time to write and maintain
> a profile for /usr/bin/bwrap. My current take of it is: probably not.

I think it is; first, this does raise the question of why is whatever it
is that it executes not listed in this profile? Getting to the bottom of
that is already a good start. :)

Once that's sorted out, I think it'll be a good to have a list of things
that might possibly have access to all the above privileges in the event
bugs are found in bwrap, and confine those things according to the
privileges they may actually need.

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

Re: [apparmor] [Merge] lp:~talkless/apparmor/abstractions_fonts_mmap into lp:apparmor

[Seth Arnold]

I dislike this one too (similar to 
https://code.launchpad.net/~talkless/apparmor/gnome_abstraction_thumbnail_cache/+merge/330883/comments/866778
 ), but at least /usr/share/fonts/ should be under complete control of the 
packaging system and admin.

I'd hope though that asking Skype team to not use the read-implies-execution 
personality would fix this one as well.

Thanks
-- 
https://code.launchpad.net/~talkless/apparmor/abstractions_fonts_mmap/+merge/330884
Your team AppArmor Developers is requested to review the proposed merge of 
lp:~talkless/apparmor/abstractions_fonts_mmap into lp:apparmor.

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

Re: [apparmor] [Merge] lp:~talkless/apparmor/gnome_abstraction_thumbnail_cache into lp:apparmor

[Seth Arnold]

The 'm' privilege is for _executable_ memory maps.

I dislike giving this permission here -- especially since thumbnailers are so 
often abused and targeted by exploits.

My theory is that they are running with a code personality where READ_IMPLIES_X 
(based entirely on the per=40 entries in the logs) -- is the skype team 
accessible? Can they report back why they use this personality?

Thanks
-- 
https://code.launchpad.net/~talkless/apparmor/gnome_abstraction_thumbnail_cache/+merge/330883
Your team AppArmor Developers is requested to review the proposed merge of 
lp:~talkless/apparmor/gnome_abstraction_thumbnail_cache into lp:apparmor.

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

Re: [apparmor] [PATCH] remove /var/run alternations in favor of /run

[Seth Arnold]

On Fri, Sep 15, 2017 at 08:19:24AM -0500, Jamie Strandboge wrote:
> 
> Description: remove /{,var/}run, /{var/,}run and {var/run,run} alternations in
> favor of /run. This migration happened corss-distribution in late 2011 when 
> the
> compatibility symlink for /var/run -> /run was introduced.
> 
> References: https://lists.ubuntu.com/archives/apparmor/2017-April/010724.html
> 
> Signed-Off-By: Jamie Strandboge <ja...@canonical.com>

Acked-by: Seth Arnold <seth.arn...@canonical.com>

.. with one concern:

> === modified file 'profiles/apparmor.d/usr.sbin.ntpd'
> --- profiles/apparmor.d/usr.sbin.ntpd 2016-11-14 23:41:53 +
> +++ profiles/apparmor.d/usr.sbin.ntpd 2017-09-15 13:02:48 +
> @@ -50,15 +50,15 @@
>/var/lib/ntp/etc/* r,
>/var/lib/ntp/ntp.drift rw,
>/var/lib/ntp/ntp.drift.TEMP rw,
> -  /var/lib/ntp/{,var/}run/ntp/ntpd.pid w,
> +  /var/lib/ntp/run/ntp/ntpd.pid w,


With a path this ugly and ntpd's long history of moving these files around
all the time, I think we shouldn't commit this change.

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

Re: [apparmor] [PATCH] update nameservice abstraction for system stub resolver

[Seth Arnold]

On Fri, Sep 15, 2017 at 07:58:44AM -0500, Jamie Strandboge wrote:
> 
> Subject says it all. Note, this is using /{,var/}run/... since everything else
> in the nameservice abstraction still is. I'll send a follow-up patch to remove
> all of this once and for all.
> 
> Signed-Off-By: Jamie Strandboge <ja...@canonical.com>

Acked-by: Seth Arnold <seth.arn...@canonical.com>

Thanks

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

> Author: Jamie Strandboge <ja...@canonical.com>
> Description: allow access to stub resolver configuration
> 
> Index: apparmor-2.11.0/profiles/apparmor.d/abstractions/nameservice
> ===
> --- apparmor-2.11.0.orig/profiles/apparmor.d/abstractions/nameservice
> +++ apparmor-2.11.0/profiles/apparmor.d/abstractions/nameservice
> @@ -37,6 +37,7 @@
># a symlink to /{,var/}run/(whatever program is managing it)/resolv.conf.
>
> /{,var/}run/{resolvconf,NetworkManager,systemd/resolve,connman}/resolv.conf r,
>/etc/resolvconf/run/resolv.conf r,
> +  /{,var/}run/systemd/resolve/stub-resolv.conf r,
>  
>/etc/samba/lmhosts  r,
>/etc/services   r,





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] [patch] merge updated traceroute profile into 2.10 and 2.9

[Seth Arnold]

On Tue, Sep 12, 2017 at 06:03:24PM +0200, Christian Boltz wrote:
> Hello,
> 
> the updated traceroute profile (especially the /proc/sys/net/ipv4/... 
> rule) made it only into 2.11 and trunk, but it's also needed in 2.10.x 
> which is used in openSUSE Leap 42.x.
> 
> I propose to apply this patch to the 2.10 and 2.9 branch.

Acked-by: Seth Arnold <seth.arn...@canonical.com>

Thanks

> 
> References: https://bugzilla.opensuse.org/show_bug.cgi?id=1057900
> 
> 
> 
> revno: 3690 [merge]
> committer: Steve Beattie <sbeat...@ubuntu.com>
> branch nick: apparmor
> timestamp: Wed 2017-08-09 08:57:36 -0700
> message:
>   traceroute profile: support TCP SYN for probes, quite net_admin request
>   
>   Merge from Vincas Dargis, approved by intrigeri.
>   fix traceroute denies in tcp mode
>   
>   Acked-by: Steve Beattie <st...@nxnw.org>
> 
> 
> 
> === modified file 'profiles/apparmor.d/usr.sbin.traceroute'
> --- profiles/apparmor.d/usr.sbin.traceroute 2016-09-29 22:07:26 +
> +++ profiles/apparmor.d/usr.sbin.traceroute 2017-07-03 16:44:14 +
> @@ -15,6 +15,7 @@
>#include 
>#include 
>  
> +  deny capability net_admin, # noisy setsockopt() calls
>capability net_raw,
>  
>network inet raw,
> @@ -23,6 +24,7 @@
>/usr/sbin/traceroute mrix,
>/usr/bin/traceroute.db mrix,
>@{PROC}/net/route r,
> +  @{PROC}/sys/net/ipv4/
> {tcp_ecn,tcp_sack,tcp_timestamps,tcp_window_scaling} r,
>  
># Site-specific additions and overrides. See local/README for details.
>#include 
> 
> 


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] AppArmor and kernel capabilities

[Seth Arnold]

Hello,

On Tue, Sep 12, 2017 at 07:04:06PM +0200, linux maillist wrote:
> I creates a profile for gpg and that profile requested now the
> capability dac_override.
> 
> This raises some questions to me. First, does dac_override honor the
> folder permission rules within the profile? For example, if there is a
> rule "/foo/** r," does dac_override this rule?
> 
> If dac_override still honors the folder rules, what then is the point to
> ask for that capability?
> 
> Lastly, why is that capability requested at all?

Here's the text from capabilities(7):

   CAP_DAC_OVERRIDE
  Bypass file read, write, and execute permission
  checks.  (DAC is an abbreviation of "discretionary
  access control".)

   CAP_DAC_READ_SEARCH
  * Bypass file read permission checks and directory
read and execute permission checks;
  * Invoke open_by_handle_at(2).

So gpg was run as root and tried to read, write, or execute, a file
(or write to a directory) that it did not have access to via the usual
Unix permissions. It was able to operate on the file because it was run
as root and had CAP_DAC_OVERRIDE in its effective permissions.

Now the sad news -- there's no easy way to see what operation was
requested. At the point when the kernel asks AppArmor if this capability
should be allowed we don't have any context on what the operation is, so
we can't report anything better. auditd has an option to log syscalls --
which can be enabled for usual dmesg logs via
/sys/modules/apparmor/parameters/logsyscall -- but it will tell you the
values of the pointers given to the system call rather than the paths that
were used.

So your best bet to figure out why this value is needed is to load
a version of the profile without the capability and either (a) hope
gpg reports a good error message when it gets permission denied or (b)
use strace to find out what it was doing when it gets the error. strace
modifies so much of the execution environment that it would be my last
resort method.

> Normally AppArmor complains if r/w to a certain file/folder is needed.
> But, here a capability was requested.
> Requesting dac_override does not give any hint, what file or folder is
> required to access...

In the long run I think it should be possible to use the kernel's
perf facility to log _some_ kind of details on-demand when profiling
an application. It probably wouldn't be something you'd want to have
running all the time but it feels like this should be possible.

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

Re: [apparmor] [PATCH] apparmor: Remove is_deleted()

[Seth Arnold]

On Thu, Sep 07, 2017 at 02:33:58PM -0500, Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues <rgold...@suse.com>
> 
> is_deleted() function is no longer in use and can be safely removed.
> 
> Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com>

Acked-by: Seth Arnold <seth.arn...@canonical.com>

Thanks

> --- 
> diff --git a/security/apparmor/file.c b/security/apparmor/file.c
> index 3382518b87fa..242cd5c09761 100644
> --- a/security/apparmor/file.c
> +++ b/security/apparmor/file.c
> @@ -152,19 +152,6 @@ int aa_audit_file(struct aa_profile *profile, struct 
> aa_perms *perms,
>   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: %1 if deleted else %0
> - */
> -static inline bool is_deleted(struct dentry *dentry)
> -{
> - if (d_unlinked(dentry) && d_backing_inode(dentry)->i_nlink == 0)
> - return 1;
> - return 0;
> -}
> -
>  static int path_name(const char *op, struct aa_label *label,
>const struct path *path, int flags, char *buffer,
>const char **name, struct path_cond *cond, u32 request)


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] [PATCH] regression test: update query label tests to reflect, fixed xpass cases

[Seth Arnold]

On Wed, Sep 06, 2017 at 01:10:49PM -0700, John Johansen wrote:
> newer versions of apparmor that support multi-transaction have this xpass 
> case fixed
> 
> Signed-off-by: John Johansen <john.johan...@canonical.com>

Nice :)

Acked-by: Seth Arnold <seth.arn...@canonical.com>

Thanks

> ---
>  tests/regression/apparmor/query_label.sh | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/regression/apparmor/query_label.sh 
> b/tests/regression/apparmor/query_label.sh
> index e9028f1..44e1e8a 100755
> --- a/tests/regression/apparmor/query_label.sh
> +++ b/tests/regression/apparmor/query_label.sh
> @@ -213,8 +213,13 @@ querytest "QUERY dbus (svc receive)" fail $dbus_svc_query
>  genqueryprofile "file,"
>  expect allow
>  perms file 
> exec,write,read,append,create,delete,setattr,getattr,chmod,chown,link,linksubset,lock,exec_mmap
> -querytest "QUERY file (all base perms #1)" xpass /anything
> -querytest "QUERY file (all base perms #2)" xpass /everything
> +if [ "$(kernel_features query/label/multi_transaction)" == "true" ] ; then
> +querytest "QUERY file (all base perms #1)" pass /anything
> +querytest "QUERY file (all base perms #2)" pass /everything
> +else
> +querytest "QUERY file (all base perms #1)" xpass /anything
> +querytest "QUERY file (all base perms #2)" xpass /everything
> +fi
>  
>  genqueryprofile "/etc/passwd r,"
>  expect allow


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] [PATCH] regression test: conditionaly run pivot_root domain, transitions

[Seth Arnold]

On Wed, Sep 06, 2017 at 01:09:05PM -0700, John Johansen wrote:
> Update the tests to test whether the kernel and parser support domain
> transitions on pivot_root.
> 
> Signed-off-by: John Johansen <john.johan...@canonical.com>

Acked-by: Seth Arnold <seth.arn...@canonical.com>

Thanks

> ---
>  tests/regression/apparmor/pivot_root.sh | 68 
> ++---
>  tests/regression/apparmor/prologue.inc  | 24 
>  2 files changed, 62 insertions(+), 30 deletions(-)
> 
> diff --git a/tests/regression/apparmor/pivot_root.sh 
> b/tests/regression/apparmor/pivot_root.sh
> index b68f6cf..0e13a0a 100755
> --- a/tests/regression/apparmor/pivot_root.sh
> +++ b/tests/regression/apparmor/pivot_root.sh
> @@ -155,34 +155,42 @@ do_test "bad put_old, new_root" fail "$put_old" 
> "$new_root" "$test"
>  genprofile $cur $cap "pivot_root:oldroot=$put_old $bad"
>  do_test "put_old, bad new_root" fail "$put_old" "$new_root" "$test"
>  
> -# Give sufficient perms and perform a profile transition
> -genprofile $cap "pivot_root:-> $new_prof" -- image=$new_prof $cur
> -do_test "transition" pass "$put_old" "$new_root" "$new_prof"
> +if [ "$(kernel_features_istrue namespaces/pivot_root)" != "true" ] ; then
> +echo "   kernel does not support pivot_root domain transitions skipping 
> tests ..."
> +elif [ "$(parser_supports 'pivot_root -> foo,')"  != "true" ] ; then
> +#pivot_root domain transitions not supported
> +echo "   parser does not support pivot root domain transitions skipping 
> tests ..."
> +else
> +# Give sufficient perms and perform a profile transition
> +genprofile $cap "pivot_root:-> $new_prof" -- image=$new_prof $cur
> +do_test "transition" pass "$put_old" "$new_root" "$new_prof"
> +
> +# Ensure failure when the the new profile can't read 
> /proc//attr/current
> +genprofile $cap "pivot_root:-> $new_prof" -- image=$new_prof
> +do_test "transition, no perms" fail "$put_old" "$new_root" "$new_prof"
> +
> +# Ensure failure when the new profile doesn't exist
> +genprofile $cap "pivot_root:-> $bad" -- image=$new_prof $cur
> +do_test "bad transition" fail "$put_old" "$new_root" "$new_prof"
> +
> +# Ensure the test binary is accurately doing post pivot_root profile 
> verification
> +genprofile $cap "pivot_root:-> $new_prof" -- image=$new_prof $cur
> +do_test "bad transition comparison" fail "$put_old" "$new_root" "$test"
> +
> +# Give sufficient perms with new_root and a transition
> +genprofile $cap "pivot_root:$new_root -> $new_prof" -- image=$new_prof 
> $cur
> +do_test "new_root, transition" pass "$put_old" "$new_root" "$new_prof"
> +
> +# Ensure failure when the new profile doesn't exist and new_root is 
> specified
> +genprofile $cap "pivot_root:$new_root -> $bad" -- image=$new_prof $cur
> +do_test "new_root, bad transition" fail "$put_old" "$new_root" 
> "$new_prof"
> +
> +# Give sufficient perms with new_root, put_old, and a transition
> +genprofile $cap "pivot_root:oldroot=$put_old $new_root -> $new_prof" -- 
> image=$new_prof $cur
> +do_test "put_old, new_root, transition" pass "$put_old" "$new_root" 
> "$new_prof"
> +
> +# Ensure failure when the new profile doesn't exist and new_root and 
> put_old are specified
> +genprofile $cap "pivot_root:oldroot=$put_old $new_root -> $bad" -- 
> image=$new_prof $cur
> +do_test "put_old, new_root, bad transition" fail "$put_old" "$new_root" 
> "$new_prof"
>  
> -# Ensure failure when the the new profile can't read /proc//attr/current
> -genprofile $cap "pivot_root:-> $new_prof" -- image=$new_prof
> -do_test "transition, no perms" fail "$put_old" "$new_root" "$new_prof"
> -
> -# Ensure failure when the new profile doesn't exist
> -genprofile $cap "pivot_root:-> $bad" -- image=$new_prof $cur
> -do_test "bad transition" fail "$put_old" "$new_root" "$new_prof"
> -
> -# Ensure the test binary is accurately doing post pivot_root profile 
> verification
> -genprofi

Re: [apparmor] [profile] xfce4-dict: complain mode: /usr/bin/enchant, /usr/bin/enchant-lsmod and access to Specific Resources.

[Seth Arnold]

Hello Daniel,

On Wed, Aug 30, 2017 at 10:04:45PM +0200, daniel curtis wrote:
> Hello
> 
> On Wed, Aug 2. I've asked a question about xfce4-dict - a client program,
> for example, to query different dictionaries via internet connections etc.
> And I've had a problem with some aa-status(8) command result. Namely with
> "/usr/bin/enchant" and "/usr/bin/enchant-lsmod".
> 
> So, during creating a profile, aa-genprof(8) utility created a rules for
> both above files with a "rix" mode access. It led to a "strange" result for
> aa-status(8) command:
> 
> 2 profiles are in complain mode.
> /usr/bin/xfce4-dict//null-/usr/bin/enchant
> /usr/bin/xfce4-dict//null-/usr/bin/enchant-lsmod
> 
> There was also some other issues. But I would like to write about above
> things, because it seems they are solved. As I said, aa-genprof(8) utility
> created rules with "rix" mode, right? I decided to try something. A small
> change, that worked!
> 
> ✗ /usr/bin/enchant rix,
> ✗ /usr/bin/enchant-lsmod rix,
> ✓ /usr/bin/enchant mrix,
> ✓ /usr/bin/enchant-lsmod mrix,
> 
> After this small change "rix" > "mrix", aa-status(8) command no longer
> shows "enchant" in a Complain mode and xfce4-dict is Enforced and works OK.
> It makes me happy, because I want every application, which is connecting to
> the internet had an AppArmor profile. (At last, I achieved this on one of
> my testing machine.)

I believe you've seen here a series of interesting coincidences rather
than cause and effect.

The ..//null-.. profiles are created by the kernel when a process in a
complain-mode profile executes another program.

I believe the ..//null-.. profiles are cleaned up by aa-genprof and
probably aa-logprof when you provide a concrete answer for ix/cx/px/ux for
the executable in question. (At least they used to. I hope they still do.)

If you created the complain-mode profile yourself, then you'll have to
clean them up with:

echo "/usr/bin/xfce4-dict//null-/usr/bin/enchant-lsmod {}" | apparmor_parser 
--remove


The 'm' permission is required on executables after this change to the
Linux kernel:

commit 9f834ec18defc369d73ccf9e87a2790bfa05bf46
Author: Linus Torvalds 
Date:   Mon Aug 22 16:41:46 2016 -0700

binfmt_elf: switch to new creds when switching to new mm


The auto-generated profiles and the creds change that now requires 'm'
permissions are unrelated.

If aa-genprof and tools are still marking the executable with only
'rix' then we can probably improve the user experience by marking them
with 'm' also, perhaps if they are actually ELF or a.out or whatever (not
scripts).

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

Re: [apparmor] [profile] Firefox: put /bin/ps in a Child Profile for an extra security?

[Seth Arnold]

Hi Daniel,

On Wed, Aug 30, 2017 at 09:40:32PM +0200, daniel curtis wrote:
> ✓ /bin/ps Cx,

> profile /bin/ps {
> 
> [NEEDED RULES]
> 
> }
> 
> }
> 
> The "/bin/ps" child profile structure is straightforward, but I'm wondering
> whether is it OK? I'm asking just to be one hundred percent sure. Nothing

Yes, this is good. Be sure to #include  in this child
profile, and the rest should be easy enough. Your suggested updates to
more modern rules with variables makes sense too.

> What do you think about such idea - an idea of creating a Child Profile for
> "/bin/ps" utility? Could it make a Firefox more secure? (My opinion, mainly
> refers to the comment: "Ideally these would use a child profile." See
> above.)

ps is old enough that I strongly doubt it can be negatively influenced by
malicious processes, so it may not actually have any real impact on system
security. However, the principle of reducing privileges available to
processes on the system is solid, and if nothing else it's good practice.

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

Re: [apparmor] [patch] Add network 'smc' keyword in NetworkRule and apparmor.d manpage

[Seth Arnold]

On Tue, Aug 29, 2017 at 10:55:07PM +0200, Christian Boltz wrote:
> Hello,
> 
> 'smc' seems to be new in kernel 4.12.
> 
> 
> I propose this patch for trunk, 2.11 and 2.10.

Acked-by: Seth Arnold <seth.arn...@canonical.com>

Thanks

> Note that the 2.10 apparmor.d manpage also misses the 'kcm' keyword, so
> I'll also add it there.
> 
> 2.9 doesn't have NetworkRule, and it's unlikely that someone expects the
> manpage on that old branch to match the latest kernel ;-)
> 
> 
> [ 04-network-smc.diff ]
> 
> === modified file ./utils/apparmor/rule/network.py
> --- utils/apparmor/rule/network.py  2016-10-01 20:33:23.421684000 +0200
> +++ utils/apparmor/rule/network.py  2017-08-29 22:21:17.809764695 +0200
> @@ -27,7 +27,7 @@
>  network_domain_keywords   = [ 'unspec', 'unix', 'inet', 'ax25', 'ipx', 
> 'appletalk', 'netrom', 'bridge', 'atmpvc', 'x25', 'inet6',
>'rose', 'netbeui', 'security', 'key', 
> 'netlink', 'packet', 'ash', 'econet', 'atmsvc', 'rds', 'sna',
>'irda', 'pppox', 'wanpipe', 'llc', 'can', 
> 'tipc', 'bluetooth', 'iucv', 'rxrpc', 'isdn', 'phonet',
> -  'ieee802154', 'caif', 'alg', 'nfc', 'vsock', 
> 'mpls', 'ib', 'kcm' ]
> +  'ieee802154', 'caif', 'alg', 'nfc', 'vsock', 
> 'mpls', 'ib', 'kcm', 'smc' ]
>  
>  network_type_keywords = ['stream', 'dgram', 'seqpacket', 'rdm', 'raw', 
> 'packet']
>  network_protocol_keywords = ['tcp', 'udp', 'icmp']
> --- parser/apparmor.d.pod   2017-07-16 21:43:30.710865535 +0200
> +++ parser/apparmor.d.pod   2017-08-29 22:21:42.489684725 +0200
> @@ -111,7 +111,7 @@
>  
>  B = [ I ] 'network' [ I ] [ I | 
> I ]
>  
> -B = ( 'inet' | 'ax25' | 'ipx' | 'appletalk' | 'netrom' | 'bridge' | 
> 'atmpvc' | 'x25' | 'inet6' | 'rose' | 'netbeui' | 'security' | 'key' | 
> 'packet' | 'ash' | 'econet' | 'atmsvc' | 'sna' | 'irda' | 'pppox' | 'wanpipe' 
> | 'bluetooth' | 'netlink' | 'unix' | 'rds' | 'llc' | 'can' | 'tipc' | 'iucv' 
> | 'rxrpc' | 'isdn' | 'phonet' | 'ieee802154' | 'caif' | 'alg' | 'nfc' | 
> 'vsock' | 'mpls' | 'ib' | 'kcm' ) ','
> +B = ( 'inet' | 'ax25' | 'ipx' | 'appletalk' | 'netrom' | 'bridge' | 
> 'atmpvc' | 'x25' | 'inet6' | 'rose' | 'netbeui' | 'security' | 'key' | 
> 'packet' | 'ash' | 'econet' | 'atmsvc' | 'sna' | 'irda' | 'pppox' | 'wanpipe' 
> | 'bluetooth' | 'netlink' | 'unix' | 'rds' | 'llc' | 'can' | 'tipc' | 'iucv' 
> | 'rxrpc' | 'isdn' | 'phonet' | 'ieee802154' | 'caif' | 'alg' | 'nfc' | 
> 'vsock' | 'mpls' | 'ib' | 'kcm' | 'smc' ) ','
>  
>  B = ( 'stream' | 'dgram' | 'seqpacket' |  'rdm' | 'raw' | 'packet' )
>  
> 


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] [patch] Samba profile updates for ActiveDirectory / Kerberos

[Seth Arnold]

On Tue, Aug 22, 2017 at 11:14:59PM +0200, Christian Boltz wrote:
> > Is the sss/ms/initgroups change intentional? 
> 
> Yes, this is intentional - I did the profile updates (on an INVIS server) 
> myself ;-)
> 
> > Should that go into abstractions/nameservice instead?
> 
> What about "maybe"? ;-)  This was the first time I've seen access to 
> sss/ms/initgroups. I don't really know what it does, so I prefered to 
> only allow it in the smbd profile.
> 
> If you think it makes sense for abstractions/nameservice, I can change 
> the patch ;-)

This would be wonderful, thanks. The 'initgroups' interface exists to
support the getgrouplist(3) function as described by nsswitch.conf(5). So
if a site is using sss then probably more than just Samba will need this.

Acked-by: Seth Arnold <seth.arn...@canonical.com> for the 'old' patch
minus the initgroups, and the offered new patch of the initgroups in
abstractions/nameservice. :)

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