On 2013-02-12 10:56:54, Tim Gardner wrote:
> smatch analysis:
>
> fs/ecryptfs/keystore.c:1206 decrypt_pki_encrypted_session_key() info:
> redundant null check on msg calling kfree()
>
> Cc: Tyler Hicks
> Cc: Dustin Kirkland
> Cc: ecryp...@vger.kernel.org
> Signed-o
On 2013-02-12 11:03:49, Tim Gardner wrote:
> smatch analysis:
>
> fs/ecryptfs/messaging.c:101 ecryptfs_msg_ctx_alloc_to_free() info:
> redundant null check on msg_ctx->msg calling kfree()
>
> Cc: Tyler Hicks
> Cc: Dustin Kirkland
> Cc: ecryp...@vger.kernel.org
&
ing the /dev/ecryptfs node.
>
> Signed-off-by: Kees Cook
> Cc: Tyler Hicks
Thanks for the patch, Kees!
I took a glance over the code and noticed that ECRYPTFS_VERSIONING_MASK
needs some adjusting. Its value is what is used to populate the
/sys/fs/ecryptfs/version mask and ecryptfs-utils u
flush().
- Fixes a regression, introduced in 2.6.39, when a file is renamed on top of
another file. The target file's inode was not being evicted and the space
taken by the file was not reclaimed until eCryptfs was unmounted.
--------
rrected patch to stable@v.k.o. Thanks!
Tyler
>
> --
>
> From: Tyler Hicks
>
> commit 4a26620df451ad46151ad21d711ed43e963c004e upstream.
>
> BugLink: http://bugs.launchpad.net/bugs/885744
>
> statfs() calls on eCryptfs files returned the wr
On 2012-10-23 13:03:39, Kees Cook wrote:
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
>
> CC: Tyler Hicks
Kees - Please push this through your tree. Thanks!
veral code cleanups
Matthew Wilcox (1):
Use ecryptfs_dentry_to_lower_path in a couple of places
Thomas Meyer (1):
eCryptfs: Cocci spatch "memdup.spatch"
Tyler Hicks (10):
eCryptfs: Use entire helper pag
On 2013-08-13 15:02:27, Kees Cook wrote:
> It might be possible for two callers to race the mutex lock after the
> NULL ctx check. Instead, move the lock above the check so there isn't
> the possibility of leaking a crypto ctx. Additionally, report the full
> algo name when failing.
>
> Signed-off
Hi Linus,
The following changes since commit 4de9ad9bc08b4953fc03336ad38908496e2f8826:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile
(2013-09-06 11:14:33 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs
x speedup.
>
> Signed-off-by: Li Wang
> Signed-off-by: Yunchuan Wen
> Reviewed-by: Tyler Hicks
Thanks again, Li. I've pushed this to my next branch.
I lost track of it last time. Sorry about that!
Tyler
> ---
> fs/ecryptfs/mmap.c | 12 ++--
> 1 files changed, 10
Hi Linus,
The following changes since commit 0e4a43ed08e2f44aa7b96aa95d0a540d675483e1:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes
(2012-11-07 13:38:56 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptf
Error out of ecryptfs_fsync() if filemap_write_and_wait() fails.
Signed-off-by: Tyler Hicks
Cc: Paul Taysom
Cc: Olof Johansson
---
After giving Paul's patch one more look, I noticed that we were ignoring
filemap_write_and_wait()'s return value. I plan to push this patch along w
* A couple of MAINTAINERS updates
Dustin Kirkland (1):
Update eCryptFS maintainers
Paul Taysom (1):
ecryptfs: fixed msync to flush data
Tyler Hicks (1):
eCryptfs: Check return of filemap_write_and_wait during fsync
On 2013-06-01 11:39:36, Thomas Meyer wrote:
>
> Signed-off-by: Thomas Meyer
> ---
Thanks Thomas - I've pushed this to my next branch.
Tyler
>
> diff -u -p a/fs/ecryptfs/messaging.c b/fs/ecryptfs/messaging.c
> --- a/fs/ecryptfs/messaging.c
> +++ b/fs/ecryptfs/messaging.c
> @@ -247,14 +247,13 @
ing the /dev/ecryptfs node.
>
> Signed-off-by: Kees Cook
> Cc: Tyler Hicks
> ---
>
> v2:
> - update version mask to reflect messaging feature presence.
Thanks for v2. I've pushed it to my next branch.
Tyler
>
> ---
> fs/ecryptfs/Kconfig |8 +
ablkcipher crypto API. The improvement is more
apparent on faster storage devices. There's no noticeable change when hardware
crypto is not available.
Tyler Hicks (1):
eCryptfs: Use the ablkcipher crypto API
fs/ecryptfs/cry
On 2013-05-23 14:31:43, Paul Taysom wrote:
> When msync is called on a memory mapped file, that
> data is not flushed to the disk.
>
> In Linux, msync calls fsync for the file. For ecryptfs,
> fsync just calls the lower level file system's fsync.
> Changed the ecryptfs fsync code to call filemap_w
Gardner (2):
eCryptfs: decrypt_pki_encrypted_session_key(): remove kfree() redundant
null check
ecryptfs: ecryptfs_msg_ctx_alloc_to_free(): remove kfree() redundant null
check
Tyler Hicks (3):
eCryptfs: Fix -Wunused-but-set-variable warnings
eCryptfs: Fix -Wmissing-prototype
tfs cipher support at mount
Tyler Hicks (6):
eCryptfs: Copy up POSIX ACL and read-only flags from lower mount
eCryptfs: Remove unused messaging declarations and function
eCryptfs: Make all miscdev functions use daemon ptr in file private_data
eCryptfs: Unlink lower
gt;
> Resolves Launchpad issue #338914, reported by Tyler Hicks in 03/2009.
> https://bugs.launchpad.net/ecryptfs/+bug/338914
Hey Tim - Thanks for digging this one out of the bug tracker. :)
>
> Signed-off-by: Tim Sally
> ---
> fs/ecryptfs/main.c | 24 +
r of users that use the miscdev
interface. I was able to keep the changes minimal and I have some cleaner, more
complete changes queued up for the next merge window that will build on these
patches.
--------
Tyler Hicks (3):
eCryptfs: Pro
On 06/09/2016 03:31 PM, Chris J Arges wrote:
> Noticed some minor spelling errors when looking through the code.
>
> Signed-off-by: Chris J Arges
Hey Chris - thanks for these fixups. The first two hunks
(respresentation -> representation) were already fixed by an older patch
that is pending in t
On 10/30/2017 10:03 AM, Jeff Layton wrote:
> On Mon, 2017-10-30 at 11:01 -0400, Jeff Layton wrote:
>> From: Jeff Layton
>>
>> There is no need to bump the i_version counter here, as ecryptfs does
>> not set the MS_I_VERSION flag, and doesn't use it internally. It also
>
> My apologies, I've been
On 10/24/2017 06:46 PM, Dave Jones wrote:
> (Triggered with trinity, but it seems just a 'cat
> /proc/sys/kernel/seccomp/actions_logged' reproduces just as easily).
Hi Dave - Thanks for the report. This is a false positive that was
previously discussed here:
https://lkml.kernel.org/r/<20171010182
tale eCryptfs dcache entries caused by unlinked lower inodes
Markus Elfring (1):
eCryptfs: Delete a check before the function call "key_put"
Tyler Hicks (1):
eCryptfs: Invalidate dcache entries when lower
When creating various bridge objects in /sys/class/net/... make sure
that they belong to the container's owner instead of global root (if
they belong to a container/namespace).
Signed-off-by: Tyler Hicks
---
net/bridge/br_if.c | 9 +
net/bridge/br_private.h | 2 ++
net/b
_dir() are left alone
and always create objects belonging to the global root.
When creating symlinks ownership (uid/gid) is taken from the target kernfs
object.
Signed-off-by: Dmitry Torokhov
Signed-off-by: Tyler Hicks
---
fs/kernfs/dir.c | 29 ++---
fs/ker
okhov
Reviewed-by: Tyler Hicks
---
drivers/base/core.c| 9 +
include/linux/device.h | 5 +
2 files changed, 14 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index df3e1a44707a..276c7e3f754c 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -866,10 +8
d profile permission query ability")
Signed-off-by: Tyler Hicks
---
security/apparmor/apparmorfs.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/security/apparmor/apparmorfs.c b/security/apparmor/apparmorfs.c
index 949dd8a48164..e09fe4d7307c 100644
--- a/security/ap
Don't read past the end of the buffer containing permissions
characters or write past the end of the destination string.
Detected by CoverityScan CID#1415361, 1415376 ("Out-of-bounds access")
Fixes: e53cfe6c7caa ("apparmor: rework perm mapping to a slightly broader set&qu
This set fixes three issues, discovered by CoverityScan, that I don't
believe are serious in practice but are worth fixing to make the
AppArmor code more robust and prevent them from becoming more serious
issues in the future. The first patch fixes possible out of bounds
access issues when mapping
n those
regions, despite not being aligned to 16M.
Link:
https://lore.kernel.org/lkml/CA+CK2bDJ3hrWoE91L2wpAk+Yu0_=GtYw=4glddd7mxs321b...@mail.gmail.com
Fixes: 2522afb86a8c ("libnvdimm/region: Introduce an 'align' attribute")
Signed-off-by: Tyler Hicks
---
While testing wi
On 2022-08-30 00:45:05, Tyler Hicks wrote:
> The alignment constraint for namespace creation in a region was
> increased, from 2M to 16M, for non-PowerPC architectures in v5.7 with
> commit 2522afb86a8c ("libnvdimm/region: Introduce an 'align'
> attribute"). The th
On 2022-09-26 16:18:18, Jeff Moyer wrote:
> Tyler Hicks writes:
>
> > The alignment constraint for namespace creation in a region was
> > increased, from 2M to 16M, for non-PowerPC architectures in v5.7 with
> > commit 2522afb86a8c ("libnvdimm/region: Introduce an
gt;
> Resolves Launchpad issue #338914, reported by Tyler Hicks in 03/2009.
> https://bugs.launchpad.net/ecryptfs/+bug/338914
>
> Signed-off-by: Tim Sally
Looks good! I've pushed it to the eCryptfs -next branch and it will go
in during the 3.6 merge window.
I'm looking forw
Hello Guenter
On 02/13/2018 04:36 PM, Guenter Roeck wrote:
> Commit 88ae4ab9802e ("ecryptfs_lookup(): try either only encrypted or
> plaintext name") was supposed to fix a situation where two files with
> the same name and same inode could be created in ecryptfs. One of those
> files had an encryp
On 03/28/2018 08:33 AM, Guenter Roeck wrote:
> On 03/27/2018 08:58 AM, Tyler Hicks wrote:
>> Hello Guenter
>>
>> On 02/13/2018 04:36 PM, Guenter Roeck wrote:
>>> Commit 88ae4ab9802e ("ecryptfs_lookup(): try either only encrypted or
>>> plaintext name
Additionally, some potentially noisy error/info messages in the related
code paths are turned into debug messages so that the logs can't be
easily filled.
Fixes: 88ae4ab9802e ("ecryptfs_lookup(): try either only encrypted or plaintext
name")
Reported-by: Guenter Roeck
Cc: Al Viro
On 03/02/2018 03:07 AM, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in debug message text.
>
> Signed-off-by: Colin Ian King
Looks good to me. Thanks!
Tyler
> ---
> fs/ecryptfs/keystore.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --gi
On 01/18/2018 08:40 PM, Guenter Roeck wrote:
> mount_crypt_stat is assigned to
> &ecryptfs_superblock_to_private(ecryptfs_dentry->d_sb)->mount_crypt_stat,
> and mount_crypt_stat is not the first object in struct ecryptfs_sb_info.
> mount_crypt_stat is therefore never NULL. At the same time, no cras
, results in the same
value as the previous example for the actions field:
type=CONFIG_CHANGE msg=audit(1524601204.365:152): pid=1704 uid=0
auid=1000 tty=pts8 ses=1 comm="tee" exe="/usr/bin/tee"
op=seccomp-logging actions="kill_process kill_thread errno trace log"
Seccomp received improved logging controls in v4.14. Applications can opt into
logging of "handled" actions (SECCOMP_RET_TRAP, SECCOMP_RET_TRACE,
SECCOMP_RET_ERRNO) using the SECCOMP_FILTER_FLAG_LOG bit when loading filters.
They can also debug filter matching with the new SECCOMP_RET_LOG action.
A
parameter evaluates to true.
Signed-off-by: Tyler Hicks
---
kernel/seccomp.c | 60 +++-
1 file changed, 38 insertions(+), 22 deletions(-)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index dc77548..f4afe67 100644
--- a/kernel/seccomp.c
++
Signed-off-by: Tyler Hicks
---
Documentation/userspace-api/seccomp_filter.rst | 7 ---
include/linux/audit.h | 10 +-
kernel/auditsc.c | 2 +-
kernel/seccomp.c | 15 +--
4 files change
parameter evaluates to true.
Signed-off-by: Tyler Hicks
---
kernel/seccomp.c | 60 +++-
1 file changed, 38 insertions(+), 22 deletions(-)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index dc77548..f4afe67 100644
--- a/kernel/seccomp.c
++
Seccomp received improved logging controls in v4.14. Applications can opt into
logging of "handled" actions (SECCOMP_RET_TRAP, SECCOMP_RET_TRACE,
SECCOMP_RET_ERRNO) using the SECCOMP_FILTER_FLAG_LOG bit when loading filters.
They can also debug filter matching with the new SECCOMP_RET_LOG action.
A
.
Signed-off-by: Tyler Hicks
---
kernel/seccomp.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index f4afe67..b36ac1e 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -1135,10 +1135,11 @@ static const struct seccomp_log_name
Signed-off-by: Tyler Hicks
---
Documentation/userspace-api/seccomp_filter.rst | 7 ---
include/linux/audit.h | 10 +-
kernel/auditsc.c | 14 +-
kernel/seccomp.c | 15 +--
4 fi
ill_process,kill_thread,errno,trace,log res=1
No audit records are generated when reading the actions_logged sysctl.
Suggested-by: Steve Grubb
Signed-off-by: Tyler Hicks
---
include/linux/audit.h | 5 +
kernel/auditsc.c | 25 +
kernel/seccomp.c | 51
On 05/01/2018 12:25 PM, Paul Moore wrote:
> On Tue, May 1, 2018 at 12:41 PM, Steve Grubb wrote:
>> On Tuesday, May 1, 2018 11:18:55 AM EDT Paul Moore wrote:
>>> On Fri, Apr 27, 2018 at 3:16 PM, Tyler Hicks wrote:
>>>> The decision to log a seccomp action will alway
On 2021-02-05 12:01:55, Tyler Hicks wrote:
> On 2020-10-30 09:00:35, Mark Salyzyn wrote:
> > On 10/30/20 8:07 AM, Miklos Szeredi wrote:
> > > On Wed, Oct 21, 2020 at 5:19 PM Mark Salyzyn wrote:
> > > > Because of the overlayfs getxattr recursion, the incoming ino
-by: Pavel Tatashin
> Fixes: 58284a901b42 ("arm64/mm: Validate hotplug range before creating linear
> mapping")
Tested-by: Tyler Hicks
This fixes a memory hot plugging bug that I was seeing on 5.10, with the
introduction of 58284a901b42.
One comment below...
> ---
>
I'm seeing a race during policy load while the "regular" sidtab
conversion is happening and a live conversion starts to take place in
sidtab_context_to_sid().
We have an initial policy that's loaded by systemd ~0.6s into boot and
then another policy gets loaded ~2-3s into boot. That second policy
On 2021-02-23 15:43:48, Tyler Hicks wrote:
> I'm seeing a race during policy load while the "regular" sidtab
> conversion is happening and a live conversion starts to take place in
> sidtab_context_to_sid().
>
> We have an initial policy that's loaded by systemd
On 2021-02-23 15:50:56, Tyler Hicks wrote:
> On 2021-02-23 15:43:48, Tyler Hicks wrote:
> > I'm seeing a race during policy load while the "regular" sidtab
> > conversion is happening and a live conversion starts to take place in
> > sidtab_context_to_sid()
On 2021-02-24 10:33:46, Ondrej Mosnacek wrote:
> On Tue, Feb 23, 2021 at 11:37 PM Tyler Hicks
> wrote:
> > On 2021-02-23 15:50:56, Tyler Hicks wrote:
> > > On 2021-02-23 15:43:48, Tyler Hicks wrote:
> > > > I'm seeing a race during policy load while the
Hi Linus,
The following changes since commit 83d09ad4b950651a95d37697f1493c00d888d0db:
Merge tag 'for-linus' of git://github.com/openrisc/linux (2021-01-21 18:35:02
-0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs.git
tags/ecr
On 2020-12-18 13:07:30, Jeffrey Mitchell wrote:
> On asynchronous base filesystems like NFS, eCryptFS leaves inodes for
> deleted files in the cache until unmounting. Change call in
> ecryptfs_do_unlink() from set_nlink() to drop_nlink() in order to reliably
> evict inodes from the cache even on to
On 2020-11-27 10:11:23, Joe Perches wrote:
> On Fri, 2020-11-27 at 08:05 -0800, t...@redhat.com wrote:
> > Function like macros should have a semicolon.
> []
> > diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c
> []
> > @@ -1172,7 +1172,7 @@ decrypt_pki_encrypted_session_key(struct
> >
On 2020-12-24 21:22:33, Zheng Yongjun wrote:
> mutex lock can be initialized automatically with DEFINE_MUTEX()
> rather than explicitly calling mutex_init().
>
> Signed-off-by: Zheng Yongjun
This looks good to me. I've pushed the patch to the eCryptfs next
branch:
https://git.kernel.org/pub/s
On 2020-10-30 09:00:35, Mark Salyzyn wrote:
> On 10/30/20 8:07 AM, Miklos Szeredi wrote:
> > On Wed, Oct 21, 2020 at 5:19 PM Mark Salyzyn wrote:
> > > Because of the overlayfs getxattr recursion, the incoming inode fails
> > > to update the selinux sid resulting in avc denials being reported
> > >
On 2021-02-25 17:38:25, Ondrej Mosnacek wrote:
> On Wed, Feb 24, 2021 at 3:43 PM Tyler Hicks
> wrote:
> > On 2021-02-24 10:33:46, Ondrej Mosnacek wrote:
> > > On Tue, Feb 23, 2021 at 11:37 PM Tyler Hicks
> > > wrote:
> > > > On 2021-02-23 15:50:56, Tyl
On 2020-07-29 20:47:21, Lakshmi Ramasubramanian wrote:
> Critical data structures of security modules need to be measured to
> enable an attestation service to verify if the configuration and
> policies for the security modules have been setup correctly and
> that they haven't been tampered with at
to measure LSM state and LSM policy
> respectively. Return the status of the measurement operation from these
> two IMA hooks.
>
> Signed-off-by: Lakshmi Ramasubramanian
Reviewed-by: Tyler Hicks
Tyler
> ---
> include/linux/ima.h | 14 +
> se
On 2020-07-30 08:15:34, Lakshmi Ramasubramanian wrote:
> On 7/30/20 8:02 AM, Tyler Hicks wrote:
>
> > > diff --git a/security/integrity/ima/ima_policy.c
> > > b/security/integrity/ima/ima_policy.c
> > > index 07f033634b27..a0f5c39d9084 100644
> > >
On 2020-07-30 11:02:50, Lakshmi Ramasubramanian wrote:
> On 7/29/20 8:47 PM, Lakshmi Ramasubramanian wrote:
>
> Hi Tyler,
>
> > diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> > index 080c53545ff0..86cba844f73c 100644
> > --- a/security/integrity/ima/Kconfig
> > +++
Undefine parse_u32, instead of parse_size, as the name of the macro
recently changed but the #undef directive wasn't updated at that time.
Fixes: 6b31e99b85b0 ("pstore/ram: Refactor DT size parsing")
Signed-off-by: Tyler Hicks
---
Hi Kees - Here's a minor fixup that I noti
f keyrings was longer than what could
fit in the fixed size tbuf buffer in ima_policy_show().
Fixes: 5c7bac9fb2c5 ("IMA: pre-allocate buffer to hold keyrings string")
Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy")
Signed-off-by: Tyler Hicks
Reviewed-by:
authors don't assume that
these policy language constructs are supported.
Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy")
Fixes: 5808611cccb2 ("IMA: Add KEY_CHECK func to measure keys")
Suggested-by: Nayna Jain
Signed-off-by: Tyler Hicks
Review
to be fully
parsed at this time) and using "|" as an alternation delimiter is
becoming the norm in IMA policy.
This series is based on commit 311aa6aafea4 ("ima: move
APPRAISE_BOOTPARAM dependency on ARCH_POLICY to runtime") in
next-integrity.
Tyler
Tyler Hicks (2):
ima:
On 2020-08-05 08:36:40, Casey Schaufler wrote:
> On 8/4/2020 6:14 PM, Lakshmi Ramasubramanian wrote:
> > On 8/4/20 6:04 PM, Casey Schaufler wrote:
> >> On 8/4/2020 5:43 PM, Lakshmi Ramasubramanian wrote:
> >>> Critical data structures of security modules are currently not measured.
> >>> Therefore
On 2020-08-05 10:27:43, Stephen Smalley wrote:
> On Wed, Aug 5, 2020 at 9:20 AM Mimi Zohar wrote:
> >
> > On Wed, 2020-08-05 at 09:03 -0400, Stephen Smalley wrote:
> > > On Wed, Aug 5, 2020 at 8:57 AM Mimi Zohar wrote:
> > > > On Wed, 2020-08-05 at 08:46 -0400, Stephen Smalley wrote:
> > > > > On
On 2020-08-05 09:21:24, Lakshmi Ramasubramanian wrote:
> On 8/5/20 9:14 AM, Tyler Hicks wrote:
> > On 2020-08-05 09:07:48, Lakshmi Ramasubramanian wrote:
> > > On 8/5/20 8:45 AM, Tyler Hicks wrote:
> > > > On 2020-08-05 08:36:40, Casey Schaufler wrote:
> >
On 2020-08-05 09:07:48, Lakshmi Ramasubramanian wrote:
> On 8/5/20 8:45 AM, Tyler Hicks wrote:
> > On 2020-08-05 08:36:40, Casey Schaufler wrote:
> > > On 8/4/2020 6:14 PM, Lakshmi Ramasubramanian wrote:
> > > > On 8/4/20 6:04 PM, Casey Schaufler wrote:
> >
On 2020-08-06 11:34:43, Nayna wrote:
>
> On 7/27/20 10:08 AM, Tyler Hicks wrote:
> > The ima_keyrings buffer was used as a work buffer for strsep()-based
> > parsing of the "keyrings=" option of an IMA policy rule. This parsing
> > was re-performed each tim
On 2020-12-09 11:42:06, Tushar Sugandhi wrote:
> The original IMA buffer data measurement sizes were small (e.g. boot
> command line), but the new buffer data measurement use cases have data
> sizes that are a lot larger. Just as IMA measures the file data hash,
> not the file data, IMA should si
rent patch is fine:
Reviewed-by: Tyler Hicks
> ---
> security/integrity/ima/ima.h| 6 ++--
> security/integrity/ima/ima_api.c| 6 ++--
> security/integrity/ima/ima_main.c | 6 ++--
> security/integrity/ima/ima_policy.c | 49 ++---
>
On 2020-12-09 11:42:07, Tushar Sugandhi wrote:
> IMA provides capabilities to measure file data, and in-memory buffer
> data. However, various data structures, policies, and states
> stored in kernel memory also impact the integrity of the system.
> Several kernel subsystems contain such integrity
On 2020-12-09 11:42:08, Tushar Sugandhi wrote:
> A new IMA policy rule is needed for the IMA hook
> ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
> measuring the input buffer. The policy rule should ensure the buffer
> would get measured only when the policy rule allows t
On 2020-12-09 11:42:09, Tushar Sugandhi wrote:
> System administrators should be able to limit which kernel subsystems
> they want to measure the critical data for. To enable that, an IMA policy
> condition to choose specific kernel subsystems is needed. This policy
> condition would constrain the
xtend the IMA hook ima_measure_critical_data() to support passing
> the data source label as an input parameter, so that the policy rule can
> be used to limit the measurements based on the label.
>
> Signed-off-by: Tushar Sugandhi
Reviewed-by: Tyler Hicks
Tyler
> ---
> in
e kernel command line
> contains "ima_policy=critical_data".
>
> Update the documentation on kernel parameters to document
> the new critical data builtin policy.
>
> Signed-off-by: Lakshmi Ramasubramanian
Reviewed-by: Tyler Hicks
Tyler
> ---
> Documentation/a
On 2020-12-10 17:21:19, Tushar Sugandhi wrote:
>
>
> On 2020-12-10 2:38 p.m., Tyler Hicks wrote:
> > On 2020-12-09 11:42:06, Tushar Sugandhi wrote:
> > > The original IMA buffer data measurement sizes were small (e.g. boot
> > > command line), but the new buffe
On 2020-11-29 08:17:38, Mimi Zohar wrote:
> Hi Sasha,
>
> On Wed, 2020-07-08 at 21:27 -0400, Sasha Levin wrote:
> > On Wed, Jul 08, 2020 at 12:13:13PM -0400, Mimi Zohar wrote:
> > >Hi Sasha,
> > >
> > >On Wed, 2020-07-08 at 11:40 -0400, Sasha Levin wrote:
> > >> From: Maurizio Drocco
> > >>
> > >
On 2020-12-09 11:42:12, Tushar Sugandhi wrote:
> From: Lakshmi Ramasubramanian
>
> IMA measures files and buffer data such as keys, command line arguments
> passed to the kernel on kexec system call, etc. While these measurements
> enable monitoring and validating the integrity of the system, it
On 2020-12-11 09:36:30, Tyler Hicks wrote:
> The calls to pr_err() in this aren't quite following the style of the
> other error SELinux error messages.
Sorry, I left out a word. I meant to say that the calls to pr_err() in
this *file* aren't quite following the right style. Plea
er to extend them without code duplication.
>
> Refactor the keyring specific measurement constructs to be generic and
> reusable in other measurement scenarios.
>
> Signed-off-by: Tushar Sugandhi
> Reviewed-by: Tyler Hicks
This looks good to me. Thanks!
Tyler
> --
a buffer, which would be much smaller, instead of the buffer
> itself.
>
> Signed-off-by: Tushar Sugandhi
Reviewed-by: Tyler Hicks
Tyler
> ---
> security/integrity/ima/ima.h | 3 +-
> security/integrity/ima/ima_appraise.c| 2 +-
> securit
l
> integrity critical data.
>
> Signed-off-by: Tushar Sugandhi
Reviewed-by: Tyler Hicks
Tyler
> ---
> include/linux/ima.h | 6 ++
> security/integrity/ima/ima.h | 1 +
> security/integrity/ima/ima_api.c | 2 +-
> security/integrity/ima/i
On 2020-12-11 15:58:03, Tushar Sugandhi wrote:
> A new IMA policy rule is needed for the IMA hook
> ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
> measuring the input buffer. The policy rule should ensure the buffer
> would get measured only when the policy rule allows t
gt; Note that the actual verification of SELinux policy would require loading
> the expected policy into an identical kernel on a pristine/known-safe
> system and run the sha256sum /sys/kernel/selinux/policy there to get
> the expected hash.
>
> Signed-off-by: Lakshmi Ramasubra
On 2020-12-11 17:17:22, Tushar Sugandhi wrote:
>
>
> On 2020-12-11 4:25 p.m., Tyler Hicks wrote:
> > On 2020-12-11 15:58:03, Tushar Sugandhi wrote:
> > > A new IMA policy rule is needed for the IMA hook
> > > ima_measure_critical_data() and the cor
Tushar Sugandhi
This looks nice. Thanks for the changes!
Reviewed-by: Tyler Hicks
Tyler
> ---
> Documentation/ABI/testing/ima_policy | 2 +-
> security/integrity/ima/ima_policy.c | 29
> 2 files changed, 26 insertions(+), 5 deletions(-)
>
> dif
unc CRITICAL_DATA, the data from all the
> supported kernel subsystems is measured.
>
> Signed-off-by: Tushar Sugandhi
Reviewed-by: Tyler Hicks
Tyler
> ---
> Documentation/ABI/testing/ima_policy | 2 ++
> security/integrity/ima/ima_policy.c | 37 +
On 2020-12-14 10:42:24, Tyler Hicks wrote:
> On 2020-12-11 06:01:54, Mimi Zohar wrote:
> > On Thu, 2020-12-10 at 21:10 -0600, Tyler Hicks wrote:
> > > On 2020-11-29 08:17:38, Mimi Zohar wrote:
> > > > Hi Sasha,
> > > >
> > > > On Wed, 2020-07-
urements | tail -1 |
> > cut -d' ' -f 6
> >
> > Note that the actual verification of SELinux policy would require loading
> > the expected policy into an identical kernel on a pristine/known-safe
> > system and run the sha256sum /sys/kernel/selinux/policy there
e_remove(struct platform_device *pdev)
> return 0;
> }
>
> +/* optee_shutdown - Device Removal Routine
> + * @pdev: platform device information struct
> + *
> + * platform_shutdown is called by the platform subsystem to alter
igned-off-by: Allen Pais
Reviewed-by: Tyler Hicks
Tyler
> ---
> drivers/firmware/broadcom/tee_bnxt_fw.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/firmware/broadcom/tee_bnxt_fw.c
> b/drivers/firmware/broadcom/tee_bnxt_fw.c
> index ed10da5313e8.
70.921642] CPU7: shutdown
> <6>[ 70.922650] psci: CPU7 killed (polled 0 ms)
>
> Signed-off-by: Pavel Tatashin
> Reviewed-by: Kees Cook
> Reviewed-by: Petr Mladek
> Reviewed-by: Bhupesh Sharma
Reviewed-by: Tyler Hicks
Tyler
> Acked-by: Baoquan He
> -
ccident, but other platforms update this value properly.
> So, fix it in ARM64 version of elfcorehdr_read() as well.
>
Fixes: e62aaeac426a ("arm64: kdump: provide /proc/vmcore file")
Reviewed-by: Tyler Hicks
Tyler
> Signed-off-by: Pavel Tatashin
> ---
> arch/arm64
1 - 100 of 372 matches
Mail list logo
