Bitbake-type build question

Bitbake-type build question

[Aaron Biver]

[-- Attachment #1.1: Type: text/plain, Size: 2714 bytes --]

I'm attempting to cross-compile the 2.8 maintenance branch with petalinux,
which uses bitbake yocto under the hood to build it, and I run it on a
system V target which is a 64 bit arm architecture.  I'm seeing some errors
when I attempt to load rules for system some calls (like open, creat,
rename, link, etc) with auditctl, and I'm not sure how critical these
errors are.  This is my first encounter with linux auditing, and I'll
apologize in advance because I'm sure this is something easy, but I could
not find a way to search the mailing list archives.

These are some of my errors from auditctl's output:
> Syscall name unknown: creat
> There was an error in line 14 of /etc/audit/audit.rules
> Syscall name unknown: link
> There was an error in line 15 of /etc/audit/audit.rules
> Syscall name unknown: open
> There was an error in line 16 of /etc/audit/audit.rules
> Syscall name unknown: open
> There was an error in line 17 of /etc/audit/audit.rules
> Syscall name unknown: rename
> There was an error in line 19 of /etc/audit/audit.rules
> Syscall name unknown: rename
> There was an error in line 20 of /etc/audit/audit.rules

Those lines are below in an excerpt from my rules file (with line numbers
prepended for easy reading):
 13 -w /etc/hostname -p wa -k system-locale
 14 -a always,exit -F arch=b64 -S
creat,link,mknod,mkdir,symlink,mknodat,linkat,symlinkat -F exit=-EACCES -F
key=creation
 15 -a always,exit -F arch=b64 -S link,mkdir,symlink,mkdirat -F exit=-EPERM
-F key=creation
 16 -a always,exit -F arch=b64 -S open,openat,open_by_handle_at -F
exit=-EACCES -F key=open
 17 -a always,exit -F arch=b64 -S open,openat,open_by_handle_at -F
exit=-EPERM -F key=open
 18 -a always,exit -F arch=b64 -S close -F exit=-EIO -F key=close
 19 -a always,exit -F arch=b64 -S rename -S renameat -S truncate -S chmod
-S setxattr -S lsetxattr -S removexattr -S lremovexattr -F exit=-EACCES -F
key=mods
 20 -a always,exit -F arch=b64 -S rename -S renameat -S truncate -S chmod
-S setxattr -S lsetxattr -S removexattr -S lremovexattr -F exit=-EPERM -F
key=mods

The startup script and rules I'm repurposing had rules for open, create,
link, unlink, rename, and others, and it seems like those would be part of
a reasonable auditing security plan, but these system calls do not appear
to be auditable on my system.

My target platform is a 64 bit arm architecture.   I have a bitbake recipe
which uses  the --with-aarch64.
I build the kernel with auditing support (CONFIG_AUDIT and others like it),
and I pass the audit=1 argument on the kernel boot command line.

Are there other incantations I am missing?  Any help would be greatly
appreciated.

Aaron

[-- Attachment #1.2: Type: text/html, Size: 3122 bytes --]

[-- Attachment #2: Type: text/plain, Size: 102 bytes --]

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Bitbake-type build question

[Steve Grubb]

On Wednesday, March 11, 2020 6:01:54 PM EDT Aaron Biver wrote:
> I'm attempting to cross-compile the 2.8 maintenance branch with petalinux,
> which uses bitbake yocto under the hood to build it, and I run it on a
> system V target which is a 64 bit arm architecture.  I'm seeing some errors
> when I attempt to load rules for system some calls (like open, creat,
> rename, link, etc) with auditctl, and I'm not sure how critical these
> errors are.  This is my first encounter with linux auditing, and I'll
> apologize in advance because I'm sure this is something easy, but I could
> not find a way to search the mailing list archives.
> 
> These are some of my errors from auditctl's output:
> > Syscall name unknown: creat
> > There was an error in line 14 of /etc/audit/audit.rules
> > Syscall name unknown: link
> > There was an error in line 15 of /etc/audit/audit.rules
> > Syscall name unknown: open
> > There was an error in line 16 of /etc/audit/audit.rules
> > Syscall name unknown: open
> > There was an error in line 17 of /etc/audit/audit.rules
> > Syscall name unknown: rename
> > There was an error in line 19 of /etc/audit/audit.rules
> > Syscall name unknown: rename
> > There was an error in line 20 of /etc/audit/audit.rules
> 
> Those lines are below in an excerpt from my rules file (with line numbers
> prepended for easy reading):
>  13 -w /etc/hostname -p wa -k system-locale
>  14 -a always,exit -F arch=b64 -S
> creat,link,mknod,mkdir,symlink,mknodat,linkat,symlinkat -F exit=-EACCES -F
> key=creation
>  15 -a always,exit -F arch=b64 -S link,mkdir,symlink,mkdirat -F exit=-EPERM
> -F key=creation
>  16 -a always,exit -F arch=b64 -S open,openat,open_by_handle_at -F
> exit=-EACCES -F key=open
>  17 -a always,exit -F arch=b64 -S open,openat,open_by_handle_at -F
> exit=-EPERM -F key=open
>  18 -a always,exit -F arch=b64 -S close -F exit=-EIO -F key=close
>  19 -a always,exit -F arch=b64 -S rename -S renameat -S truncate -S chmod
> -S setxattr -S lsetxattr -S removexattr -S lremovexattr -F exit=-EACCES -F
> key=mods
>  20 -a always,exit -F arch=b64 -S rename -S renameat -S truncate -S chmod
> -S setxattr -S lsetxattr -S removexattr -S lremovexattr -F exit=-EPERM -F
> key=mods
> 
> The startup script and rules I'm repurposing had rules for open, create,
> link, unlink, rename, and others, and it seems like those would be part of
> a reasonable auditing security plan, but these system calls do not appear
> to be auditable on my system.

If I were to venture a guess, I'd say that the ABI was created after glibc 
started using openat, renameat, linkat, etc. So, there was never a need to 
implement the older "insecure" syscalls.


> My target platform is a 64 bit arm architecture.   I have a bitbake recipe
> which uses  the --with-aarch64.
> I build the kernel with auditing support (CONFIG_AUDIT and others like it),
> and I pass the audit=1 argument on the kernel boot command line.
> 
> Are there other incantations I am missing?  Any help would be greatly
> appreciated.

You can always strace a program to see what syscalls its using. Also, 
ausyscall is handy for telling you if a syscall exists. I think you can drop 
the missing syscalls from your rules and you'll be fine.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit