Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upSmackfs interfaces #1513
Smackfs interfaces #1513
Conversation
This comment has been minimized.
This comment has been minimized.
codecov-io
commented
Nov 21, 2019
•
Codecov Report
@@ Coverage Diff @@
## master #1513 +/- ##
==========================================
- Coverage 56.2% 56.16% -0.05%
==========================================
Files 142 142
Lines 26415 26415
==========================================
- Hits 14847 14835 -12
- Misses 10859 10869 +10
- Partials 709 711 +2
Continue to review full report at Codecov.
|
| level fmt[dec, int8[0:SMACK_CIPSO_MAXLEVEL]] | ||
| sp1 const[' ', int8] | ||
| # SMK_DIGITLEN | ||
| # TODO: num fmt[dec, len[cats, int8]] |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
evdenis
Nov 21, 2019
•
Author
Contributor
It doesn't work:
$ make generate
smack.txt:88:15: wrong number of arguments for type len, expect len target
This works:
num fmt[dec, len[cats]]
I think that it will use intptr in this case.
However, we need int8 here because of: https://www.kernel.org/doc/html/latest/admin-guide/LSM/Smack.html
cipso2
This interface allows a specific CIPSO header to be assigned to a Smack label. The format accepted on write is:"%s%4d%4d"["%4d"]...
Actually, it's not a "%4d" it's "%3d" with whitespace. This len is in [0:184] https://elixir.bootlin.com/linux/v5.4-rc8/source/security/smack/smackfs.c#L887
This comment has been minimized.
This comment has been minimized.
dvyukov
Nov 21, 2019
Collaborator
Using fmt[dec, len[cats]] looks better to me. We will have the correct length and unless the array itself contains more than 184 elements, this value will be correct as well.
This comment has been minimized.
This comment has been minimized.
evdenis
Nov 21, 2019
Author
Contributor
Done. I just hope it will not add leading zeroes. It's not clear to me what input will be generated in this case.
"fmt": a string representation of an integer (not zero-terminated), type-options:
format (one of "dec", "hex", "oct") and the value (a resource, int, flags, const or proc)
the resulting data is always fixed-size (formatted as "%020llu", "0x%016llx" or "%023llo", respectively)
Smack expects here exactly 3-size number, e.g.: 001, 183, 010...
This comment has been minimized.
This comment has been minimized.
dvyukov
Nov 22, 2019
Collaborator
Ah, I see. Yes, it won't format numbers this ways, but int8 won't help either.
The problem is that we still don't support for dynamically-sized arguments. Say an array is variable size, but once a program is generated its size is known. Whereas if we want to sprintf a dynamic number (e.g. a pid) we don't know until the runtime how many digits it will take. So the current format is a simplified version that always pads numbers to max size.
But actually this case is yet different b/c for %03d we do know the resulting size.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Cool! I see /sys/fs/smackfs is automounted when smack is enabled, so we shouldn't need anything else for syzbot to test this. |
This comment has been minimized.
This comment has been minimized.
As far as I understand there is no "permissive" mode in smack. Thus, I use this patch to force it:
Otherwise it is better to not touch onlycap interface (and maybe some others, syslog?, ptrace?) during fuzzing. It will result in connection loss and no-output errors.
Maybe @cschaufler could provide some hints. |
This comment has been minimized.
This comment has been minimized.
cschaufler
commented
Nov 21, 2019
|
Smack has no permissive mode. This is intentional. Your patch
should be effective in disabling the enforcement of Smack policy.
Results you get while doing any sort of testing using the patch
have to be considered questionable, because it's probable you won't
have gotten to the failing path had enforcement been in place.
If a problem can't be reproduced without "permissive mode", and
isn't "obviously broken" code, (there may well be some) it isn't
going to be high on my fix list.
onlycap is painfully restrictive. That's what it is for. :)
syslog and ptrace should be less of an issue for fuzzing, although
syslog may interfere with your data gathering.
…On 11/21/2019 4:53 AM, Denis Efremov wrote:
Cool! I see /sys/fs/smackfs is automounted when smack is enabled, so we shouldn't need anything else for syzbot to test this.
As far as I understand there is no "permissive" mode in smack. Thus, I use this patch to force it:
|diff --git a/security/smack/smack_access.c b/security/smack/smack_access.c index 38ac3da4e791..ec59c06cd491 100644 --- a/security/smack/smack_access.c +++ b/security/smack/smack_access.c @@ -12,6 +12,9 @@ #include <linux/sched.h> #include "smack.h" +#undef EACCES +#define EACCES 0 + struct smack_known smack_known_huh = { .smk_known = "?", .smk_secid = 2, @@ -638,7 +641,7 @@ bool smack_privileged_cred(int cap, const struct cred *cred) rc = cap_capable(cred, &init_user_ns, cap, CAP_OPT_NONE); if (rc) - return false; + return true; rcu_read_lock(); if (list_empty(&smack_onlycap_list)) { @@ -654,7 +657,7 @@ bool smack_privileged_cred(int cap, const struct cred *cred) } rcu_read_unlock(); - return false; + return true; } /** diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c index abeb09c30633..1c0f72525ad6 100644 --- a/security/smack/smack_lsm.c +++ b/security/smack/smack_lsm.c @@ -44,6 +44,9 @@ #include <linux/fs_parser.h> #include "smack.h" +#undef EACCES
+#define EACCES 0 + #define TRANS_TRUE "TRUE" #define TRANS_TRUE_SIZE 4 |
Otherwise it is better to not touch onlycap interface (and maybe some others, syslog?, ptrace?) during fuzzing. It will result in connection loss and no-output errors.
onlycap
This contains labels processes must have for CAP_MAC_ADMIN and CAP_MAC_OVERRIDE to be effective.
Maybe @cschaufler <https://github.com/cschaufler> could provide some hints.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1513?email_source=notifications&email_token=AAJ5L7FAKNFSLHPV63VZZETQU2AFTA5CNFSM4JP45SU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE2D3XY#issuecomment-557071839>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ5L7AIILR5HV7GDO7E7ZDQU2AFTANCNFSM4JP45SUQ>.
|
This comment has been minimized.
This comment has been minimized.
|
You would suggest to disable /sys/fs/smackfs/onlycap on syzbot then, right? Is so, please split the openat that opens it into 2, so that we can disable only onlycap and not relabel-self. And also add a comment that it changes global restrictive policy and may need to be disabled. |
This comment has been minimized.
This comment has been minimized.
In my experience
Done. |
This comment has been minimized.
This comment has been minimized.
cschaufler
commented
Nov 21, 2019
|
/sys/fs/smackfs/ambient controls the treatment of network packets
received without CIPSO IP options. If you are using IP protocols to
communicate with the system under test and change the "ambient" value
you are likely to lose communications.
/sys/fs/smackfs/unconfined temporarily sets a particular Smack label
as exempt from policy. This is very dangerous, and can result in a process
inadvertently creating files that can't be accessed by others who would
normally be allowed. It's for system bring-up purposes.
…On 11/21/2019 2:42 PM, Denis Efremov wrote:
You would suggest to disable /sys/fs/smackfs/onlycap on syzbot then, right?
In my experience |openat$smackfs_ambient| and |openat$smackfs_unconfined| results in frequent non-reproducible connection loss reports. I don't know is this a real issue or not, but if you want to avoid it then you need to disable them. I think that disabling onlycap will result in better coverage.
Is so, please split the openat that opens it into 2, so that we can disable only onlycap and not relabel-self. And also add a comment that it changes global restrictive policy and may need to be disabled.
Done.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1513?email_source=notifications&email_token=AAJ5L7CILPH27RHYOJEHZITQU4FGDA5CNFSM4JP45SU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE3463I#issuecomment-557305709>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ5L7HNCYJ3XOLJEIJZWZ3QU4FGDANCNFSM4JP45SUQ>.
|
e89749e
into
google:master
This comment has been minimized.
This comment has been minimized.
|
I will do:
on syzbot. The smack instance tests whole kernel, so breaking machines frequently won't be good. |
This comment has been minimized.
This comment has been minimized.
|
Thanks for the clarification! Yes, I think this will be a right choice to disable them. Thanks! |
evdenis commentedNov 21, 2019
Add descriptions for /sys/fs/smackfs/* interfaces.
Allowed to find out-of-bounds read in smk_set_cipso(): https://lkml.org/lkml/2019/11/20/633
Signed-off-by: Denis Efremov efremov@linux.com