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

2017-12-11 Thread 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

Re: [apparmor] Help needed - Apparmor usage

2017-12-11 Thread 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

Re: [apparmor] RFC: Policy versioning

2017-12-11 Thread 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

Re: [apparmor] RFC: Policy versioning

2017-12-11 Thread 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

Re: [apparmor] RFC: Policy versioning

2017-12-11 Thread 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

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

2017-12-11 Thread 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.

Re: [apparmor] RFC: Policy versioning

2017-12-11 Thread 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

Re: [apparmor] RFC: Policy versioning

2017-12-11 Thread 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

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

2017-12-11 Thread 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.

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

2017-12-11 Thread 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

Re: [apparmor] RFC: Policy versioning

2017-12-11 Thread 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.