aboutsummaryrefslogtreecommitdiffstats
path: root/security (follow)
AgeCommit message (Collapse)AuthorFilesLines
2019-03-04keys: fix missing __user in KEYCTL_PKEY_QUERYBen Dooks1-1/+1
The arg5 of KEYCTL_PKEY_QUERY should have a __user pointer tag on it as it is a user pointer. This clears the following sparse warning for this: security/keys/keyctl.c:1755:43: warning: incorrect type in argument 3 (different address spaces) security/keys/keyctl.c:1755:43: expected struct keyctl_pkey_query [noderef] <asn:1>*<noident> security/keys/keyctl.c:1755:43: got struct keyctl_pkey_query *<noident> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Acked-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-03-01LSM: Update list of SECURITYFS users in KconfigPetr Vorel1-2/+1
Remove modules not using it (SELinux and SMACK aren't the only ones not using it). Signed-off-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-02-25LSM: Ignore "security=" when "lsm=" is specifiedKees Cook1-2/+6
To avoid potential confusion, explicitly ignore "security=" when "lsm=" is used on the command line, and report that it is happening. Suggested-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Acked-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-02-25LSM: Update function documentation for cap_capableMicah Morton1-1/+1
This should have gone in with commit c1a85a00ea66cb6f0bd0f14e47c28c2b0999799f. Signed-off-by: Micah Morton <mortonm@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-02-22security: mark expected switch fall-throughs and add a missing breakGustavo A. R. Silva5-3/+8
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: security/integrity/ima/ima_template_lib.c:85:10: warning: this statement may fall through [-Wimplicit-fallthrough=] security/integrity/ima/ima_policy.c:940:18: warning: this statement may fall through [-Wimplicit-fallthrough=] security/integrity/ima/ima_policy.c:943:7: warning: this statement may fall through [-Wimplicit-fallthrough=] security/integrity/ima/ima_policy.c:972:21: warning: this statement may fall through [-Wimplicit-fallthrough=] security/integrity/ima/ima_policy.c:974:7: warning: this statement may fall through [-Wimplicit-fallthrough=] security/smack/smack_lsm.c:3391:9: warning: this statement may fall through [-Wimplicit-fallthrough=] security/apparmor/domain.c:569:6: warning: this statement may fall through [-Wimplicit-fallthrough=] Warning level 3 was used: -Wimplicit-fallthrough=3 Also, add a missing break statement to fix the following warning: security/integrity/ima/ima_appraise.c:116:26: warning: this statement may fall through [-Wimplicit-fallthrough=] Acked-by: John Johansen <john.johansen@canonical.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-02-19tomoyo: Bump version.Tetsuo Handa2-8/+13
Update URLs and profile version. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-02-12LSM: fix return value check in safesetid_init_securityfs()Wei Yongjun1-1/+1
In case of error, the function securityfs_create_dir() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: aeca4e2ca65c ("LSM: add SafeSetID module that gates setid calls") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-30LSM: SafeSetID: remove unused includeMicah Morton1-1/+0
The include for asm/syscall.h was needed in a prior version of lsm.c that checked return values of syscall_get_nr, but since we did away with that part of the code this include is no longer necessary. Take out this include since it breaks builds for certain architectures. We no longer have any arch-specific code in SafeSetID. Signed-off-by: Micah Morton <mortonm@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-29LSM: SafeSetID: 'depend' on CONFIG_SECURITYMicah Morton1-0/+2
This patch changes the Kconfig file for the SafeSetID LSM to depend on CONFIG_SECURITY as well as select CONFIG_SECURITYFS, since the policies for the LSM are configured through writing to securityfs. Signed-off-by: Micah Morton <mortonm@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-28LSM: Add 'name' field for SafeSetID in DEFINE_LSMMicah Morton1-0/+1
Without this, system boot was crashing with: [0.174285] LSM: Security Framework initializing [0.175277] BUG: unable to handle kernel NULL pointer dereference ... [0.176272] Call Trace: [0.176272] ordered_lsm_parse+0x112/0x20b [0.176272] security_init+0x9b/0x3ab [0.176272] start_kernel+0x413/0x479 [0.176272] secondary_startup_64+0xa4/0xb0 Signed-off-by: Micah Morton <mortonm@chromium.org> Fixed-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-25LSM: add SafeSetID module that gates setid callsMicah Morton7-1/+526
SafeSetID gates the setid family of syscalls to restrict UID/GID transitions from a given UID/GID to only those approved by a system-wide whitelist. These restrictions also prohibit the given UIDs/GIDs from obtaining auxiliary privileges associated with CAP_SET{U/G}ID, such as allowing a user to set up user namespace UID mappings. For now, only gating the set*uid family of syscalls is supported, with support for set*gid coming in a future patch set. Signed-off-by: Micah Morton <mortonm@chromium.org> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-24tomoyo: Allow multiple use_group lines.Tetsuo Handa3-22/+42
Being able to specify multiple "use_group" lines makes it easier to write whitelisted policies. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-24tomoyo: Coding style fix.Tetsuo Handa15-105/+309
Follow many of recommendations by scripts/checkpatch.pl, and follow "lift switch variables out of switches" by Kees Cook. This patch makes no functional change. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-23tomoyo: Swicth from cred->security to task_struct->security.Tetsuo Handa5-122/+108
TOMOYO security module is designed to use "struct task_struct"->security in order to allow per "struct task_struct" tracking without being disturbed by unable to update "struct cred"->security due to override mechanism. Now that infrastructure-managed security blob is ready, this patch updates TOMOYO to use "struct task_struct"->security. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-22security: keys: annotate implicit fall throughsMathieu Malaterre1-0/+4
There is a plan to build the kernel with -Wimplicit-fallthrough and these places in the code produced warnings (W=1). Fix them up. This commit remove the following warnings: security/keys/request_key.c:293:7: warning: this statement may fall through [-Wimplicit-fallthrough=] security/keys/request_key.c:298:7: warning: this statement may fall through [-Wimplicit-fallthrough=] security/keys/request_key.c:307:7: warning: this statement may fall through [-Wimplicit-fallthrough=] Signed-off-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-22security: keys: annotate implicit fall throughsMathieu Malaterre1-0/+3
There is a plan to build the kernel with -Wimplicit-fallthrough and these places in the code produced warnings (W=1). Fix them up. This commit remove the following warning: security/keys/process_keys.c:380:7: warning: this statement may fall through [-Wimplicit-fallthrough=] security/keys/process_keys.c:404:7: warning: this statement may fall through [-Wimplicit-fallthrough=] security/keys/process_keys.c:424:7: warning: this statement may fall through [-Wimplicit-fallthrough=] Signed-off-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-22security: keys: annotate implicit fall throughMathieu Malaterre1-0/+1
There is a plan to build the kernel with -Wimplicit-fallthrough and this place in the code produced a warning (W=1). This commit remove the following warning: security/keys/keyring.c:248:10: warning: this statement may fall through [-Wimplicit-fallthrough=] Signed-off-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-22apparmor: Adjust offset when accessing task blob.Tetsuo Handa1-1/+1
AppArmor will no longer be the only user of task blob after TOMOYO started using task blob. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Fixes: f4ad8f2c4076 ("LSM: Infrastructure management of the task security") Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-22Merge tag 'v5.0-rc3' into next-generalJames Morris3-2/+12
Sync to Linux 5.0-rc3 to pull in the VFS changes which impacted a lot of the LSM code.
2019-01-18LSM: Make some functions staticWei Yongjun1-3/+3
Fixes the following sparse warnings: security/security.c:533:5: warning: symbol 'lsm_task_alloc' was not declared. Should it be static? security/security.c:554:5: warning: symbol 'lsm_ipc_alloc' was not declared. Should it be static? security/security.c:575:5: warning: symbol 'lsm_msg_msg_alloc' was not declared. Should it be static? Fixes: f4ad8f2c4076 ("LSM: Infrastructure management of the task security") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-18LSM: Make lsm_early_cred() and lsm_early_task() local functions.Tetsuo Handa5-22/+11
Since current->cred == current->real_cred when ordered_lsm_init() is called, and lsm_early_cred()/lsm_early_task() need to be called between the amount of required bytes is determined and module specific initialization function is called, we can move these calls from individual modules to ordered_lsm_init(). Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-17Merge branch 'fixes-v5.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-securityLinus Torvalds2-1/+10
Pull security subsystem fixes from James Morris: "Fixes for the security subsystem. The first (by Casey actually - it's misattributed) fixes a regression introduced with the LSM stacking changes" * 'fixes-v5.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: LSM: Check for NULL cred-security on free Yama: Check for pid death before checking ancestry seccomp: fix UAF in user-trap code
2019-01-16LSM: Check for NULL cred-security on freeJames Morris1-0/+7
From: Casey Schaufler <casey@schaufler-ca.com> Check that the cred security blob has been set before trying to clean it up. There is a case during credential initialization that could result in this. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Acked-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <james.morris@microsoft.com> Reported-by: syzbot+69ca07954461f189e808@syzkaller.appspotmail.com
2019-01-16Yama: Check for pid death before checking ancestryKees Cook1-1/+3
It's possible that a pid has died before we take the rcu lock, in which case we can't walk the ancestry list as it may be detached. Instead, check for death first before doing the walk. Reported-by: syzbot+a9ac39bf55329e206219@syzkaller.appspotmail.com Fixes: 2d514487faf1 ("security: Yama LSM") Cc: stable@vger.kernel.org Suggested-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-16Merge tag 'selinux-pr-20190115' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinuxLinus Torvalds1-1/+2
Pull SELinux fix from Paul Moore: "One small patch to fix a potential NULL dereference on a failed SELinux policy load" * tag 'selinux-pr-20190115' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux: selinux: fix GPF on invalid policy
2019-01-10selinux: fix GPF on invalid policyStephen Smalley1-1/+2
levdatum->level can be NULL if we encounter an error while loading the policy during sens_read prior to initializing it. Make sure sens_destroy handles that case correctly. Reported-by: syzbot+6664500f0f18f07a5c0e@syzkaller.appspotmail.com Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com>
2019-01-10LSM: generalize flag passing to security_capableMicah Morton9-39/+37
This patch provides a general mechanism for passing flags to the security_capable LSM hook. It replaces the specific 'audit' flag that is used to tell security_capable whether it should log an audit message for the given capability check. The reason for generalizing this flag passing is so we can add an additional flag that signifies whether security_capable is being called by a setid syscall (which is needed by the proposed SafeSetID LSM). Signed-off-by: Micah Morton <mortonm@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-08TOMOYO: Update LSM flags to no longer be exclusiveKees Cook1-1/+1
With blob sharing in place, TOMOYO is no longer an exclusive LSM, so it can operate separately now. Mark it as such. Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08LSM: Infrastructure management of the ipc security blobCasey Schaufler5-121/+108
Move management of the kern_ipc_perm->security and msg_msg->security blobs out of the individual security modules and into the security infrastructure. Instead of allocating the blobs from within the modules the modules tell the infrastructure how much space is required, and the space is allocated there. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08Smack: Abstract use of ipc security blobsCasey Schaufler2-5/+20
Don't use the ipc->security pointer directly. Don't use the msg_msg->security pointer directly. Provide helper functions that provides the security blob pointers. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08SELinux: Abstract use of ipc security blobsCasey Schaufler2-9/+22
Don't use the ipc->security pointer directly. Don't use the msg_msg->security pointer directly. Provide helper functions that provides the security blob pointers. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08LSM: Infrastructure management of the task securityCasey Schaufler3-27/+60
Move management of the task_struct->security blob out of the individual security modules and into the security infrastructure. Instead of allocating the blobs from within the modules the modules tell the infrastructure how much space is required, and the space is allocated there. The only user of this blob is AppArmor. The AppArmor use is abstracted to avoid future conflict. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08LSM: Infrastructure management of the inode securityCasey Schaufler5-98/+90
Move management of the inode->i_security blob out of the individual security modules and into the security infrastructure. Instead of allocating the blobs from within the modules the modules tell the infrastructure how much space is required, and the space is allocated there. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08Smack: Abstract use of inode security blobCasey Schaufler2-18/+23
Don't use the inode->i_security pointer directly. Provide a helper function that provides the security blob pointer. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08SELinux: Abstract use of inode security blobCasey Schaufler3-15/+21
Don't use the inode->i_security pointer directly. Provide a helper function that provides the security blob pointer. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08LSM: Infrastructure management of the file securityCasey Schaufler7-51/+71
Move management of the file->f_security blob out of the individual security modules and into the infrastructure. The modules no longer allocate or free the data, instead they tell the infrastructure how much space they require. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08Smack: Abstract use of file security blobCasey Schaufler2-4/+13
Don't use the file->f_security pointer directly. Provide a helper function that provides the security blob pointer. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08SELinux: Abstract use of file security blobCasey Schaufler2-9/+14
Don't use the file->f_security pointer directly. Provide a helper function that provides the security blob pointer. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08Infrastructure management of the cred security blobCasey Schaufler10-102/+150
Move management of the cred security blob out of the security modules and into the security infrastructre. Instead of allocating and freeing space the security modules tell the infrastructure how much space they require. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08TOMOYO: Abstract use of cred security blobCasey Schaufler4-16/+64
Don't use the cred->security pointer directly. Provide helper functions that provide the security blob pointer. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08AppArmor: Abstract use of cred security blobCasey Schaufler4-10/+24
Don't use the cred->security pointer directly. Provide a helper function that provides the security blob pointer. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08SELinux: Remove unused selinux_is_enabledCasey Schaufler5-29/+1
There are no longer users of selinux_is_enabled(). Remove it. As selinux_is_enabled() is the only reason for include/linux/selinux.h remove that as well. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08SELinux: Remove cred security blob poisoningCasey Schaufler1-6/+0
The SELinux specific credential poisioning only makes sense if SELinux is managing the credentials. As the intent of this patch set is to move the blob management out of the modules and into the infrastructure, the SELinux specific code has to go. The poisioning could be introduced into the infrastructure at some later date. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08SELinux: Abstract use of cred security blobCasey Schaufler3-29/+34
Don't use the cred->security pointer directly. Provide a helper function that provides the security blob pointer. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08Smack: Abstract use of cred security blobCasey Schaufler4-43/+53
Don't use the cred->security pointer directly. Provide a helper function that provides the security blob pointer. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08procfs: add smack subdir to attrsCasey Schaufler1-4/+20
Back in 2007 I made what turned out to be a rather serious mistake in the implementation of the Smack security module. The SELinux module used an interface in /proc to manipulate the security context on processes. Rather than use a similar interface, I used the same interface. The AppArmor team did likewise. Now /proc/.../attr/current will tell you the security "context" of the process, but it will be different depending on the security module you're using. This patch provides a subdirectory in /proc/.../attr for Smack. Smack user space can use the "current" file in this subdirectory and never have to worry about getting SELinux attributes by mistake. Programs that use the old interface will continue to work (or fail, as the case may be) as before. The proposed S.A.R.A security module is dependent on the mechanism to create its own attr subdirectory. The original implementation is by Kees Cook. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08capability: Initialize as LSM_ORDER_FIRSTKees Cook2-6/+8
This converts capabilities to use the new LSM_ORDER_FIRST position. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
2019-01-08LSM: Introduce enum lsm_orderKees Cook1-1/+8
In preparation for distinguishing the "capability" LSM from other LSMs, it must be ordered first. This introduces LSM_ORDER_MUTABLE for the general LSMs and LSM_ORDER_FIRST for capability. In the future LSM_ORDER_LAST for could be added for anything that must run last (e.g. Landlock may use this). Signed-off-by: Kees Cook <keescook@chromium.org>
2019-01-08Yama: Initialize as ordered LSMKees Cook3-3/+8
This converts Yama from being a direct "minor" LSM into an ordered LSM. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
2019-01-08LoadPin: Initialize as ordered LSMKees Cook3-40/+8
This converts LoadPin from being a direct "minor" LSM into an ordered LSM. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.