Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #231254 > unrolled thread

Apparmor pain

Started byTony van der Hoff <lists@vanderhoff.org>
First post2021-01-29 14:10 +0100
Last post2021-01-29 18:00 +0100
Articles 5 — 4 participants

Back to article view | Back to linux.debian.user


Contents

  Apparmor pain Tony van der Hoff <lists@vanderhoff.org> - 2021-01-29 14:10 +0100
    Re: Apparmor pain Reco <recoverym4n@enotuniq.net> - 2021-01-29 14:30 +0100
      Re: Apparmor pain Tony van der Hoff <lists@vanderhoff.org> - 2021-01-29 15:30 +0100
        Re: Apparmor pain Brian <ad44@cityscape.co.uk> - 2021-01-29 16:50 +0100
        Re: Apparmor pain David Wright <deblis@lionunicorn.co.uk> - 2021-01-29 18:00 +0100

#231254 — Apparmor pain

FromTony van der Hoff <lists@vanderhoff.org>
Date2021-01-29 14:10 +0100
SubjectApparmor pain
Message-ID<BCBHc-7gE-15@gated-at.bofh.it>
This is a simplified scenario: Say I have 2 machines, both running 
Debian 10.7. Each machine has 3 users: A, B and C. Each machine has an 
identical (mantained by Unison) directoery: /home/C/pictures, with 
permissions ugo:rwx owned by C. Each file therein has permissions ugo:r

Both machines can access any file within pictures with no problems, as 
one would expect.

However, using Thunderbird, machine A can attach any file from pictures, 
but machine B fails silently to do so. Examining the syslog for B it 
would appear that apparmor is preventing access.

 From my web research it appears that apparmor was introduced by default 
at debian 10. On machine B it is blocking Thunderbird, but not on A.

I don't understand why my two machines are behaving so differently.

I don't think I really want apparmor running at all, but at least I'd 
like either machine to access C's files. Apparmor's man page gives 
eye-watering detail, but I can'tr find any easily usable configuration 
suggestions. The debian wiki gives me a way to disable apparmor by 
patching grub, but that seems like overkill.

Does anyone pease have any suggestions on how to enable an application 
without major surgery? any help appreciated. Thanks

-- 
Tony van der Hoff        | mailto:tony@vanderhoff.org
Buckinghamshire, England |

[toc] | [next] | [standalone]


#231255

FromReco <recoverym4n@enotuniq.net>
Date2021-01-29 14:30 +0100
Message-ID<BCC0x-7mH-3@gated-at.bofh.it>
In reply to#231254
	Hi.

On Fri, Jan 29, 2021 at 12:49:42PM +0000, Tony van der Hoff wrote:
> This is a simplified scenario: Say I have 2 machines, both running Debian 10.7. Each machine has 3 users: A, B and C. Each machine has an identical (mantained
> by Unison) directoery: /home/C/pictures, with permissions ugo:rwx owned by C. Each file therein has permissions ugo:r
...
> I don't understand why my two machines are behaving so differently.

uid difference between hosts A and B, most probably.
Along the other things, thunderbird's apparmor policy contains this:

    owner @{HOME}/** r,

I.e. it's allowed to read any file at /home as long as the file is owned
by thunderbird's uid.


> I don't think I really want apparmor running at all,

Add apparmor=0 to kernel's cmdline. Building a kernel without apparmor
helps with that too, but that's straying too far from Debian's defaults.


> The debian wiki gives me a way to disable apparmor by patching grub,
> but that seems like overkill.

You probably got it wrong. Modifying a kernel cmdline and rebuilding
grub with custom patches are different, and they should suggest former
at Debian's wiki.


> Does anyone pease have any suggestions on how to enable an application
> without major surgery? any help appreciated. Thanks

Disabling a problematic apparmor profile altogether is done by:

/usr/sbin/aa-disable /usr/bin/thunderbird

Disabling a problematic apparmor profile but keeping audit records
generation is done by

/usr/sbin/aa-complain /usr/bin/thunderbird

You'll want the first one, probably.

Reco

[toc] | [prev] | [next] | [standalone]


#231256

FromTony van der Hoff <lists@vanderhoff.org>
Date2021-01-29 15:30 +0100
Message-ID<BCCWB-7UX-3@gated-at.bofh.it>
In reply to#231255

On 29/01/2021 13:27, Reco wrote:
> 	Hi.
> 
> On Fri, Jan 29, 2021 at 12:49:42PM +0000, Tony van der Hoff wrote:
>> This is a simplified scenario: Say I have 2 machines, both running Debian 10.7. Each machine has 3 users: A, B and C. Each machine has an identical (mantained
>> by Unison) directoery: /home/C/pictures, with permissions ugo:rwx owned by C. Each file therein has permissions ugo:r
> ...
>> I don't understand why my two machines are behaving so differently.
> 
> uid difference between hosts A and B, most probably.
> Along the other things, thunderbird's apparmor policy contains this:
> 
>      owner @{HOME}/** r,
> 
> I.e. it's allowed to read any file at /home as long as the file is owned
> by thunderbird's uid.
> 
> 
>> I don't think I really want apparmor running at all,
> 
> Add apparmor=0 to kernel's cmdline. Building a kernel without apparmor
> helps with that too, but that's straying too far from Debian's defaults.
> 
> 
>> The debian wiki gives me a way to disable apparmor by patching grub,
>> but that seems like overkill.
> 
> You probably got it wrong. Modifying a kernel cmdline and rebuilding
> grub with custom patches are different, and they should suggest former
> at Debian's wiki.
> 
> 
>> Does anyone pease have any suggestions on how to enable an application
>> without major surgery? any help appreciated. Thanks
> 
> Disabling a problematic apparmor profile altogether is done by:
> 
> /usr/sbin/aa-disable /usr/bin/thunderbird
> 
> Disabling a problematic apparmor profile but keeping audit records
> generation is done by
> 
> /usr/sbin/aa-complain /usr/bin/thunderbird
> 
> You'll want the first one, probably.
> 
> Reco
> 

Thanks, Reco, that was just the information I needed. I had to install 
apparmor-utils, but otherwise aa-disable did the job.

Cheers, Tony
-- 
Tony van der Hoff        | mailto:tony@vanderhoff.org
Buckinghamshire, England |

[toc] | [prev] | [next] | [standalone]


#231260

FromBrian <ad44@cityscape.co.uk>
Date2021-01-29 16:50 +0100
Message-ID<BCEc2-7Q-3@gated-at.bofh.it>
In reply to#231256
On Fri 29 Jan 2021 at 14:21:07 +0000, Tony van der Hoff wrote:

> 
> 
> On 29/01/2021 13:27, Reco wrote:
> > 	Hi.
> > 
> > On Fri, Jan 29, 2021 at 12:49:42PM +0000, Tony van der Hoff wrote:
> > > This is a simplified scenario: Say I have 2 machines, both running Debian 10.7. Each machine has 3 users: A, B and C. Each machine has an identical (mantained
> > > by Unison) directoery: /home/C/pictures, with permissions ugo:rwx owned by C. Each file therein has permissions ugo:r
> > ...
> > > I don't understand why my two machines are behaving so differently.
> > 
> > uid difference between hosts A and B, most probably.
> > Along the other things, thunderbird's apparmor policy contains this:
> > 
> >      owner @{HOME}/** r,
> > 
> > I.e. it's allowed to read any file at /home as long as the file is owned
> > by thunderbird's uid.
> > 
> > 
> > > I don't think I really want apparmor running at all,
> > 
> > Add apparmor=0 to kernel's cmdline. Building a kernel without apparmor
> > helps with that too, but that's straying too far from Debian's defaults.
> > 
> > 
> > > The debian wiki gives me a way to disable apparmor by patching grub,
> > > but that seems like overkill.
> > 
> > You probably got it wrong. Modifying a kernel cmdline and rebuilding
> > grub with custom patches are different, and they should suggest former
> > at Debian's wiki.
> > 
> > 
> > > Does anyone pease have any suggestions on how to enable an application
> > > without major surgery? any help appreciated. Thanks
> > 
> > Disabling a problematic apparmor profile altogether is done by:
> > 
> > /usr/sbin/aa-disable /usr/bin/thunderbird
> > 
> > Disabling a problematic apparmor profile but keeping audit records
> > generation is done by
> > 
> > /usr/sbin/aa-complain /usr/bin/thunderbird
> > 
> > You'll want the first one, probably.
> > 
> > Reco
> > 
> 
> Thanks, Reco, that was just the information I needed. I had to install
> apparmor-utils, but otherwise aa-disable did the job.

Debian's default provision of apparmor is something I can take or
leave. Generally, I leave it by purging it from the system rather
than installing another unneeded package.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]


#231268

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2021-01-29 18:00 +0100
Message-ID<BCFhM-Kl-5@gated-at.bofh.it>
In reply to#231256
On Fri 29 Jan 2021 at 14:21:07 (+0000), Tony van der Hoff wrote:
> On 29/01/2021 13:27, Reco wrote:
> > On Fri, Jan 29, 2021 at 12:49:42PM +0000, Tony van der Hoff wrote:
> > > This is a simplified scenario: Say I have 2 machines, both running Debian 10.7. Each machine has 3 users: A, B and C. Each machine has an identical (mantained
> > > by Unison) directoery: /home/C/pictures, with permissions ugo:rwx owned by C. Each file therein has permissions ugo:r
> > ...
> > > I don't understand why my two machines are behaving so differently.
> > 
> > uid difference between hosts A and B, most probably.
> > Along the other things, thunderbird's apparmor policy contains this:
> > 
> >      owner @{HOME}/** r,
> > 
> > I.e. it's allowed to read any file at /home as long as the file is owned
> > by thunderbird's uid.

I'm assuming that you mean a file owned by the user who's running TB,
not that TB owns it. (Why would you want TB to own your own mail.)

> > […]

> > Disabling a problematic apparmor profile altogether is done by:
> > 
> > /usr/sbin/aa-disable /usr/bin/thunderbird
> > 
> > Disabling a problematic apparmor profile but keeping audit records
> > generation is done by
> > 
> > /usr/sbin/aa-complain /usr/bin/thunderbird
> 
> Thanks, Reco, that was just the information I needed. I had to install
> apparmor-utils, but otherwise aa-disable did the job.

Note that this change does not fix the problem of administering a
group of machines with different users' userids, assuming that
that actually *was* the underlying cause. Many utilities will cope
because they communicate with usernames, but archive files and
filesystems that are shared between machines will employ numeric
IDs, which convey the wrong information. Fixing apparmor just treats
one symptom.

(It's usual for different machines to have different *system* UIDs and
GIDs, except for a very short list. That's a different kettle of fish.)

Cheers,
David.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.user


csiph-web