Lines Matching refs:be
14 uncontrolled access can be devastating [#attackf]_.
41 should have. This knowledge will be necessary for the review process
49 Finally, the document covers how changes are to be made to this
55 Designing an open software system such as Zephyr to be secure requires
61 protection mechanisms cannot be kept secret on any system in
64 well established cryptographic libraries shall be used.
67 system shall be kept as simple and small as possible. In the context
68 of the Zephyr project, this can be realized, e.g., by modular code
72 process needs to be authenticated first. Mechanisms to store access
73 conditions shall be avoided if possible.
78 Furthermore, default settings for services shall be chosen in a way
83 more need to be satisfied before access is granted. In the context
93 than one user or process shall not be shared if not strictly
94 required. The example given in [SALT75]_ is a function that should be
110 shall be used.
114 shall not be enabled by default if they are only rarely used (a
116 be realized using the configuration management. Each functionality
117 and module shall be represented as a configuration option and needs
118 to be explicitly enabled. Then, all features, protocols, and drivers
119 not required for a particular use case can be disabled. The user
120 shall be notified if low-level options and APIs are enabled but not
126 validation phase. In each stage, appropriate documentation shall be
127 provided. All commits shall be related to a bug report or change
129 shall be denied.
147 projects' installation shall be secure by default)
149 - complete mediation (every access that might be limited must be
150 checked for authority and be non-bypassable)
173 - psychological acceptability (the human interface must be designed
179 - input validation with whitelists (inputs should typically be checked
192 Developers would typically be considered primary developers if they
230 There shall be a "Zephyr Security Subcommittee", responsible for
234 This team will be established according to the Zephyr Project charter.
240 required to go through. Each change shall be reviewed by at least one
253 that can be used to record and track defects that are found in the
261 Subcommittee. In addition, there shall be a
265 This embargo, or limited visibility, shall only be for a fixed
268 project itself, it may be necessary to increase this embargo time.
269 The time necessary shall be clearly annotated in the issue itself.
271 The list of issues shall be reviewed at least once a month by the
273 tracking the fixes, determining if any external parties need to be
275 issue. The embargo should **not** be lifted via an automated means, but
282 Changes to this document shall be reviewed by the Zephyr Security Subcommittee,