Re: Apparmor: 1 processes are unconfined but have a profile defined
Le lundi 2 août 2021 à 06:00:05 UTC+2, Ratan Gupta a écrit : [...] > In my case it is not at all complaining as it is because the process is > unconfined. [...] If I am not mistaken, the purpose of the complain mode is precisely to inform about policy violations without forbidding them (forbidding, that is the purpose of the enforce mode). So, to me, there is no contradiction between complaining and unconfined I am not knowledgeable enough to really help you in this matter, so I would suggest you to take a look at the AppArmor doc: - Profiling_with_tools https://gitlab.com/apparmor/apparmor/-/wikis/Profiling_with_tools - or Profiling_by_hand, if you prefer https://gitlab.com/apparmor/apparmor/-/wikis/Profiling_by_hand - AppArmorMonitoring https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorMonitoring Good luck ;-)
Re: Apparmor: 1 processes are unconfined but have a profile defined
Hi Didier,
I was not able to reply on your mail as I am not part of the above mailing
list, I have subscribed myself now.
Regarding your suggestion.
> From what I understand, unless you specify a deny rule, when you switch
an AppArmor profile to complain mode, it complains but does not confine, so
you would probably switch your AppArmor profile to enforce mode instead.
In my case it is not at all complaining as it is because the process is
unconfined.
> And I suspect that on a default Debian installation (Systemd instead of
SysVinit), restarting unit or reloading configuration by a /etc/init.d
command instead of systemctl might have undesired effects.
I tried with systemctl(systemctl reload/restart apparmor) but that also
didn't work.
On Fri, Jul 30, 2021 at 3:24 PM Ratan Gupta wrote:
> Hi Team,
>
>
>
> Looking for your help.
>
>
>
> I have gone through the following link where the similar issue was asked.
>
>
>
> https://lists.debian.org/debian-user/2018/07/msg00542.html
>
>
>
> Issue: I made a profile for the application, and it is not getting
> confined by the apparmor.
>
>
>
> What I did:
>
>
>
> 1) I wrote the following profile
>
>
>
> root@abc:~# cat /etc/apparmor.d/usr.bin.phosphor-network-snmpconf
>
> # Last Modified: Thu Jul 29 14:30:33 2021
>
> #include
>
>
>
> /usr/bin/phosphor-network-snmpconf flags=(complain) {
>
> #include
>
>
>
> /lib/x86_64-linux-gnu/ld-*.so mr,
>
> /usr/bin/phosphor-network-snmpconf mr,
>
> }
>
>
> 2) Reload the apparmor profiles
>
> /etc/init.d/apparmor reload
>
>
> 3)
>
> I ran the binary under complain mode through the following command.
>
>
>
> aa-complain /usr/bin/phosphor-network-snmpconf
>
> Setting /usr/bin/phosphor-network-snmpconf to complain mode.
>
> [ 875.716595] kauditd_printk_skb: 40 callbacks suppressed
>
> [ 875.716649] audit: type=1400 audit(1627637368.796:113):
> apparmor="STATUS" operation="profile_replace" info="same as current
> profile, skipping" profile="unconfined"
> name="/usr/bin/phosphor-network-snmpconf" pid=815 comm="apparmor_parser"
>
>
>
> 4)
>
> Restart the snmp service which internally calls the
> phosphor-network-snmpconf
>
>
>
> systemctl restart xyz.openbmc_project.Network.SNMP.service
>
>
>
> 4) How the above service file looks like
>
>
> https://github.com/openbmc/openbmc/blob/1497c9c9c743277815d7b19f6112bf20c1e24c4f/meta-phosphor/recipes-phosphor/network/phosphor-snmp/xyz.openbmc_project.Network.SNMP.service
>
>
>
> 5) Output of aa-status as follows:
>
>
>
> root@abc:~# aa-status
>
> apparmor module is loaded.
>
> 48 profiles are loaded.
>
> 47 profiles are in enforce mode.
>
>/usr/lib/apache2/mpm-prefork/apache2
>
>/usr/lib/apache2/mpm-prefork/apache2//DEFAULT_URI
>
>/usr/lib/apache2/mpm-prefork/apache2//HANDLING_UNTRUSTED_INPUT
>
>/usr/lib/apache2/mpm-prefork/apache2//phpsysinfo
>
>apache2
>
>apache2//DEFAULT_URI
>
>apache2//HANDLING_UNTRUSTED_INPUT
>
>apache2//phpsysinfo
>
>avahi-daemon
>
>dnsmasq
>
>dnsmasq//libvirt_leaseshelper
>
>dovecot
>
>dovecot-anvil
>
>dovecot-auth
>
>dovecot-config
>
>dovecot-deliver
>
>dovecot-dict
>
>dovecot-dovecot-auth
>
>dovecot-dovecot-lda
>
>dovecot-dovecot-lda//sendmail
>
>dovecot-imap
>
>dovecot-imap-login
>
>dovecot-lmtp
>
>dovecot-log
>
>dovecot-managesieve
>
>dovecot-managesieve-login
>
>dovecot-pop3
>
>dovecot-pop3-login
>
>dovecot-script-login
>
>dovecot-ssl-params
>
>dovecot-stats
>
>identd
>
>klogd
>
>lsb_release
>
>mdnsd
>
>nmbd
>
>nscd
>
>ntpd
>
>php-fpm
>
>ping
>
>smbd
>
>smbldap-useradd
>
>smbldap-useradd///etc/init.d/nscd
>
>syslog-ng
>
>syslogd
>
>traceroute
>
>winbindd
>
> 1 profiles are in complain mode.
>
>/usr/bin/phosphor-network-snmpconf
>
> 0 profiles are in kill mode.
>
> 0 profiles are in unconfined mode.
>
> 1 processes have profiles defined.
>
> 0 processes are in enforce mode.
>
> 0 processes are in complain mode.
>
> 1 processes are unconfined but have a profile defined.
>
>/usr/bin/phosphor-network-snmpconf (825)
>
> 0 processes are in mixed mode.
>
> 0 processes are in kill mode.
>
>
>
> 7) Source code of snmp service : https://github.com/openbmc/phosphor-snmp
>
>
>
> Expectation was that when I run the SNMP service , it should throw the
> DENIAL messages but I am not getting any DENIAL messages as the
> process is unconfined.
>
>
>
> Can you please let me know where I am making the mistake.
>
>
>
> Ratan
>
Re: Apparmor: 1 processes are unconfined but have a profile defined
Hello, Disclaimer: I never wrote an AppArmor profile >From what I understand, unless you specify a deny rule, when you switch an >AppArmor profile to complain mode, it complains but does not confine, so you >would probably switch your AppArmor profile to enforce mode instead. And I suspect that on a default Debian installation (Systemd instead of SysVinit), restarting unit or relading configuration by a /etc/init.d command instead of systemctl might have undesired effects. https://wiki.debian.org/AppArmor/HowToUse https://linuxhint.com/apparmor-profiles-ubuntu/
Re: Apparmor: 1 processes are unconfined but have a profile defined
Hi. On Fri, Jul 13, 2018 at 11:59:00PM +0300, Ge wrote: > > On Fri, Jul 13, 2018 at 11:09:19PM +0300, Ge wrote: > >> Hi i couldn't figure out so i delete all Firefox profiles and i started > >> again from the beginning > > > > If you just deleted the files from /etc/apparmor.d - that won't be > > enough as old profiles are still loaded into the running kernel. > > See if it sticks after the reboot. > > > > But, > I also reboot my laptop > > > >> My Firefox profile now seems to work. > >> > >> sudo cat ./usr.lib.firefox-esr.firefox-esr > > > > If your Apparmor profile is not world-readable then you're doing it > > wrong (i.e. sudo should not be needed for this). > > > Why? You won't increase overall security by setting such files non-world-readable, and requiring root just to read such files is wrong. Reco
Re: Apparmor: 1 processes are unconfined but have a profile defined
Hi!
Thanks for your detail reply.
On 07/13/2018 11:42 PM, Reco wrote:
> Hi.
>
> I accept on-list communication only.
>
> On Fri, Jul 13, 2018 at 11:09:19PM +0300, Ge wrote:
>> Hi i couldn't figure out so i delete all Firefox profiles and i started
>> again from the beginning
>
> If you just deleted the files from /etc/apparmor.d - that won't be
> enough as old profiles are still loaded into the running kernel.
> See if it sticks after the reboot.
>
> But,
I also reboot my laptop
>
>> My Firefox profile now seems to work.
>>
>> sudo cat ./usr.lib.firefox-esr.firefox-esr
>
> If your Apparmor profile is not world-readable then you're doing it
> wrong (i.e. sudo should not be needed for this).
>
Why?
>> [sudo] password for gssd:
>> # Last Modified: Fri Jul 13 19:58:57 2018
>> #include
>>
>> /usr/lib/firefox-esr/firefox-esr {
>
> That line's crucial. Enabling and disabling should be done via
> aa-enforce/aa-complain /usr/lib/firefox-esr/firefox-esr.
>
Yes i used aa-enforce and aa-disable. I didnt use aa-complain that much.
>
>> "/home/gssd/.mozilla/firefox/Crash Reports/*" r,
>
> This one and everything like it are better written as:
>
> owner "@{HOME}/.mozilla/firefox/Crash Reports/*" r
>
> And I wonder whenever disabling writing crash reports was intentional.
>
>> /home/*/.mozilla/firefox/72z9u2as.default/browser-extension-data/** rw,
>
> This one:
>
> owner @{HOME}/.mozilla/firefox/*/browser-extension-data/** rw,
>
>
I didnt write the profile files. I used aa-genprof and aa-logprof to
automatically created them.
Thanks again for your help!
> Everything else is more or less ok.
>
> Reco
>
Re: Apparmor: 1 processes are unconfined but have a profile defined
Hi.
I accept on-list communication only.
On Fri, Jul 13, 2018 at 11:09:19PM +0300, Ge wrote:
> Hi i couldn't figure out so i delete all Firefox profiles and i started
> again from the beginning
If you just deleted the files from /etc/apparmor.d - that won't be
enough as old profiles are still loaded into the running kernel.
See if it sticks after the reboot.
But,
> My Firefox profile now seems to work.
>
> sudo cat ./usr.lib.firefox-esr.firefox-esr
If your Apparmor profile is not world-readable then you're doing it
wrong (i.e. sudo should not be needed for this).
> [sudo] password for gssd:
> # Last Modified: Fri Jul 13 19:58:57 2018
> #include
>
> /usr/lib/firefox-esr/firefox-esr {
That line's crucial. Enabling and disabling should be done via
aa-enforce/aa-complain /usr/lib/firefox-esr/firefox-esr.
> "/home/gssd/.mozilla/firefox/Crash Reports/*" r,
This one and everything like it are better written as:
owner "@{HOME}/.mozilla/firefox/Crash Reports/*" r
And I wonder whenever disabling writing crash reports was intentional.
> /home/*/.mozilla/firefox/72z9u2as.default/browser-extension-data/** rw,
This one:
owner @{HOME}/.mozilla/firefox/*/browser-extension-data/** rw,
Everything else is more or less ok.
Reco
Re: Apparmor: 1 processes are unconfined but have a profile defined
Hi. On Fri, Jul 13, 2018 at 07:10:51PM +0300, Ge wrote: > Hello > Im trying to make my own profiles for apparmor. > > I made a profile for firefox-esr but for some reason i cant get apparmor > to confine it. I run aa-enforce firefox-esr but nothing change. First, you're supposed to restart confined process, as Apparmor profile applies on process start only. Second, Apparmor applies to a full pathnames only, and aa-enforce is dumb enough to pick /usr/bin/firefox-esr instead of a real firefox binary (which should be /usr/lib/firefox-esr/firefox-esr). > Any ideas? > Thanks in advance for your help. Third, I see a discrepancy here: > $sudo aa-status > apparmor module is loaded. > 21 profiles are loaded. > 21 profiles are in enforce mode. >/etc/apparmor.d/usr.lib.firefox-esr.firefox-esr ... >/usr/bin/firefox ... > 3 processes are in enforce mode. >/usr/bin/freshclam (689) >/usr/lib/firefox-esr/plugin-container (1843) ... > 1 processes are unconfined but have a profile defined. >/usr/lib/firefox-esr/firefox-esr (1798) Which binary does your custom profile apply to? Can you share it? Reco
