lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 20 Oct 2008 22:53:13 -0700
From:	"Andrew G. Morgan" <morgan@...nel.org>
To:	Eric Paris <eparis@...hat.com>
CC:	linux-kernel@...r.kernel.org, linux-audit@...hat.com,
	viro@...iv.linux.org.ok, sgrubb@...hat.com, serue@...ibm.com
Subject: Re: [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or
 inheritable capabilities

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric Paris wrote:
> Any time fcaps are used to increase a processes pP or pE we will crate a new
> audit record which contains the entire set of known information about the 
> executable in question, fP, fI, fE, version and includes the parent processes
> pE, pI, pP.  This record type will only be emitted from execve syscalls.

I'm confused by the choice of when to log this event.

File capabilities are required to give a process 'any' active
capabilities. That is they don't affect pI -> pI', but without fI or fP,
the post-execve() process is guaranteed to have no pP or pE capabilities.

Logging execve()s where there is only an increase in capabilities seems
wrong to me. To me it seems equally important to log any event where an
execve() yields pP != 0.

> diff --git a/security/commoncap.c b/security/commoncap.c
> index 888b292..9bb285d 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -8,6 +8,7 @@
>   */
>  
>  #include <linux/capability.h>
> +#include <linux/audit.h>
>  #include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/kernel.h>
> @@ -320,6 +321,8 @@ static int get_file_caps(struct linux_binprm *bprm)
>  
>  	rc = bprm_caps_from_vfs_caps(&vcaps, bprm);
>  
> +	audit_log_bprm_fcaps(bprm, &vcaps);
> +

When rc != 0, the execve() will fail. Is it appropriate to log in this case?

Cheers

Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI/W5F+bHCR3gb8jsRAhM9AJ9oJL4PmdtMwHEkN0Xh0ZTHBlJPzgCfVT/8
1Rq4wgGWftqpaVXBmeAsEi8=
=W8R9
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ