[apparmor] [PATCH] apparmor: Remove deadcode
From: "Dr. David Alan Gilbert"
aa_label_audit, aa_label_find, aa_label_seq_print and aa_update_label_name
were added by commit
f1bd904175e8 ("apparmor: add the base fns() for domain labels")
but never used.
aa_profile_label_perm was added by commit
637f688dc3dc ("apparmor: switch from profiles to using labels on contexts")
but never used.
aa_secid_update was added by commit
c092921219d2 ("apparmor: add support for mapping secids and using secctxes")
but never used.
aa_split_fqname has been unused since commit
3664268f19ea ("apparmor: add namespace lookup fns()")
aa_lookup_profile has been unused since commit
93c98a484c49 ("apparmor: move exec domain mediation to using labels")
aa_audit_perms_cb was only used by aa_profile_label_perm (see above).
All of these commits are from around 2017.
Remove them.
Signed-off-by: Dr. David Alan Gilbert
---
security/apparmor/include/label.h | 4 --
security/apparmor/include/lib.h| 1 -
security/apparmor/include/perms.h | 3 --
security/apparmor/include/policy.h | 1 -
security/apparmor/include/secid.h | 1 -
security/apparmor/label.c | 33
security/apparmor/lib.c| 84 --
security/apparmor/policy.c | 5 --
security/apparmor/secid.c | 14 -
9 files changed, 146 deletions(-)
diff --git a/security/apparmor/include/label.h
b/security/apparmor/include/label.h
index 2a72e6b17d68..83a840d935bc 100644
--- a/security/apparmor/include/label.h
+++ b/security/apparmor/include/label.h
@@ -291,8 +291,6 @@ bool aa_label_replace(struct aa_label *old, struct aa_label
*new);
bool aa_label_make_newest(struct aa_labelset *ls, struct aa_label *old,
struct aa_label *new);
-struct aa_label *aa_label_find(struct aa_label *l);
-
struct aa_profile *aa_label_next_in_merge(struct label_it *I,
struct aa_label *a,
struct aa_label *b);
@@ -320,8 +318,6 @@ void aa_label_seq_xprint(struct seq_file *f, struct aa_ns
*ns,
struct aa_label *label, int flags, gfp_t gfp);
void aa_label_xprintk(struct aa_ns *ns, struct aa_label *label, int flags,
gfp_t gfp);
-void aa_label_audit(struct audit_buffer *ab, struct aa_label *label, gfp_t
gfp);
-void aa_label_seq_print(struct seq_file *f, struct aa_label *label, gfp_t gfp);
void aa_label_printk(struct aa_label *label, gfp_t gfp);
struct aa_label *aa_label_strn_parse(struct aa_label *base, const char *str,
diff --git a/security/apparmor/include/lib.h b/security/apparmor/include/lib.h
index d7a894b1031f..f11a0db7f51d 100644
--- a/security/apparmor/include/lib.h
+++ b/security/apparmor/include/lib.h
@@ -59,7 +59,6 @@ extern int apparmor_initialized;
/* fn's in lib */
const char *skipn_spaces(const char *str, size_t n);
-char *aa_split_fqname(char *args, char **ns_name);
const char *aa_splitn_fqname(const char *fqname, size_t n, const char
**ns_name,
size_t *ns_len);
void aa_info_message(const char *str);
diff --git a/security/apparmor/include/perms.h
b/security/apparmor/include/perms.h
index 0f7e913c3fc2..bbaa7d39a39a 100644
--- a/security/apparmor/include/perms.h
+++ b/security/apparmor/include/perms.h
@@ -213,9 +213,6 @@ void aa_perms_accum_raw(struct aa_perms *accum, struct
aa_perms *addend);
void aa_profile_match_label(struct aa_profile *profile,
struct aa_ruleset *rules, struct aa_label *label,
int type, u32 request, struct aa_perms *perms);
-int aa_profile_label_perm(struct aa_profile *profile, struct aa_profile
*target,
- u32 request, int type, u32 *deny,
- struct apparmor_audit_data *ad);
int aa_check_perms(struct aa_profile *profile, struct aa_perms *perms,
u32 request, struct apparmor_audit_data *ad,
void (*cb)(struct audit_buffer *, void *));
diff --git a/security/apparmor/include/policy.h
b/security/apparmor/include/policy.h
index 75088cc310b6..757e3c232c57 100644
--- a/security/apparmor/include/policy.h
+++ b/security/apparmor/include/policy.h
@@ -264,7 +264,6 @@ void aa_free_profile(struct aa_profile *profile);
struct aa_profile *aa_find_child(struct aa_profile *parent, const char *name);
struct aa_profile *aa_lookupn_profile(struct aa_ns *ns, const char *hname,
size_t n);
-struct aa_profile *aa_lookup_profile(struct aa_ns *ns, const char *name);
struct aa_profile *aa_fqlookupn_profile(struct aa_label *base,
const char *fqname, size_t n);
diff --git a/security/apparmor/include/secid.h
b/security/apparmor/include/secid.h
index a912a5d5d04f..b49dd0253118 100644
--- a/security/apparmor/include/secid.h
+++ b/security/apparmor/include/secid.h
@@ -32,6 +32,5 @@ void apparmor_release_secctx(char *secdata, u32 seclen);
int aa_
[apparmor] AppArmor and kernel capabilities
Good day, I run AppArmor version 2.10.2 on a kernel 4.4 system. I creates a profile for gpg and that profile requested now the capability dac_override. This raises some questions to me. First, does dac_override honor the folder permission rules within the profile? For example, if there is a rule "/foo/** r," does dac_override this rule? If dac_override still honors the folder rules, what then is the point to ask for that capability? Lastly, why is that capability requested at all? Normally AppArmor complains if r/w to a certain file/folder is needed. But, here a capability was requested. Requesting dac_override does not give any hint, what file or folder is required to access... Would be nice if someone could give me a hint on that CAP vs AppArmor issue :-) -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] AppArmor and kernel capabilities
>> This raises some questions to me. First, does dac_override honor the >> folder permission rules within the profile? For example, if there is a >> rule "/foo/** r," does dac_override this rule? >> (...) > So gpg was run as root and tried to read, write, or execute, a file > (or write to a directory) that it did not have access to via the usual > Unix permissions. It was able to operate on the file because it was run > as root and had CAP_DAC_OVERRIDE in its effective permissions. Thanks for explanation. Things look clearer now. But, one thing I still don´t get. Isn´t there a collision between dac_override and permission rules in AA profiles? Assume I have such a read only rule in the profile: audit capability dac_override, /tmp/foo r, does dac_override now grant write access to /tmp/foo or does the rule /tmp/foo r, have more priority than dac_override? To me this looks like a permission collision I am not sure how it get handled Thanks! -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [PATCH 3/7] hv: simplify sysctl registration
From: Luis Chamberlain On Behalf Of Luis Chamberlain
Sent: Thursday, March 2, 2023 12:46 PM
>
> register_sysctl_table() is a deprecated compatibility wrapper.
> register_sysctl() can do the directory creation for you so just use
> that.
>
> Signed-off-by: Luis Chamberlain
> ---
> drivers/hv/vmbus_drv.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index d24dd65b33d4..229353f1e9c2 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -1460,15 +1460,6 @@ static struct ctl_table hv_ctl_table[] = {
> {}
> };
>
> -static struct ctl_table hv_root_table[] = {
> - {
> - .procname = "kernel",
> - .mode = 0555,
> - .child = hv_ctl_table
> - },
> - {}
> -};
> -
> /*
> * vmbus_bus_init -Main vmbus driver initialization routine.
> *
> @@ -1547,7 +1538,7 @@ static int vmbus_bus_init(void)
>* message recording won't be available in isolated
>* guests should the following registration fail.
>*/
> - hv_ctl_table_hdr = register_sysctl_table(hv_root_table);
> + hv_ctl_table_hdr = register_sysctl("kernel", hv_ctl_table);
> if (!hv_ctl_table_hdr)
> pr_err("Hyper-V: sysctl table register error");
>
> --
> 2.39.1
Reviewed-by: Michael Kelley
Re: [GIT PULL] sysctl constification changes for v6.11-rc1
Hello: This pull request was applied to riscv/linux.git (fixes) by Linus Torvalds : On Wed, 24 Jul 2024 23:00:14 +0200 you wrote: > Linus > > Constifying ctl_table structs will prevent the modification of > proc_handler function pointers as they would reside in .rodata. To get > there, the proc_handler arguments must first be const qualified which > requires this (fairly large) treewide PR. Sending it in the tail end of > of the merge window after a suggestion from Kees to avoid unneeded merge > conflicts. It has been rebased on top of > 7a3fad30fd8b4b5e370906b3c554f64026f56c2f. > I can send it later if it makes more sense on your side; please tell me > what you prefer. > > [...] Here is the summary with links: - [GIT,PULL] sysctl constification changes for v6.11-rc1 https://git.kernel.org/riscv/c/f8a8b94d0698 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [GIT PULL] sysctl constification changes for v6.11-rc1
Hello: This pull request was applied to riscv/linux.git (for-next) by Linus Torvalds : On Wed, 24 Jul 2024 23:00:14 +0200 you wrote: > Linus > > Constifying ctl_table structs will prevent the modification of > proc_handler function pointers as they would reside in .rodata. To get > there, the proc_handler arguments must first be const qualified which > requires this (fairly large) treewide PR. Sending it in the tail end of > of the merge window after a suggestion from Kees to avoid unneeded merge > conflicts. It has been rebased on top of > 7a3fad30fd8b4b5e370906b3c554f64026f56c2f. > I can send it later if it makes more sense on your side; please tell me > what you prefer. > > [...] Here is the summary with links: - [GIT,PULL] sysctl constification changes for v6.11-rc1 https://git.kernel.org/riscv/c/b485625078ca You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
