SELinux vs AppArmor applicability
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I am going through some primers on LSM implementations so eventually I am digging a bit into AppArmor
and SELinux
.
I am aware of this discussion but this does not make very clear one question I am having in regard to these two LSM implementations:
Is it a fact that:
- SELinux must be applied system-wide (thus the
auto-relabeling
process on first boot which takes as much time as a filesystem scan) - AppArmor provides the flexibility to define policies only on those processes / scripts you d' like? - via the interactive auditing process)
(?)
security selinux apparmor lsm
add a comment |Â
up vote
1
down vote
favorite
I am going through some primers on LSM implementations so eventually I am digging a bit into AppArmor
and SELinux
.
I am aware of this discussion but this does not make very clear one question I am having in regard to these two LSM implementations:
Is it a fact that:
- SELinux must be applied system-wide (thus the
auto-relabeling
process on first boot which takes as much time as a filesystem scan) - AppArmor provides the flexibility to define policies only on those processes / scripts you d' like? - via the interactive auditing process)
(?)
security selinux apparmor lsm
Yes, both points are correct... And your question is?
– Filipe Brandenburger
3 hours ago
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I am going through some primers on LSM implementations so eventually I am digging a bit into AppArmor
and SELinux
.
I am aware of this discussion but this does not make very clear one question I am having in regard to these two LSM implementations:
Is it a fact that:
- SELinux must be applied system-wide (thus the
auto-relabeling
process on first boot which takes as much time as a filesystem scan) - AppArmor provides the flexibility to define policies only on those processes / scripts you d' like? - via the interactive auditing process)
(?)
security selinux apparmor lsm
I am going through some primers on LSM implementations so eventually I am digging a bit into AppArmor
and SELinux
.
I am aware of this discussion but this does not make very clear one question I am having in regard to these two LSM implementations:
Is it a fact that:
- SELinux must be applied system-wide (thus the
auto-relabeling
process on first boot which takes as much time as a filesystem scan) - AppArmor provides the flexibility to define policies only on those processes / scripts you d' like? - via the interactive auditing process)
(?)
security selinux apparmor lsm
security selinux apparmor lsm
asked 4 hours ago


pkaramol
408213
408213
Yes, both points are correct... And your question is?
– Filipe Brandenburger
3 hours ago
add a comment |Â
Yes, both points are correct... And your question is?
– Filipe Brandenburger
3 hours ago
Yes, both points are correct... And your question is?
– Filipe Brandenburger
3 hours ago
Yes, both points are correct... And your question is?
– Filipe Brandenburger
3 hours ago
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
As I answered to the other question, a major difference between AppArmor and SELinux is labeling. AppArmor is path based while SELinux adds additional label to every object. This is why auto relabeling is done at first boot to apply the default file labels. Otherwise it would not be possible to write meaningful policy for file access, as every file would be considered the same (due having same labels).
Both AppArmor and SELinux have unconfined domains, which do not restrict processes. Both systems also have complain mode (called permissive domain in SELinux), which only log policy violations but not enforce the policy. Both AppArmor and SELinux are enabled system-wide and it is possible in both systems to run processes which are not restricted by the security module.
When it comes to automatic policy generation, both systems have similar tools and mechanisms.
AppArmor profiles can be generated using aa-genprof
and aa-logprof
. aa-genprof
creates a basic profile and sets it in complain mode. After running the program the rules can be generated from log files.
SELinux tools are policygentool
and audit2allow
. The major difference again is the file labeling, but policygentool
can automatically create file types for program data (var), configuration files and log files. The policy can then be loaded in permissive mode and rules can be then generated from logs using audit2allow
.
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
As I answered to the other question, a major difference between AppArmor and SELinux is labeling. AppArmor is path based while SELinux adds additional label to every object. This is why auto relabeling is done at first boot to apply the default file labels. Otherwise it would not be possible to write meaningful policy for file access, as every file would be considered the same (due having same labels).
Both AppArmor and SELinux have unconfined domains, which do not restrict processes. Both systems also have complain mode (called permissive domain in SELinux), which only log policy violations but not enforce the policy. Both AppArmor and SELinux are enabled system-wide and it is possible in both systems to run processes which are not restricted by the security module.
When it comes to automatic policy generation, both systems have similar tools and mechanisms.
AppArmor profiles can be generated using aa-genprof
and aa-logprof
. aa-genprof
creates a basic profile and sets it in complain mode. After running the program the rules can be generated from log files.
SELinux tools are policygentool
and audit2allow
. The major difference again is the file labeling, but policygentool
can automatically create file types for program data (var), configuration files and log files. The policy can then be loaded in permissive mode and rules can be then generated from logs using audit2allow
.
add a comment |Â
up vote
2
down vote
accepted
As I answered to the other question, a major difference between AppArmor and SELinux is labeling. AppArmor is path based while SELinux adds additional label to every object. This is why auto relabeling is done at first boot to apply the default file labels. Otherwise it would not be possible to write meaningful policy for file access, as every file would be considered the same (due having same labels).
Both AppArmor and SELinux have unconfined domains, which do not restrict processes. Both systems also have complain mode (called permissive domain in SELinux), which only log policy violations but not enforce the policy. Both AppArmor and SELinux are enabled system-wide and it is possible in both systems to run processes which are not restricted by the security module.
When it comes to automatic policy generation, both systems have similar tools and mechanisms.
AppArmor profiles can be generated using aa-genprof
and aa-logprof
. aa-genprof
creates a basic profile and sets it in complain mode. After running the program the rules can be generated from log files.
SELinux tools are policygentool
and audit2allow
. The major difference again is the file labeling, but policygentool
can automatically create file types for program data (var), configuration files and log files. The policy can then be loaded in permissive mode and rules can be then generated from logs using audit2allow
.
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
As I answered to the other question, a major difference between AppArmor and SELinux is labeling. AppArmor is path based while SELinux adds additional label to every object. This is why auto relabeling is done at first boot to apply the default file labels. Otherwise it would not be possible to write meaningful policy for file access, as every file would be considered the same (due having same labels).
Both AppArmor and SELinux have unconfined domains, which do not restrict processes. Both systems also have complain mode (called permissive domain in SELinux), which only log policy violations but not enforce the policy. Both AppArmor and SELinux are enabled system-wide and it is possible in both systems to run processes which are not restricted by the security module.
When it comes to automatic policy generation, both systems have similar tools and mechanisms.
AppArmor profiles can be generated using aa-genprof
and aa-logprof
. aa-genprof
creates a basic profile and sets it in complain mode. After running the program the rules can be generated from log files.
SELinux tools are policygentool
and audit2allow
. The major difference again is the file labeling, but policygentool
can automatically create file types for program data (var), configuration files and log files. The policy can then be loaded in permissive mode and rules can be then generated from logs using audit2allow
.
As I answered to the other question, a major difference between AppArmor and SELinux is labeling. AppArmor is path based while SELinux adds additional label to every object. This is why auto relabeling is done at first boot to apply the default file labels. Otherwise it would not be possible to write meaningful policy for file access, as every file would be considered the same (due having same labels).
Both AppArmor and SELinux have unconfined domains, which do not restrict processes. Both systems also have complain mode (called permissive domain in SELinux), which only log policy violations but not enforce the policy. Both AppArmor and SELinux are enabled system-wide and it is possible in both systems to run processes which are not restricted by the security module.
When it comes to automatic policy generation, both systems have similar tools and mechanisms.
AppArmor profiles can be generated using aa-genprof
and aa-logprof
. aa-genprof
creates a basic profile and sets it in complain mode. After running the program the rules can be generated from log files.
SELinux tools are policygentool
and audit2allow
. The major difference again is the file labeling, but policygentool
can automatically create file types for program data (var), configuration files and log files. The policy can then be loaded in permissive mode and rules can be then generated from logs using audit2allow
.
edited 21 mins ago
answered 1 hour ago


sebasth
7,55631745
7,55631745
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f475371%2fselinux-vs-apparmor-applicability%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Yes, both points are correct... And your question is?
– Filipe Brandenburger
3 hours ago