On 07/08/2020 22.12, Christian Boltz wrote:
>
> They get added up - so in your example, you'll get rw.
>
> As another example,
>
> /foo rwl,
> /foo wk,
>
> will effectively give you /foo rwlk,
>
I have a question -- what would be in this case?
owner /foo rwl,
/foo wk,
On 11/02/2020 16:36, mailinglis...@posteo.de wrote:
> What I recently do is to create a copy of a program and then have 2
> profiles, one very tight and the other a bit more flexibel, e.g. I have
> /usr/bin/vlc and /usr/bin/vlc-secure both exactly the same, but with
> different name that allows
On 26/10/2019 18:08, John Johansen wrote:
> Unfortunately apparmor only supports 12 of this style of transition in a
> profile atm. There are 2 patch sets in the works to help address this. A
> smaller patch that can be backported to older kernels, and userspaces. It
> will raise the limit to 28
Should the rules in the following test profile count as a profile transitions?
profile test /bin/test {
/file1 rwl -> /some-file1,
/file2 rwl -> /some-file2,
/file3 rwl -> /some-file3,
/file4 rwl -> /some-file4,
/file5 rwl -> /some-file5,
/file6 rwl -> /some-file6,
/file7 rwl ->
On 17/09/2019 14:53, Seth Arnold wrote:
> 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
When I add a profile for some app, and this profile wants to execute or
map some file, it usually wants the "x" (operation="exec") or "m"
(operation="file_mmap") permissions. But what about the path the profile
confines?
For instance, I have a perl script under /usr/bin/some_app . When I
On 07/08/2019 05:34, John Johansen wrote:
> name="apparmor/.null" says that it is an fd that was inherited and apparmor
> did a
> revalidation on it and the access was denied so the fd was duped to a special
> null
> device files instead of out right closing it (there are good reasons for
>
On 07/08/2019 00:24, Seth Arnold wrote:
> - run both processes in the same filesystem namespace, so files have names
> that are meaningful to both
>
I though they both run in the same filesystem namespace.
It's just /usr/sbin/deluser which executes /usr/sbin/userdel .
Here are the two
I have two apps: *app1* and *app2*, and *app1* calls/executes *app2* at
some point in time.
When I create an AppArmor profile for *app2* only, the *app2* works
well, and there's no problem with its confinement. When now I create an
AppArmor profile for *app1* and inside of this profile I use
On 22/05/2019 21:17, Jamie Strandboge wrote:
> In short, today you can't do this without patching your pulseaudio and denying
> access to /dev/snd. In the future, pipewire should allow this sort of
> mediation, but I don't know OTOH what that will look like atm.
>
I see... Thanks for the answer.
There's currently an abstraction *abstractions/audio* which
gives access to all devices/files that have something to do
with playing/capturing sounds. Many apps need only the
playback devices to play sounds. Other apps need also the
capture devices, so they could record sounds via a
On 10/01/2019 14:58, Christian Boltz wrote:
> The proper solution / fix is to expand variables and to work on their
> content, but I'm afraind that isn't something I can do quickly.
>
> For now, you could use a workaround - prefix the variable name with the
> profile name [2], so that you have
On 10/01/2019 01:31, John Johansen wrote:
> Well this is certainly allowed, and the python based tools should be able
> to support it. Are you sure they weren't failing in the past? If so this
> would be a regression.
I have around 300 profiles, some of them are disabled because they're not
On 03/01/2019 15:24, John Johansen wrote:
> What version of the apparmor userspace are you using
> apparmor_parser -V
>
> and what kernel are you using?
>
It was 2.13.1 , but recently there was an update to 2.13.2 in debian.
I haven't check whether the newer version works or not.
Kernel was
Most of the mount rules work just fine, but I have one that doesn't really want
to work. Here's the log message:
-
[ 586.912376] audit: type=1400 audit(1545442788.976:399): apparmor="ALLOWED"
operation="mount" info="failed flags match" error=-13 profile="systemd-shutdown"
name="/"
I can't really figure out what apparmor wants from me in the following message:
kernel: [61380.312237] audit: type=1400 audit(1541256918.026:2604):
apparmor="DENIED" operation="exec" info="no new privs" error=-1
profile="opt-google-chrome-chrome" name="/usr/bin/xdg-desktop-menu" pid=115118
On 2018-05-30 08:44, Germán Diago Gómez wrote:
>
>> 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
> I found a couple
On 2018-04-02 09:33, John Johansen wrote:
> On 03/30/2018 09:23 AM, Mikhail Morfikov wrote:
>> AppArmor has a feature that allows it to log messages, and that behavior can
>> be
>> controlled via /sys/module/apparmor/parameters/audit . But according to some
>> do
On 2017-10-07 18:26, Christian Boltz wrote:
> Hello,
>
> Am Samstag, 7. Oktober 2017, 17:34:45 CEST schrieb Mikhail Morfikov:
>> After updating the kernel from 4.12 -> 4.13, some of my programs
>> stopped working, even though they have profiles in the "complai
After updating the kernel from 4.12 -> 4.13, some of my programs stopped
working, even though they have profiles in the "complain mode". Here's an
example of a message that appears in the system log:
AVC apparmor="ALLOWED" operation="exec" info="no new privs" error=-1
profile="/bin/app_1"
I've been using AppArmor for some time, and I wrote many profiles for my apps.
It wasn't really a hard task, but with the kernel update in Debian (4.12 ->
4.13), many of mine profiles (already "enforced") started to give messages
similar to the one below:
AVC apparmor="DENIED"
21 matches
Mail list logo
