Searched hist:187016 (Results 1 - 14 of 14) sorted by relevance
/freebsd-10.3-release/sys/security/mac_ifoff/ | ||
H A D | mac_ifoff.c | diff 187016 Sat Jan 10 11:02:08 MST 2009 rwatson Rather than having MAC policies explicitly declare what object types they label, derive that information implicitly from the set of label initializers in their policy operations set. This avoids a possible class of programmer errors, while retaining the structure that allows us to avoid allocating labels for objects that don't need them. As before, we regenerate a global mask of labeled objects each time a policy is loaded or unloaded, stored in mac_labeled. Discussed with: csjp Suggested by: Jacques Vidrine <nectar at apple.com> Obtained from: TrustedBSD Project Sponsored by: Apple, Inc. |
/freebsd-10.3-release/sys/security/mac_portacl/ | ||
H A D | mac_portacl.c | diff 187016 Sat Jan 10 11:02:08 MST 2009 rwatson Rather than having MAC policies explicitly declare what object types they label, derive that information implicitly from the set of label initializers in their policy operations set. This avoids a possible class of programmer errors, while retaining the structure that allows us to avoid allocating labels for objects that don't need them. As before, we regenerate a global mask of labeled objects each time a policy is loaded or unloaded, stored in mac_labeled. Discussed with: csjp Suggested by: Jacques Vidrine <nectar at apple.com> Obtained from: TrustedBSD Project Sponsored by: Apple, Inc. |
/freebsd-10.3-release/sys/security/mac_seeotheruids/ | ||
H A D | mac_seeotheruids.c | diff 187016 Sat Jan 10 11:02:08 MST 2009 rwatson Rather than having MAC policies explicitly declare what object types they label, derive that information implicitly from the set of label initializers in their policy operations set. This avoids a possible class of programmer errors, while retaining the structure that allows us to avoid allocating labels for objects that don't need them. As before, we regenerate a global mask of labeled objects each time a policy is loaded or unloaded, stored in mac_labeled. Discussed with: csjp Suggested by: Jacques Vidrine <nectar at apple.com> Obtained from: TrustedBSD Project Sponsored by: Apple, Inc. |
/freebsd-10.3-release/sys/security/mac_none/ | ||
H A D | mac_none.c | diff 187016 Sat Jan 10 11:02:08 MST 2009 rwatson Rather than having MAC policies explicitly declare what object types they label, derive that information implicitly from the set of label initializers in their policy operations set. This avoids a possible class of programmer errors, while retaining the structure that allows us to avoid allocating labels for objects that don't need them. As before, we regenerate a global mask of labeled objects each time a policy is loaded or unloaded, stored in mac_labeled. Discussed with: csjp Suggested by: Jacques Vidrine <nectar at apple.com> Obtained from: TrustedBSD Project Sponsored by: Apple, Inc. |
/freebsd-10.3-release/sys/security/mac_partition/ | ||
H A D | mac_partition.c | diff 187016 Sat Jan 10 11:02:08 MST 2009 rwatson Rather than having MAC policies explicitly declare what object types they label, derive that information implicitly from the set of label initializers in their policy operations set. This avoids a possible class of programmer errors, while retaining the structure that allows us to avoid allocating labels for objects that don't need them. As before, we regenerate a global mask of labeled objects each time a policy is loaded or unloaded, stored in mac_labeled. Discussed with: csjp Suggested by: Jacques Vidrine <nectar at apple.com> Obtained from: TrustedBSD Project Sponsored by: Apple, Inc. |
/freebsd-10.3-release/sys/security/mac_bsdextended/ | ||
H A D | mac_bsdextended.c | diff 187016 Sat Jan 10 11:02:08 MST 2009 rwatson Rather than having MAC policies explicitly declare what object types they label, derive that information implicitly from the set of label initializers in their policy operations set. This avoids a possible class of programmer errors, while retaining the structure that allows us to avoid allocating labels for objects that don't need them. As before, we regenerate a global mask of labeled objects each time a policy is loaded or unloaded, stored in mac_labeled. Discussed with: csjp Suggested by: Jacques Vidrine <nectar at apple.com> Obtained from: TrustedBSD Project Sponsored by: Apple, Inc. |
/freebsd-10.3-release/sys/security/mac_lomac/ | ||
H A D | mac_lomac.c | diff 187016 Sat Jan 10 11:02:08 MST 2009 rwatson Rather than having MAC policies explicitly declare what object types they label, derive that information implicitly from the set of label initializers in their policy operations set. This avoids a possible class of programmer errors, while retaining the structure that allows us to avoid allocating labels for objects that don't need them. As before, we regenerate a global mask of labeled objects each time a policy is loaded or unloaded, stored in mac_labeled. Discussed with: csjp Suggested by: Jacques Vidrine <nectar at apple.com> Obtained from: TrustedBSD Project Sponsored by: Apple, Inc. |
/freebsd-10.3-release/sys/security/mac_stub/ | ||
H A D | mac_stub.c | diff 187016 Sat Jan 10 11:02:08 MST 2009 rwatson Rather than having MAC policies explicitly declare what object types they label, derive that information implicitly from the set of label initializers in their policy operations set. This avoids a possible class of programmer errors, while retaining the structure that allows us to avoid allocating labels for objects that don't need them. As before, we regenerate a global mask of labeled objects each time a policy is loaded or unloaded, stored in mac_labeled. Discussed with: csjp Suggested by: Jacques Vidrine <nectar at apple.com> Obtained from: TrustedBSD Project Sponsored by: Apple, Inc. |
/freebsd-10.3-release/sys/security/mac/ | ||
H A D | mac_framework.c | diff 187016 Sat Jan 10 11:02:08 MST 2009 rwatson Rather than having MAC policies explicitly declare what object types they label, derive that information implicitly from the set of label initializers in their policy operations set. This avoids a possible class of programmer errors, while retaining the structure that allows us to avoid allocating labels for objects that don't need them. As before, we regenerate a global mask of labeled objects each time a policy is loaded or unloaded, stored in mac_labeled. Discussed with: csjp Suggested by: Jacques Vidrine <nectar at apple.com> Obtained from: TrustedBSD Project Sponsored by: Apple, Inc. |
H A D | mac_internal.h | diff 187016 Sat Jan 10 11:02:08 MST 2009 rwatson Rather than having MAC policies explicitly declare what object types they label, derive that information implicitly from the set of label initializers in their policy operations set. This avoids a possible class of programmer errors, while retaining the structure that allows us to avoid allocating labels for objects that don't need them. As before, we regenerate a global mask of labeled objects each time a policy is loaded or unloaded, stored in mac_labeled. Discussed with: csjp Suggested by: Jacques Vidrine <nectar at apple.com> Obtained from: TrustedBSD Project Sponsored by: Apple, Inc. |
H A D | mac_policy.h | diff 187016 Sat Jan 10 11:02:08 MST 2009 rwatson Rather than having MAC policies explicitly declare what object types they label, derive that information implicitly from the set of label initializers in their policy operations set. This avoids a possible class of programmer errors, while retaining the structure that allows us to avoid allocating labels for objects that don't need them. As before, we regenerate a global mask of labeled objects each time a policy is loaded or unloaded, stored in mac_labeled. Discussed with: csjp Suggested by: Jacques Vidrine <nectar at apple.com> Obtained from: TrustedBSD Project Sponsored by: Apple, Inc. |
/freebsd-10.3-release/sys/security/mac_biba/ | ||
H A D | mac_biba.c | diff 187016 Sat Jan 10 11:02:08 MST 2009 rwatson Rather than having MAC policies explicitly declare what object types they label, derive that information implicitly from the set of label initializers in their policy operations set. This avoids a possible class of programmer errors, while retaining the structure that allows us to avoid allocating labels for objects that don't need them. As before, we regenerate a global mask of labeled objects each time a policy is loaded or unloaded, stored in mac_labeled. Discussed with: csjp Suggested by: Jacques Vidrine <nectar at apple.com> Obtained from: TrustedBSD Project Sponsored by: Apple, Inc. |
/freebsd-10.3-release/sys/security/mac_mls/ | ||
H A D | mac_mls.c | diff 187016 Sat Jan 10 11:02:08 MST 2009 rwatson Rather than having MAC policies explicitly declare what object types they label, derive that information implicitly from the set of label initializers in their policy operations set. This avoids a possible class of programmer errors, while retaining the structure that allows us to avoid allocating labels for objects that don't need them. As before, we regenerate a global mask of labeled objects each time a policy is loaded or unloaded, stored in mac_labeled. Discussed with: csjp Suggested by: Jacques Vidrine <nectar at apple.com> Obtained from: TrustedBSD Project Sponsored by: Apple, Inc. |
/freebsd-10.3-release/sys/security/mac_test/ | ||
H A D | mac_test.c | diff 187016 Sat Jan 10 11:02:08 MST 2009 rwatson Rather than having MAC policies explicitly declare what object types they label, derive that information implicitly from the set of label initializers in their policy operations set. This avoids a possible class of programmer errors, while retaining the structure that allows us to avoid allocating labels for objects that don't need them. As before, we regenerate a global mask of labeled objects each time a policy is loaded or unloaded, stored in mac_labeled. Discussed with: csjp Suggested by: Jacques Vidrine <nectar at apple.com> Obtained from: TrustedBSD Project Sponsored by: Apple, Inc. |
Completed in 429 milliseconds