en Copyright 2015 Java http://src.rcs.uwaterloo.ca:8080/source/history/netbsd-src/sys/secmodel/extensions/files.extensions#7d219861d78d0e6779cb2faabcff5e8c4a3386cd secmodel_extensions: Split vfs part into separate .c file.This way we can provide weak rumpkern stubs that don't requirerumpvfs for things that are relevant to vfs, but if you do linkrumpvfs then you get the same logic in secmodel extensions. List of files: /netbsd-src/sys/secmodel/extensions/files.extensions Sat, 22 Apr 2023 13:54:19 +0000 riastradh <riastradh@NetBSD.org> http://src.rcs.uwaterloo.ca:8080/source/history/netbsd-src/sys/secmodel/extensions/files.extensions#926571dfa7ef284889680baba2775046b1ad67ea Implement the register/deregister/evaluation API for secmodel(9). Itallows registration of callbacks that can be used later forcross-secmodel "safe" communication.When a secmodel wishes to know a property maintained by anothersecmodel, it has to submit a request to it so the other secmodel canproceed to evaluating the request. This is done through thesecmodel_eval(9) call; example: bool isroot; error = secmodel_eval("org.netbsd.secmodel.suser", "is-root", cred, &isroot); if (error == 0 && !isroot) result = KAUTH_RESULT_DENY;This one asks the suser module if the credentials are assumed to be rootwhen evaluated by suser module. If the module is present, it willrespond. If absent, the call will return an error.Args and command are arbitrarily defined; it's up to the secmodel(9) todocument what it expects.Typical example is securelevel testing: when someone wants to knowwhether securelevel is raised above a certain level or not, the callerhas to request this property to the secmodel_securelevel(9) module.Given that securelevel module may be absent from system's context (thusmaking access to the global "securelevel" variable impossible orunsafe), this API can cope with this absence and return an error.We are using secmodel_eval(9) to implement a secmodel_extensions(9)module, which plugs with the bsd44, suser and securelevel secmodelsto provide the logic behind curtain, usermount and user_set_cpu_affinitymodes, without adding hooks to traditional secmodels. This solves areal issue with the current secmodel(9) code, as usermount oruser_set_cpu_affinity are not really tied to secmodel_suser(9).The secmodel_eval(9) is also used to restrict security.models settingswhen securelevel is above 0, through the "is-securelevel-above"evaluation:- curtain can be enabled any time, but cannot be disabled ifsecurelevel is above 0.- usermount/user_set_cpu_affinity can be disabled any time, but cannotbe enabled if securelevel is above 0.Regarding sysctl(7) entries:curtain and usermount are now found under security.models.extensionstree. The security.curtain and vfs.generic.usermount are stillaccessible for backwards compat.Documentation is incoming, I am proof-reading my writings.Written by elad@, reviewed and tested (anita test + interact for rightstests) by me. ok elad@.See alsohttp://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.htmlXXX might consider va0 mapping too.XXX Having a secmodel(9) specific printf (like aprint_*) for reportingsecmodel(9) errors might be a good idea, but I am not sure on howto design such a function right now. List of files: /netbsd-src/sys/secmodel/extensions/files.extensions Sun, 04 Dec 2011 19:24:58 +0000 jym <jym@NetBSD.org>