|
Apparmor Ubuntu and Liquorix
Hi.
It would be really nice if you could include an apparmor module in the kernel. I think proactive security should be part of a modern desktop (kernel). Thanks. I am currently using Ubuntu 11.10 and get the following error: # service apparmor start * Starting AppArmor profiles * AppArmor not available as kernel LSM. < Edited by enteon :: Dec 12, 11, 13:44 > Back to top |
|||||
|
The app armor module is already compiled as a module, but I think you need to set a kernel parameter in grub to force it to replace selinux. If you check the kernel-parameters.txt file that comes with the kernel source, it says you need to set apparmor=1.
See if that works. I probably won't change this to be the default option though, since Debian doesn't really have an affinity towards AppArmor. Back to top |
|||||
|
Thanks for the hint!
It actually needed apparmor=1 security=apparmor. It's fine with me that this isn't the default behavior, i could have found it on archwiki before, but i was in kind of a lecture situation ;-) edit: actually it doesn't work at all: :: Code :: # /etc/init.d/apparmor start
* Starting AppArmor profiles Cache read/write disabled: /sys/kernel/security/apparmor/features interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.) And a whole lot more, some for every rule it seems. Also: :: Code :: # aa-status
apparmor module is loaded. You do not have enough privilege to read the profile set. Although it prints all profiles and their status with stock kernel. I found the corresponding bugreport: bugs.launchpad.net/ubuntu/+source/apparmor/+bug/680485 So does this mean ubuntu is shipping apparmor 2.7 but for some reason relying on a 2.4 compatibility layer?? That sounds stupid to me. I'm stuck, do you happen to see an easy way around this? Thanks again. Back to top |
|||||
|
I think I may have the very same issue:on Mint 13 (directly based on Ubuntu 12.04) with kernel 3.4.0-35.dmz.1-liquorix-amd64,after installing apparmor and adding
:: Code :: apparmor=1 security=apparmorapparmor module is loaded. You do not have enough privilege to read the profile set. The thing is,if I start the same system on a default kernel (I have the original Mint kernel and a mainline Ubuntu kernel as well),apparmor works apparently fine and I'm not getting that message above. Is there an incompatibility of sort between Liquorix kernels and apparmor? Is apparmor actually supported? Back to top |
|||||
|
The 3.4 liquorix kernel is no longer supported, much less available anymore in the repository. Can you try using a kernel in the main or past branch?
Back to top |
|||||
|
Well,yes...I have been sticking with this kernel because it worked wonders for my oldish issues with Mint 13 and suspension to RAM ( techpatterns.com/forums/about2258.html ),it made suspension work almost flawlessly and then I also managed (not without some struggle with Mint) to install the ATI driver using the sgfxi script-so I haven't touched anything since,as far as kernel goes.
But,I have already rsynced my entire installation on another drive for testing purposes a while ago,so I guess I'll update there to a current Liquorix kernel and see what happens-I take I'll have to eventually re-run sgfxi and reinstall the ATI driver,correct? And what you suggest I should try first,past or current branch? BTW,suspension on this hardware works with any kernel (Debian,Ubuntu mainline,Liquorix) but the default Ubuntu/Mint kernel..who knows what are they trying to "fix" by tweaking the kernel. Back to top |
|||||
|
Because you're on AMD, I would recommend the past branch. Fglrx has a history of lazy kernel compatibility and I don't know what kernel they're on now.
And finally, yes, you always need to re-run sgfxi on each kernel upgrade. Back to top |
|||||
|
Ok,done:I've upgraded to 3.10-19.dmz.1-liquorix-amd64 and reinstalled the ATI driver using sgfxi.
Not everything went smoothly,as I was kinda anticipating:first I've encountered some errors during the new kernel installation: :: Code :: Error! Could not locate dkms.conf file.
File: does not exist. Error! Bad return status for module build on kernel: 3.10-19.dmz.1-liquorix-amd64 (x86_64) Consult /var/lib/dkms/fglrx/9.012/build/make.log for more information. update-initramfs: Generating /boot/initrd.img-3.10-19.dmz.1-liquorix-amd64 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-3.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-2.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-2.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-1.fw for module r8169 Setting up linux-headers-3.10-19.dmz.1-liquorix-amd64 (3.10-12) ... Examining /etc/kernel/header_postinst.d. run-parts: executing /etc/kernel/header_postinst.d/dkms 3.10-19.dmz.1-liquorix-amd64 Error! Could not locate dkms.conf file. File: does not exist. Error! Bad return status for module build on kernel: 3.10-19.dmz.1-liquorix-amd64 (x86_64) Consult /var/lib/dkms/fglrx/9.012/build/make.log for more information. the above are the significant parts from the terminal messages during the installation,however I've saved the entire output just in case. (That "missing firmware" message also pops up during a Debian straight installation,interestingly:the network card works just as well without that firmware,apparently.) Below is the entire log referenced in the message above,sorry for posting it all but I had no idea of what is relevant in there and what is not :: Code :: DKMS make.log for fglrx-9.012 for kernel 3.10-19.dmz.1-liquorix-amd64 (x86_64)
Thu Nov 28 15:45:02 CET 2013 AMD kernel module generator version 2.1 doing Makefile based build for kernel 2.6.x and higher rm -rf *.c *.h *.o *.ko *.a .??* *.symvers make -C /lib/modules/3.10-19.dmz.1-liquorix-amd64/build SUBDIRS=/var/lib/dkms/fglrx/9.012/build/2.6.x modules make[1]: Entering directory `/usr/src/linux-headers-3.10-19.dmz.1-liquorix-amd64' CC [M] /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.o In file included from /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:467:0: /var/lib/dkms/fglrx/9.012/build/2.6.x/drm_proc.h: In function ‘FGLDRM_proc_init’: /var/lib/dkms/fglrx/9.012/build/2.6.x/drm_proc.h:98:2: error: implicit declaration of function ‘create_proc_entry’ [-Werror= implicit-function-declaration] /var/lib/dkms/fglrx/9.012/build/2.6.x/drm_proc.h:98:19: warning: assignment makes pointer from integer without a cast [enabl ed by default] /var/lib/dkms/fglrx/9.012/build/2.6.x/drm_proc.h:105:12: warning: assignment makes pointer from integer without a cast [enab led by default] /var/lib/dkms/fglrx/9.012/build/2.6.x/drm_proc.h:112:7: warning: assignment makes pointer from integer without a cast [enabl ed by default] /var/lib/dkms/fglrx/9.012/build/2.6.x/drm_proc.h:124:6: error: dereferencing pointer to incomplete type /var/lib/dkms/fglrx/9.012/build/2.6.x/drm_proc.h:125:6: error: dereferencing pointer to incomplete type /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c: In function ‘firegl_proc_init’: /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:589:14: warning: assignment makes pointer from integer without a cast [enabled by default] /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:601:13: warning: assignment makes pointer from integer without a cast [enabled by default] /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:608:12: error: dereferencing pointer to incomplete type /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:608:27: error: ‘read_proc_t’ undeclared (first use in this function) /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:608:27: note: each undeclared identifier is reported only once for each function it appears in /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:608:39: error: expected expression before ‘)’ token /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:612:15: warning: assignment makes pointer from integer without a cast [enabled by default] /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:622:13: warning: assignment makes pointer from integer without a cast [enabled by default] /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:642:16: error: dereferencing pointer to incomplete type /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:642:43: error: expected expression before ‘)’ token /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:647:16: error: dereferencing pointer to incomplete type /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:651:16: error: dereferencing pointer to incomplete type /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:660:13: warning: assignment makes pointer from integer without a cast [enabled by default] /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:663:16: error: dereferencing pointer to incomplete type /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:663:43: error: expected expression before ‘)’ token /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:664:16: error: dereferencing pointer to incomplete type /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:664:32: error: ‘write_proc_t’ undeclared (first use in this function) /var/lib/dkms/fglrx/9.012/build/2.6.x/firegl_public.c:664:45: error: expected expression before ‘)’ token BTW,I've used sgfxi with no options and just let it run:again (as described here : techpatterns.com/forums/about2258.html ) the Mint mdm login screen respawned in the middle of the driver installation and forced me to log in to a broken X server (obviously),and then by returning to the previous console I could finish the installation:having said all that,apparmor is not working with this kernel either. Checking apparmor status (the kernel is booted with apparmor=1 security=apparmor,which works in Debian with a default kernel) I'm still getting :: Code :: sudo /etc/init.d/apparmor status
apparmor module is loaded. You do not have enough privilege to read the profile set. sudo aa-status --verbose apparmor module is loaded. You do not have enough privilege to read the profile set. using the root terminal or su nothing changes,it gives the same error. Any ideas? Am I been doing something wrong,other than using Mint (I *have* to use an alternative kernel because with the default Ubuntu/Mint kernel suspension/hibernation won't work)? Back to top |
|||||
|
that's a good bug report, I've heard from random mint users over the last years, but you are the first to actually note all the relevant visible events as they happened with fglrx/sgfxi.
I'm only concerned with that side of things since that's what I maintain. So mdm is respawning, that's a bug since sgfxi told it to shutdown, a bug in mint, that is. That's what I thought was happening at some level, something in ubuntu does that too sometimes, but it's not a sgfxi problem, though I'll double check to make sure mdm is in the set of dm to test/shutdown. Given it's probably also using upstart or something (can you confirm what your actual init manager is, systemd, upstart, svsv?), there may also be an issue with how upstart is told to handle certain services, no idea since I don't use that stuff, just plain old sysv init system. The dkms likewise is a bug somewhere because sgfxi strives to remove all relevant packages running the driver updating, ie, dkms should no longer be operational, it should have turned off because the fglrx driver package should have been removed, unless it wasn't, or unless mint uses some other package name involved in fglrx dkms that does not include the term 'fglrx' in it. If that's the case, I can add the package name to the remove pattern list. Using mint is definitely one of your mistakes though, you seem technically competent enough to dump that crutch, they just introduce more errors and glitches from what I see from my end, but it is nice to finally get a reasonably coherent bug report from a mint user, it's been years.. On the mdm respawn issue, can you check this, go out of x, run: service mdm stop || echo failed $? and tell me what happens? then sit there a while, 5 minutes or so should be long enough, and see if mdm respawns. If you see 'failed [number]' in the output, that means mdm failed to stop, which means sgfxi would have gone to the default of killing x directly, which could cause a respawn event, though it's shouldn't. If it shutdown, and then respawns, that's a bug in the configuration and you should file a bug report to ubuntu, the operating system ignoring your command is a fairly serious bug in my opinion. Back to top |
|||||
|
actually, I rechecked the sgfxi logic, and what's supposed to happen is a series of tests should construct the dm shutdown command, in this case, it should be:
stop mdm if it's upstart, that is determined if the stop command exists, and if the mdm exists. Note, in some cases this will fail if the system has two dm's installed, out of the list: entrance gdm gdm3 kdm kdm-trinity lightdm lxdm mdm nodm slim wdm xdm which can be determined by running the command: type -p <dm> where <dm> is one of those names. If the system did have more than one installed, and if the other one was alphabetically earlier than the actual one, then this will fail, but that's yet another bug in the in the base system since there should be only one. sgfxi has in its logs what it did, what dm is picked, if you search /var/log/sgfxi/sgfxi.log for: dmanCommand: you can see what it tried to do, and if you then try that same command, and see what the result is, that is some information. I don't run upstart or systemd, all I can say is this used to work on ubuntu, but they keep changing their core while pretending to be stabilizing the base debian systems for end users, so I don't track ubunty changes anymore, it's boring. Back to top |
|||||
|
All times are GMT - 8 Hours
|
|||||