Re: [apparmor] Unique audit record type ranges for individual LSMs

[Steve Grubb]

On Monday, December 11, 2017 3:56:35 PM EST Casey Schaufler wrote:
> On 12/11/2017 7:44 AM, Steve Grubb wrote:
> > On Wednesday, December 6, 2017 1:47:43 PM EST Casey Schaufler wrote:
> >>> While it will be potentially painful to switch, the AppArmor project is
> >>> considering to use a unique range in order for audit-userspace to
> >>> support AppArmor audit records. IMHO, SMACK would be free to continue
> >>> using 1400-1499 as long as they don't need audit-userspace support and
> >>> SELinux would continue using 1400-1499.
> >> 
> >> Aside from the comment that says 1400-1499 are for SELinux, and the three
> >> events (1400-1402) that are SELinux specific, the events really are
> >> general. Why not add the AppArmor specifics to the 1400 range? Give them
> >> a generic sounding name and you'll achieve consistency. Change the
> >> comment to say "Security Module use" instead of "SELinux use".
> > 
> > I really don't know what the status is for user space support on the other
> > LSMs. I couldn't tell you if the searching/reporting are broken or working
> > just fine.
> 
> Understood. And it's only going to get worse with module stacking.
> 
> > Additionally, there is auditctl which has very selinux specific field
> > options to audit on a variety of pieces of the labels. Does this make
> > sense for other LSMs? Do other LSMs have different needs? I really have
> > no idea.
> 
> Three of the record types are SELinux specific. Nine are netlabel, which are
> not SELinux specific, or at least shouldn't be. Three are about setting
> state. We could have different audit records for Smack setting netlabel
> maps from the one SELinux uses, but that seems wrong.

I'd also be open to defining a block for generic messages and a couple small 
blocks (10 or so) for LSM specific events. By defining a new event type, it 
allows you to express the information specific to a LSM without having to 
conform to all other LSMs.


> > But one thing for sure...if we combine them all, I expect patches are
> > needed for user space. By separating them out by event number or some
> > identifier like lsm=, then we can have lsm specific fixups if necessary.
> 
> It seems to me that adding proper support for security modules
> other than SELinux is going to be a project. That's true regardless
> of how the messages are numbered and whether or not we have generic
> messages.

First step would be to either add lsm= to all audit events from LSM's or 
define blocks each will use. It might be best to add the lsm= field if we have 
standard events across all LSMs. Then at some future date we can start using 
that to do something smart with the extra info. But knowing which LSM emitted 
the event is important to cleaning this up.

Also...auditctl issue seems to be glossed over. Do other LSMs have auditing 
needs related to rules + labeling the LSM may do?

-Steve


-- 
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] RFC: Policy versioning

[John Johansen]

On 12/11/2017 01:26 PM, Jamie Strandboge wrote:
> I'm going to reply to this one separately from the other parts of your
> response.
> 
> On Mon, 2017-12-11 at 10:33 -0800, John Johansen wrote:
>> On 12/11/2017 09:30 AM, Jamie Strandboge wrote:
>>> On Sun, 2017-12-10 at 03:05 -0800, John Johansen wrote:
 4. Limit distros ability to compile policy to the current kernels
feature abi

   Along with this Distros will no longer be able to set a default
   policy compile that will use the current kernel's abi. This
 will
 not
   even be supported at the distro level as the project can not
 afford
   to break the feature abi of current policy for kernel
 developers.

   To address this a new tool will be added to extract the kernel
   features abi, and tooling will be updated to allow users update
 a
   profiles abi and thus begin development on newer versions.
 Basically
   a per user opt in only approach.
>>>
>>> I'm a little confused by this. Why would it be bad for a distro to
>>> compile policy to a *versioned* policy cache for the current
>>> feature
>>> abi? I understand wanting to obsolete *un*versioned policy caches.
>>>
>>
>> Because this is effectively equivalent to what got us in trouble
>> and led to the revert. Whether we like it or not, the ability to
>> to do this system wide, and at the distro level has to go away
>> to safe guard our ability to work with upstream.
>>
>> This is going to have to be a user only per profile opt-in. Yes it
>> sucks from the distro/profile developer pov, but at this point we
>> have to be extra paranoid about it.
> 
> Maybe I'm dense, but the proposal is pretty broad and seems to be
> addressing several related issues and I'm finding it difficult to
> connect the dots.
> 

Yes it is pretty broad, with that said most of the components are
needed for policy versioning or dealing with the current upstream
feature issue which was the final impetuous to move to policy
versioning.

It evolved to be something more than just policy versioning to be a
single plan to address all the main policy problems. Parts of the
design evolved/changed as new pieces of the puzzle were brought into
play.

If we just wanted to address the current crisis around kernel
features. We would cap policy at the 4.14 abi and never add a new
feature, but for some reason I don't think that would make people
happy.

Or at the other end if we just wanted to deal with the problem of
policy being written for different versions (again another way we can
look at the kernel feature issue that got us a revert in 4.14), we
could just go to monolithic policy, and only load it it exactly
matched the kernel features set. No packaging of policy with
applications, only one policy on a system at a time. But again I don't
think people would be happy with that

Policy versioning, policy hashing, conditional includes, new
variables, better conditionals, and removing the distros ability to
set the policy abi to the current kernel abi all work in concert to
solve the current kernel problem without resorting to one of the two
above extreme solutions.

At the same time that also provide us the opportunity to address some
of the other issues we have had with policy.


> I suggest identifying use cases and then describing how the proposal is
> meant to address these. I also suggest putting the proposal up

Hrmmm, I thought I was pretty explicit and up front about what this
was meant to address. I covered 7 problems that we currently have and
then did provide a few examples through out where I thought it was
necessary.

The large one is of course address the current problem of upstreaming
features without breaking current policy, which includes distributed
packaging of policy.

> somewhere-- and then people can comment and the document can grow.
> Perhaps there is something on gitlab to help with this? (otherwise just
> the wiki would work).
> 

I don't see how gitlab is going to help, we need an open discussion
and we need it yesterday (well 6 months ago but ..). We can certainly
put the doc on git lab or the wiki but moving the editing to there
effectively hides the discussion more than having it on an open
mailing list.


> I'm sure I've missed some use cases, but here are the ones I'm thinking
> about. Specifics like "the parser should do this, the apparmor package
> in the distro that, the policy in the distro should do something, the
> kernel package something else, etc" would be appreciated.
> 

certainly guide lines that can be worked on.

> = Supporting upstream kernel developers =
> Consider the upstream (non-AppArmor) kernel developer running OpenSUSE
> who runs an otherwise stable OpenSUSE system with AppArmor enabled but
> compiles her kernels based on local branches to Linus' tree. How should
> the system be configured so the the developer can pull in Linus' tree
> which has new AppArmor features without breaking the system?
> 

Ideally 

Re: [apparmor] RFC: Policy versioning

[Jamie Strandboge]

On Mon, 2017-12-11 at 10:33 -0800, John Johansen wrote:
> On 12/11/2017 09:30 AM, Jamie Strandboge wrote:
> > On Sun, 2017-12-10 at 03:05 -0800, John Johansen wrote:
> > > 
> > > 3. Standardize policy config dir and files
> > > 
> > >   Problem 5 is addressed by standardizing a config directory and
> > > file
> > >   layout. New locations must be added to the config dir to inform
> > >   apparmor of new policy locations and how they should be
> > > handled.
> > > 
> > >   The parser config has proven insufficient so Ubuntu has been
> > >   modifying the initscript to manage this which is not a solution
> > > that
> > >   can be shared across distros, nor does it provide a solution
> > > that
> > >   works with other parts of apparmor like the tools.
> > > 
> > >   Instead we have a directory in which each new location can drop
> > > its
> > >   own config, allowing to set its policy and include location
> > > cache,
> > >   and even compiler options if so desired.
> > > 
> > 
> > This makes a lot of sense. Are you envisioning apparmor would
> > handle
> > all policy loads? For example, today snapd modifies policy in it
> > own
> > area in /var/lib/snapd, outputs cache in /var/cache/apparmor and
> > uses
> > its own options. Setting the cache and options is clear from a
> > snapd-
> > perspective, what does setting the policy location imply? Or put
> > another way, how does this interact with '5', below?
> > 
> 
> Not necessarily, I fully expect lxd and libvirt to still be
> dynamically
> creating and loading policy. This is merely a way of providing the
> tools and initscripts more information so that, they can reload
> those policies if so directed but also can say these are managed
> by lxd.

+1


...

> 
> > > 
> > > 7.2 Supporting unknown rule templates
> > > 
> > >   Instead of wrapping new rule types in conditionals we should
> > > extend
> > >   policy to support rule templates. Rule templates would allow
> > > userspace
> > >   to specify patterns for unknown rule types, so that the parser
> > > or
> > >   tools can parse the rule, and ignore it.
> > > 
> > >   The Rule templates could then be dropped into the abstractions,
> > >   as new features are added providing an easy way to update older
> > >   userspaces to ignore new rule types.
> > > 
> > >   eg.
> > > if !supports(key) {
> > >   template key='key\w.*,' # yes its overly
> > > simple
> > > }
> > > 
> > >   Such rule templates wouldn't completely remove the need for
> > > being
> > >   able to wrap some policy in conditionals, but it done properly
> > > it
> > >   should be able to support most cases.
> > > 
> > 
> > IMO this would make auditing policy a bit harder since you have to
> > either do a preprocess run for auditing (not necessarily a bad
> > thing). 
> > 
> 
> Any worse than wrapping them in conditionals? 

Well, I think I misunderstood what you were proposing. See below

...
> > IIUC, the rule templates put the unix rules somewhere else, outside
> > of
> > the context of the need for the rule.
> > 
> 
> No, no. They are just a way to expand a parsers ability to parse an
> unknown rule just enough so it can skip it and keep processing the
> rules it does know about.
> 
> Think of it as being able to drop a set of rule templates into an
> older version apparmor, so it will support newer policy (yes
> ignoring)
> without doing a full SRU, which will still just result in the rule
> being dropped unless they are using a newer kernel as well.
> 
> The goal is to make it so you won't have to change your policy or
> have multiple versions of policy just because your application is
> running on systems with different versions of apparmor.

This is clear to me now. The policy author can write with the latest
features enabled and the policy packager can put in the templates to
handle new stuff. So long as those templates had clear comments, a
policy auditor focuses on the policy (without conditionals) and would
be able to tell what was available where and how for the exceptional
cases when booting into kernels that don't understand newer policy.

Thinking about this, upstream apparmor could write these templates
alongside the kernel patches introducing the new features so that
distro packagers can just pull these templates in for the new (eg,
upstream) features and SRU (whatever that process is for the particular
distro) those changes (in Ubuntu for example, it might make sense for
the kernel deb to ship these).

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

signature.asc
Description: This is a digitally signed message part
-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: [apparmor] RFC: Policy versioning

[Jamie Strandboge]

I'm going to reply to this one separately from the other parts of your
response.

On Mon, 2017-12-11 at 10:33 -0800, John Johansen wrote:
> On 12/11/2017 09:30 AM, Jamie Strandboge wrote:
> > On Sun, 2017-12-10 at 03:05 -0800, John Johansen wrote:
> > > 4. Limit distros ability to compile policy to the current kernels
> > >feature abi
> > > 
> > >   Along with this Distros will no longer be able to set a default
> > >   policy compile that will use the current kernel's abi. This
> > > will
> > > not
> > >   even be supported at the distro level as the project can not
> > > afford
> > >   to break the feature abi of current policy for kernel
> > > developers.
> > > 
> > >   To address this a new tool will be added to extract the kernel
> > >   features abi, and tooling will be updated to allow users update
> > > a
> > >   profiles abi and thus begin development on newer versions.
> > > Basically
> > >   a per user opt in only approach.
> > 
> > I'm a little confused by this. Why would it be bad for a distro to
> > compile policy to a *versioned* policy cache for the current
> > feature
> > abi? I understand wanting to obsolete *un*versioned policy caches.
> > 
> 
> Because this is effectively equivalent to what got us in trouble
> and led to the revert. Whether we like it or not, the ability to
> to do this system wide, and at the distro level has to go away
> to safe guard our ability to work with upstream.
> 
> This is going to have to be a user only per profile opt-in. Yes it
> sucks from the distro/profile developer pov, but at this point we
> have to be extra paranoid about it.

Maybe I'm dense, but the proposal is pretty broad and seems to be
addressing several related issues and I'm finding it difficult to
connect the dots.

I suggest identifying use cases and then describing how the proposal is
meant to address these. I also suggest putting the proposal up
somewhere-- and then people can comment and the document can grow.
Perhaps there is something on gitlab to help with this? (otherwise just
the wiki would work).

I'm sure I've missed some use cases, but here are the ones I'm thinking
about. Specifics like "the parser should do this, the apparmor package
in the distro that, the policy in the distro should do something, the
kernel package something else, etc" would be appreciated.

= Supporting upstream kernel developers =
Consider the upstream (non-AppArmor) kernel developer running OpenSUSE
who runs an otherwise stable OpenSUSE system with AppArmor enabled but
compiles her kernels based on local branches to Linus' tree. How should
the system be configured so the the developer can pull in Linus' tree
which has new AppArmor features without breaking the system?

= Ubuntu user testing upstream or bisect kernels =
Consider the Ubuntu user with a kernel bug who has been asked to test
various upstream and/or bisected kernels on an otherwise stable Ubuntu
system (these kernels might be substantially older or newer than what
was shipped with the apparmor userspace). How does he run these kernels
without breaking his applications?

= Ubuntu HWE kernels =
Consider the Ubuntu user who tracks the hwe kernels but otherwise has
an stable Ubuntu system (eg, non-updated apparmor userspace). How does
she run these kernels without breaking her applications?

= Distro kernel developer using non-upstream AppArmor kernel features =
Consider the kernel developer that has non-upstream features (eg,
OpenSUSE that pulls back network compat or Solus that pulls from jj's
tree). How does the developer pull in new upstream kernels with new
AppArmor features into the distro so as not to break users of the
development release?

= Distro kernel developer using only upstream AppArmor =
Consider the kernel developer that uses only upstream AppArmor features
(eg, Debian). How does the developer pull in new upstream kernels with
new AppArmor features into the distro so as not to break users of the
development release?

...

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

signature.asc
Description: This is a digitally signed message part
-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: [apparmor] Unique audit record type ranges for individual LSMs

[Casey Schaufler]

On 12/11/2017 7:44 AM, Steve Grubb wrote:
> On Wednesday, December 6, 2017 1:47:43 PM EST Casey Schaufler wrote:
>>> While it will be potentially painful to switch, the AppArmor project is
>>> considering to use a unique range in order for audit-userspace to
>>> support AppArmor audit records. IMHO, SMACK would be free to continue
>>> using 1400-1499 as long as they don't need audit-userspace support and
>>> SELinux would continue using 1400-1499.
>> Aside from the comment that says 1400-1499 are for SELinux, and the three
>> events (1400-1402) that are SELinux specific, the events really are general.
>> Why not add the AppArmor specifics to the 1400 range? Give them a generic
>> sounding name and you'll achieve consistency. Change the comment to say
>> "Security Module use" instead of "SELinux use".
> I really don't know what the status is for user space support on the other 
> LSMs. I couldn't tell you if the searching/reporting are broken or working 
> just fine.

Understood. And it's only going to get worse with module stacking.

> Additionally, there is auditctl which has very selinux specific field options 
> to audit on a variety of pieces of the labels. Does this make sense for other 
> LSMs? Do other LSMs have different needs? I really have no idea.

Three of the record types are SELinux specific. Nine are netlabel, which are
not SELinux specific, or at least shouldn't be. Three are about setting state.
We could have different audit records for Smack setting netlabel maps from the
one SELinux uses, but that seems wrong.

> But one thing for sure...if we combine them all, I expect patches are needed 
> for user space. By separating them out by event number or some identifier 
> like 
> lsm=, then we can have lsm specific fixups if necessary.

It seems to me that adding proper support for security modules
other than SELinux is going to be a project. That's true regardless
of how the messages are numbered and whether or not we have generic
messages.

> -Steve
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


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

Re: [apparmor] RFC: Policy versioning

[John Johansen]

>>
>>   #
>>   # foo rules
>>   #
>>   /usr/bin/foo ix,
>>   # needed by foo for ...
>>   /etc/blah r,
>>   # foo connects to this for ...
>>   unix ...,
>>
>>   #
>>   # bar rules
>>   #
>>   /usr/bin/bar ix,
>>   # bar connects to this for ...
>>   unix ...,
>>
>> IIUC, the rule templates put the unix rules somewhere else, outside of
>> the context of the need for the rule.
>>
> 
> No, no. They are just a way to expand a parsers ability to parse an
> unknown rule just enough so it can skip it and keep processing the
> rules it does know about.
> 
> Think of it as being able to drop a set of rule templates into an
> older version apparmor, so it will support newer policy (yes ignoring)
> without doing a full SRU, which will still just result in the rule
> being dropped unless they are using a newer kernel as well.
> 
> The goal is to make it so you won't have to change your policy or
> have multiple versions of policy just because your application is
> running on systems with different versions of apparmor.
> 
> 

Another way of putting it, is they are NOT policy rules, but a
way of extending the parser but updating dropping a text file
in.


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

Re: [apparmor] RFC: Policy versioning

[John Johansen]

On 12/11/2017 09:30 AM, Jamie Strandboge wrote:
> On Sun, 2017-12-10 at 03:05 -0800, John Johansen wrote:
>> Currently we have a few problems with policy that must be addressed
>>
> 
> Thanks for this writeup! I'm still processing a lot of it, but there
> were a couple of things I wanted to comment on right away...
> 
>>
>> I. Proposed Solution
> 
> ...
> 
>> 2. Support multiple policy caches
>>
>>   To address problems 3-4 we extend the poliy cache so that we retain
>>   a compiled policy per kernel installed. When a new kernel is
>>   installed we build a new policy cache for it.
> 
> Big +1 on supporting multiple policy caches. It does seem like we would
> want to still compile (versioned!) policy on boot if the policy cache
> does not yet exist to gracefully handle situations where the kernel
> packaging didn't yet do it, no? This would avoid a flag day for
> everyone to adjust their kernel install packaging scripts at the same
> time.
> 
> I'd have to think through the implications for snappy here since the
> kernel is shipped as a snap since nothing is (currently) executed upon
> install. It is possible to run install hooks/etc on this, so the
> proposal is not on its face problematic.
>  

So I am not opposed to having the ability compile policy later on.
It can work but its somewhat racey wrt getting policy in place for
other system services (unless there are modification to ensure
proper depedency), and it doesn't work at all for early services,
nor does it work with the early load we can get with systemd.

If we find our selves in the position where we are compiling policy
on boot, then it is entirely possible a reboot will result in
different confinement, which is not a good or reliable experience
for users.

So as much as possible we want the policy to be compiled before
boot.

>> 3. Standardize policy config dir and files
>>
>>   Problem 5 is addressed by standardizing a config directory and file
>>   layout. New locations must be added to the config dir to inform
>>   apparmor of new policy locations and how they should be handled.
>>
>>   The parser config has proven insufficient so Ubuntu has been
>>   modifying the initscript to manage this which is not a solution
>> that
>>   can be shared across distros, nor does it provide a solution that
>>   works with other parts of apparmor like the tools.
>>
>>   Instead we have a directory in which each new location can drop its
>>   own config, allowing to set its policy and include location cache,
>>   and even compiler options if so desired.
>>
> This makes a lot of sense. Are you envisioning apparmor would handle
> all policy loads? For example, today snapd modifies policy in it own
> area in /var/lib/snapd, outputs cache in /var/cache/apparmor and uses
> its own options. Setting the cache and options is clear from a snapd-
> perspective, what does setting the policy location imply? Or put
> another way, how does this interact with '5', below?
> 

Not necessarily, I fully expect lxd and libvirt to still be dynamically
creating and loading policy. This is merely a way of providing the
tools and initscripts more information so that, they can reload
those policies if so directed but also can say these are managed
by lxd.


>>
>> 4. Limit distros ability to compile policy to the current kernels
>>feature abi
>>
>>   Along with this Distros will no longer be able to set a default
>>   policy compile that will use the current kernel's abi. This will
>> not
>>   even be supported at the distro level as the project can not afford
>>   to break the feature abi of current policy for kernel developers.
>>
>>   To address this a new tool will be added to extract the kernel
>>   features abi, and tooling will be updated to allow users update a
>>   profiles abi and thus begin development on newer versions.
>> Basically
>>   a per user opt in only approach.
> 
> I'm a little confused by this. Why would it be bad for a distro to
> compile policy to a *versioned* policy cache for the current feature
> abi? I understand wanting to obsolete *un*versioned policy caches.
> 

Because this is effectively equivalent to what got us in trouble
and led to the revert. Whether we like it or not, the ability to
to do this system wide, and at the distro level has to go away
to safe guard our ability to work with upstream.

This is going to have to be a user only per profile opt-in. Yes it
sucks from the distro/profile developer pov, but at this point we
have to be extra paranoid about it.


>>
>> 5. Applications managing policy and unknown profiles
>>
>>   The current solution to problem 6 of having unknown policy and
>>   relying on aa-remove-unknown is more problematic. We are going to
>>   have to break existing behavior to fix it.
>>
>>   Applications that want to manage their own policy are going to have
>>   to register to do so. This will require a new API for applications
>>   to use which could just be a thin layer on top of the policy config
>>   file.
> 
> 

Re: [apparmor] Unique audit record type ranges for individual LSMs

[Steve Grubb]

On Wednesday, December 6, 2017 12:51:26 PM EST Tyler Hicks wrote:
> Hello - The AppArmor project would like for AppArmor audit records to be
> supported by the audit-userspace tools, such as ausearch, but it
> requires some coordination between the linux-security-module and
> linux-audit lists. This was raised as a feature request years ago in
> Ubuntu and more recently in Debian:
> 
>   https://launchpad.net/bugs/1117804
>   https://bugs.debian.org/872726
> 
> The quick summary of the problem at hand is that the audit-userspace
> project requires that each LSM use a unique record type range for audit
> records while the kernel's common_lsm_audit() function uses the same
> record type (1400) for all records. SELinux, AppArmor, and SMACK are all
> using common_lsm_audit() today and, therefore, the 1400-1499 range.
> 
> While it will be potentially painful to switch, the AppArmor project is
> considering to use a unique range in order for audit-userspace to
> support AppArmor audit records. IMHO, SMACK would be free to continue
> using 1400-1499 as long as they don't need audit-userspace support and
> SELinux would continue using 1400-1499.
> 
> Steve Grubb previously told me that he intends 1500-1599 to be used by
> AppArmor:
> 
>   https://www.redhat.com/archives/linux-audit/2014-May/msg00119.html
> 
> 
> John Johansen tells me that AppArmor previously used the 1500-1599 range
> before AppArmor was upstreamed.

Yes, this is what I have:

#define AUDIT_AA1500/* Not upstream yet */
#define AUDIT_APPARMOR_AUDIT1501
#define AUDIT_APPARMOR_ALLOWED  1502
#define AUDIT_APPARMOR_DENIED   1503
#define AUDIT_APPARMOR_HINT 1504
#define AUDIT_APPARMOR_STATUS   1505
#define AUDIT_APPARMOR_ERROR1506


> There's a conflicting comment in the kernel stating that 1500-1599 is to
> by used by kernel LSPP events. As far as I can tell, there were never
> any kernel LSPP events that used the range.

This seems like an erroneous comment in audit.h.


> Steve is the one that added that comment so I think it is a safe range for
> AppArmor to use:
> 
>   https://git.kernel.org/linus/90d526c074ae5db484388da56c399acf892b6c17

I think this commit predates the agreement on the apparmor range and a 
followup assignment in the kernel was never done.


> Considering audit-userspace's stance, does the LSM community agree that
> common_lsm_audit() should be modified to accept an audit record type
> parameter to pass on to audit_log_start()?

This is part of the problem. I get an AVC from selinux like this:

type=AVC msg=audit(1512997597.761:271): avc:  denied  { append } for  pid=1304 
comm="mail" name="dead.letter" dev="nvme0n1p2" ino=17 
scontext=system_u:system_r:fsdaemon_t:s0 
tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file permissive=0

Nowhere in this does it tell me this is from the selinux LSM. So, that means 
it is implicit in the event number. Its important for me to know what LSM sent 
this so that it can be parsed correctly. If every LSM uses the same event 
numbers as selinux, then we probably have parsing problems because they are 
being parsed like selinux events and the wording/reporting probably does not 
make sense.


> If so, does everyone agree that 1500-1599 would be acceptable for
> AppArmor to use?

In the absence of any way to determine what I'm dealing with, separating LSMs 
by event number is best.

Also, I don't get or see any events from these other LSM's. I can't reproduce 
any bugs or verify the correctness of any reports or searches. Not that I 
don't want to support other LSM's, but I need someone else to check it and 
make sure it's doing  the right thing. Patches are welcome.

-Steve

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

Re: [apparmor] Unique audit record type ranges for individual LSMs

[Steve Grubb]

On Wednesday, December 6, 2017 1:47:43 PM EST Casey Schaufler wrote:
> > While it will be potentially painful to switch, the AppArmor project is
> > considering to use a unique range in order for audit-userspace to
> > support AppArmor audit records. IMHO, SMACK would be free to continue
> > using 1400-1499 as long as they don't need audit-userspace support and
> > SELinux would continue using 1400-1499.
> 
> Aside from the comment that says 1400-1499 are for SELinux, and the three
> events (1400-1402) that are SELinux specific, the events really are general.
> Why not add the AppArmor specifics to the 1400 range? Give them a generic
> sounding name and you'll achieve consistency. Change the comment to say
> "Security Module use" instead of "SELinux use".

I really don't know what the status is for user space support on the other 
LSMs. I couldn't tell you if the searching/reporting are broken or working 
just fine.

Additionally, there is auditctl which has very selinux specific field options 
to audit on a variety of pieces of the labels. Does this make sense for other 
LSMs? Do other LSMs have different needs? I really have no idea.

But one thing for sure...if we combine them all, I expect patches are needed 
for user space. By separating them out by event number or some identifier like 
lsm=, then we can have lsm specific fixups if necessary.

-Steve

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

Re: [apparmor] RFC: Policy versioning

[Jamie Strandboge]

On Sun, 2017-12-10 at 03:05 -0800, John Johansen wrote:
> Currently we have a few problems with policy that must be addressed
> 

Thanks for this writeup! I'm still processing a lot of it, but there
were a couple of things I wanted to comment on right away...

> 
> I. Proposed Solution

...

> 2. Support multiple policy caches
> 
>   To address problems 3-4 we extend the poliy cache so that we retain
>   a compiled policy per kernel installed. When a new kernel is
>   installed we build a new policy cache for it.

Big +1 on supporting multiple policy caches. It does seem like we would
want to still compile (versioned!) policy on boot if the policy cache
does not yet exist to gracefully handle situations where the kernel
packaging didn't yet do it, no? This would avoid a flag day for
everyone to adjust their kernel install packaging scripts at the same
time.

I'd have to think through the implications for snappy here since the
kernel is shipped as a snap since nothing is (currently) executed upon
install. It is possible to run install hooks/etc on this, so the
proposal is not on its face problematic.
 
> 3. Standardize policy config dir and files
> 
>   Problem 5 is addressed by standardizing a config directory and file
>   layout. New locations must be added to the config dir to inform
>   apparmor of new policy locations and how they should be handled.
> 
>   The parser config has proven insufficient so Ubuntu has been
>   modifying the initscript to manage this which is not a solution
> that
>   can be shared across distros, nor does it provide a solution that
>   works with other parts of apparmor like the tools.
> 
>   Instead we have a directory in which each new location can drop its
>   own config, allowing to set its policy and include location cache,
>   and even compiler options if so desired.
> 
This makes a lot of sense. Are you envisioning apparmor would handle
all policy loads? For example, today snapd modifies policy in it own
area in /var/lib/snapd, outputs cache in /var/cache/apparmor and uses
its own options. Setting the cache and options is clear from a snapd-
perspective, what does setting the policy location imply? Or put
another way, how does this interact with '5', below?

> 
> 4. Limit distros ability to compile policy to the current kernels
>feature abi
> 
>   Along with this Distros will no longer be able to set a default
>   policy compile that will use the current kernel's abi. This will
> not
>   even be supported at the distro level as the project can not afford
>   to break the feature abi of current policy for kernel developers.
> 
>   To address this a new tool will be added to extract the kernel
>   features abi, and tooling will be updated to allow users update a
>   profiles abi and thus begin development on newer versions.
> Basically
>   a per user opt in only approach.

I'm a little confused by this. Why would it be bad for a distro to
compile policy to a *versioned* policy cache for the current feature
abi? I understand wanting to obsolete *un*versioned policy caches.

> 
> 5. Applications managing policy and unknown profiles
> 
>   The current solution to problem 6 of having unknown policy and
>   relying on aa-remove-unknown is more problematic. We are going to
>   have to break existing behavior to fix it.
> 
>   Applications that want to manage their own policy are going to have
>   to register to do so. This will require a new API for applications
>   to use which could just be a thin layer on top of the policy config
>   file.

This sounds fine and is not onerous. The few applications that manage
their own profiles (eg, libvirt, lxd, snapd, etc) are typically
following the cutting edge of apparmor development and are already
making changes to policy for new rules, so a small change to register
going forward seems ok to me.

...

> 6.1 New variables
> 
>   The @{abi} or @{version} variable that will be defined as part of
>   the abi include can be used by the rest of the includes to
>   selectively include rules that are abi specific
> 
>   eg. the  abstraction can do an include on
> 
>
> 
> 
>   In addition to the @{abi} variable the parser should make the full
>   feature set available for finer grained decision making.
> 
>   if @{features/network/af_unix} {
>  ...
>   }

I like this type of rule.

> 6.2 Conditional include
> 
...

>   The syntax needs to be decided on, but some suggestions that have
>   been thrown around in the past are:
> 
> 
>   * Make style
> 
> with a - at the start of the line, in apparmor's case it would be
> a special qualifier that for the time being only applies to
> includes.
> 
> - include 

This reads like it is (part of) a comment. I don't particularly care
for it. Not sure which of the others I prefer so won't comment further.

...

> 7. Dealing with new policy features on older releases.
> 
>   Where possible the parser supports downgrading rules. However this
>   only works for rule types that