On Mon, Mar 11, 2013 at 12:44:15PM -0700, Yinghai Lu wrote:
> On Mon, Mar 11, 2013 at 12:39 PM, Yinghai Lu wrote:
> > On Mon, Mar 11, 2013 at 12:38 PM, Vivek Goyal wrote:
> >>> No need to use crashkernel_high, we can just cashkernel=X@Y instead.
> >>
> >>
On Mon, Mar 18, 2013 at 10:46:03AM -0400, Vivek Goyal wrote:
> On Mon, Mar 11, 2013 at 12:44:15PM -0700, Yinghai Lu wrote:
> > On Mon, Mar 11, 2013 at 12:39 PM, Yinghai Lu wrote:
> > > On Mon, Mar 11, 2013 at 12:38 PM, Vivek Goyal wrote:
> > >>> No need to
On Fri, Mar 15, 2013 at 02:12:59PM -0700, Casey Schaufler wrote:
> On 3/15/2013 1:35 PM, Vivek Goyal wrote:
> > Create a new capability CAP_SIGNED which can be given to signed executables.
>
> This would drive anyone who is trying to use
> capabilities as the privilege mechanis
On Mon, Mar 18, 2013 at 10:50:21AM -0700, Casey Schaufler wrote:
> On 3/18/2013 10:05 AM, Vivek Goyal wrote:
> > On Fri, Mar 15, 2013 at 02:12:59PM -0700, Casey Schaufler wrote:
> >> On 3/15/2013 1:35 PM, Vivek Goyal wrote:
> >>> Create a new capability CAP_SIGNE
On Mon, Mar 18, 2013 at 12:10:47PM -0700, H. Peter Anvin wrote:
> On 03/18/2013 08:33 AM, Vivek Goyal wrote:
> >
> > Thinking more about it, if ongoing DMA is an issue, then setting up
> > software iotlb in those areas is also prone to being overwritten by
> > those DM
On Mon, Mar 18, 2013 at 04:23:11PM -0400, Josh Boyer wrote:
> On Fri, Mar 15, 2013 at 4:35 PM, Vivek Goyal wrote:
> > Do elf executable signature verification (if one is present). If signature
> > is present, it should be valid. Validly signed files are given a capability
On Mon, Mar 18, 2013 at 06:04:08PM -0700, Yinghai Lu wrote:
> Current code does not set low range for crashkernel if the user
> does not specify that.
Hi Yinghai,
While we are modifying changelog, it will also be beneficial to
mention that how did we end up in this situation. Can we mention
chang
On Tue, Mar 19, 2013 at 01:59:57PM -0700, Eric W. Biederman wrote:
> HATAYAMA Daisuke writes:
>
> > Due to mmap() requirement, we need to copy pages not starting or
> > ending with page-size aligned address in 2nd kernel and to map them to
> > user-space.
> >
> > For example, see the map below:
>
On Tue, Mar 19, 2013 at 08:05:26AM -0700, Yinghai Lu wrote:
> Chao said that kdump does does work well on his system on 3.8
> without extra parameter, even iommu does not work with kdump.
> And now have to append crashkernel_low=Y in first kernel to make
> kdump work.
>
> We have now modified cras
On Tue, Mar 19, 2013 at 03:12:10PM -0700, Eric W. Biederman wrote:
> HATAYAMA Daisuke writes:
>
> > To satisfy mmap()'s page-size boundary requirement, allocate per-cpu
> > crash_notes objects on page-size boundary.
> >
> > /proc/vmcore on the 2nd kernel checks if each note objects is
> > allocat
On Tue, Mar 19, 2013 at 01:02:29PM -0700, Andrew Morton wrote:
> On Sat, 16 Mar 2013 13:02:29 +0900 HATAYAMA Daisuke
> wrote:
>
> > If there's some vmcore object that doesn't satisfy page-size boundary
> > requirement, remap_pfn_range() fails to remap it to user-space.
> >
> > Objects that posi
On Tue, Mar 19, 2013 at 03:38:45PM -0700, Eric W. Biederman wrote:
> HATAYAMA Daisuke writes:
>
> > If there's some vmcore object that doesn't satisfy page-size boundary
> > requirement, remap_pfn_range() fails to remap it to user-space.
> >
> > Objects that posisbly don't satisfy the requirement
On Wed, Mar 20, 2013 at 04:07:58PM +1100, James Morris wrote:
> On Fri, 15 Mar 2013, Casey Schaufler wrote:
>
> > Capabilities aren't just random attribute bits. They
> > indicate that a task has permission to violate a
> > system policy (e.g. change the mode bits of a file
> > the user doesn't ow
On Tue, Mar 19, 2013 at 10:39:01AM -0400, Mimi Zohar wrote:
[..]
> > +#ifdef CONFIG_BINFMT_ELF_SIG
> > + /* If executable is digitally signed. Lock down in memory */
> > + /* Get file signature, if any */
> > + retval = ima_file_signature_alloc(bprm->file, &signature);
> > +
> > + /*
> > +
On Tue, Mar 19, 2013 at 10:39:01AM -0400, Mimi Zohar wrote:
[..]
>
> Lastly, adding 'VM_LOCKED' here seems to change existing, expected
> behavior. According to the mlock(2) man pages, "Memory locks are not
> inherited by a child created via fork(2) and are automatically removed
> (unlocked) dur
On Wed, Mar 20, 2013 at 08:53:29AM -0700, Yinghai Lu wrote:
> On Wed, Mar 20, 2013 at 6:08 AM, Vivek Goyal wrote:
>
> > Have a general question about crashkernel_low. Why does it need to
> > show up as "Crash kernel low" in /proc/iomem. Will it not be better
>
On Wed, Mar 20, 2013 at 09:21:31AM -0700, Yinghai Lu wrote:
> On Wed, Mar 20, 2013 at 9:03 AM, Vivek Goyal wrote:
> > On Wed, Mar 20, 2013 at 08:53:29AM -0700, Yinghai Lu wrote:
> >> On Wed, Mar 20, 2013 at 6:08 AM, Vivek Goyal wrote:
> >>
> >> > Have a
On Wed, Mar 20, 2013 at 01:41:30PM -0400, Mimi Zohar wrote:
[..]
> Defining another Kconfig option will either memlock all signed
> executables or none. If a distro ships with this new Kconfig enabled,
> then the 'ima_appraise_tcb' boot command line option would result in all
> executables, owned
On Wed, Mar 20, 2013 at 09:18:10PM +, Matthew Garrett wrote:
> On Wed, 2013-03-20 at 17:11 -0400, Mimi Zohar wrote:
> > On Wed, 2013-03-20 at 20:37 +, Matthew Garrett wrote:
> > > Right, that'd be the rough idea. Any further runtime policy updates
> > > would presumably need to be signed wi
On Wed, Mar 20, 2013 at 01:55:55PM -0700, Eric W. Biederman wrote:
[..]
> If core counts on the high end do more than double every 2 years we
> might have a problem. Otherwise making everything mmapable seems easy
> and sound.
We already have mechanism to translate file offset into actual physic
On Thu, Mar 21, 2013 at 11:50:41AM +0900, HATAYAMA Daisuke wrote:
> From: "Eric W. Biederman"
> Subject: Re: [PATCH v3 01/21] vmcore: reference e_phoff member explicitly to
> get position of program header table
> Date: Tue, 19 Mar 2013 14:44:16 -0700
>
> > HATAYAMA Daisuke writes:
> >
> >> Cu
On Wed, Mar 20, 2013 at 08:54:25PM -0700, Eric W. Biederman wrote:
[..]
> > Also, it's possible to get size of a whole part of ELF note segments
> > from p_memsz or p_filesz, and gdb and binutils are reading the note
> > segments until reaching the size.
>
> Agreed. Except in our weird case wher
On Thu, Mar 21, 2013 at 12:22:59AM -0700, Eric W. Biederman wrote:
> HATAYAMA Daisuke writes:
>
> > OK, rigorously, suceess or faliure of the requested free pages
> > allocation depends on actual memory layout at the 2nd kernel boot. To
> > increase the possibility of allocating memory, we have n
On Wed, Mar 20, 2013 at 11:29:05PM -0700, Eric W. Biederman wrote:
[..]
> Preserving the actual PT_LOAD segments p_paddr and p_memsz values is
> important. p_offset we can change as much as we want. Which means there
> can be logical holes in the file between PT_LOAD segments, where we put
> the
On Thu, Mar 21, 2013 at 12:07:12AM -0700, Eric W. Biederman wrote:
[..]
> I think the two having different contents violates the principle of
> least surprise.
>
> I think exporting the old memory as the ``extra data'' is the least
> surprising and the easiest way to go.
>
> I don't mind filling
On Thu, Mar 21, 2013 at 11:21:24AM -0400, Vivek Goyal wrote:
[..]
> So if starting or end address of PT_LOAD header is not aligned, why
> not we simply allocate a page. Copy the relevant data from old memory,
> fill rest with zero. That way mmap and read view will be same. There
>
On Thu, Mar 21, 2013 at 10:37:25AM -0500, Serge E. Hallyn wrote:
> Quoting Vivek Goyal (vgo...@redhat.com):
> ...
> > Giving CAP_MODIFY_KERNEL to processess upon signature verification
> > will simplify things a bit.
> >
> > Only thing is that signature verificati
On Thu, Mar 21, 2013 at 10:58:23AM -0500, Serge E. Hallyn wrote:
> Quoting Vivek Goyal (vgo...@redhat.com):
> > On Thu, Mar 21, 2013 at 10:37:25AM -0500, Serge E. Hallyn wrote:
> > > Quoting Vivek Goyal (vgo...@redhat.com):
> > > ...
> > > > Giving CAP_MOD
On Mon, Feb 04, 2013 at 04:59:35AM +, Hatayama, Daisuke wrote:
> Support mmap() on /dev/oldmem to improve performance of reading
> /proc/vmcore. Currently, read to /proc/vmcore is done by read_oldmem()
> that uses ioremap and iounmap per a single page; for example, if
> memory is 1GB, ioremap/i
On Tue, Feb 05, 2013 at 06:19:26PM +, Matthew Garrett wrote:
> On Tue, Feb 05, 2013 at 02:34:50PM +0200, Dmitry Kasatkin wrote:
>
> > Digitally signed initramfs can be used to provide protected user-space
> > environment for initialization purpose. For example, LSM, IMA/EVM can be
> > securely
On Wed, Feb 06, 2013 at 07:24:46AM +, Hatayama, Daisuke wrote:
> From: Vivek Goyal
> Subject: Re: [PATCH] kdump, oldmem: support mmap on /dev/oldmem
> Date: Tue, 5 Feb 2013 10:12:56 -0500
>
> > On Mon, Feb 04, 2013 at 04:59:35AM +, Hatayama, Daisuke wrote:
>
>
On Tue, Feb 05, 2013 at 02:34:50PM +0200, Dmitry Kasatkin wrote:
[..]
> +static int __init load_initramfs(void)
> +{
> + static char *argv[] = { "pre-init", NULL, };
> + extern char *envp_init[];
> + int err;
> +
> + /*
> + * In case that a resume from disk is carried out by l
results, signed executables with valid signatures can be
given extra capability to perform priviliged operations in secureboot
mode.
Signed-off-by: Vivek Goyal
---
Documentation/ABI/testing/ima_policy |2 +-
security/integrity/ima/ima_appraise.c | 24 +++-
security/integrity
Hi Mimi,
As we discussed, thhis is a RFC patch to extend current appraisal rules
to allow appraising signed files only. This should apply on top of
Dmitry's patches to support asymmetric key signatures.
Thanks
Vivek
Vivek Goyal (2):
ima: Do not try to fix hash if file system does not su
vfs_getxattr_alloc() returns -EOPNOTSUPP if filesystem does not have
security label enabled. In that case there is no point in continuing
further and try to fix hashes (if ima_appraise=fix was specified) as
that will fail too. Return early
Signed-off-by: Vivek Goyal
Acked-by: Mimi Zohar
On Fri, Feb 08, 2013 at 12:33:49AM +, Hatayama, Daisuke wrote:
[..]
> Also, remap_pfn_range is the function exported into kernel modules, so
> changing the third argument means changing ABI. Introducing a kind of
> remap_pfn_range_64 is a good idea? if there's someone needing the feature on
On Fri, Feb 08, 2013 at 03:27:30PM +0200, Kasatkin, Dmitry wrote:
> >>
> >> Dmitry,
> >>
> >> How do we make sure that this is the first call to user mode helpers. I
> >> see that we first unpacked unsigned initramfs. Then after a while we
> >> unpacked signed initramfs on /root and did a chroot. B
On Mon, Feb 11, 2013 at 05:10:14PM -0500, Mimi Zohar wrote:
> On Mon, 2013-02-11 at 15:11 -0500, Vivek Goyal wrote:
> > appraise_type=imasig_optional will allow appraisal to pass even if no
> > signatures are present on the file. If signatures are present, then it
> > ha
On Tue, Feb 12, 2013 at 06:45:06AM -0500, Mimi Zohar wrote:
> On Mon, 2013-02-11 at 15:11 -0500, Vivek Goyal wrote:
> > vfs_getxattr_alloc() returns -EOPNOTSUPP if filesystem does not have
> > security label enabled. In that case there is no point in continuing
> > further
esent, then it has to be valid digital signature,
otherwise appraisal will fail.
Signed-off-by: Vivek Goyal
---
Documentation/ABI/testing/ima_policy |2 +-
security/integrity/ima/ima_appraise.c | 25 -
security/integrity/ima/ima_policy.c |2 ++
security/inte
vfs_getxattr_alloc() returns -EOPNOTSUPP if filesystem does not have
security label enabled. In that case there is no point in continuing
further and try to fix hashes (if ima_appraise=fix was specified) as
that will fail too. Return early
Signed-off-by: Vivek Goyal
Acked-by: Mimi Zohar
tures are present, then it has to be valid digital signature,
otherwise appraisal will fail.
v2: Changed patches based on Mimi's feedback.
Thanks
Vivek
Vivek Goyal (2):
ima: detect security xattrs not enabled
ima: Allow appraisal of digitally signed files only
Documentation/ABI/testing/
On Tue, Feb 12, 2013 at 12:14:07PM -0500, Mimi Zohar wrote:
[..]
> > > > --- a/security/integrity/ima/ima_appraise.c
> > > > +++ b/security/integrity/ima/ima_appraise.c
> > > > @@ -124,19 +124,26 @@ int ima_appraise_measurement(int func, struct
> > > > integrity_iint_cache *iint,
> > > >
On Tue, Feb 12, 2013 at 01:52:03PM -0500, Vivek Goyal wrote:
> On Tue, Feb 12, 2013 at 12:14:07PM -0500, Mimi Zohar wrote:
>
> [..]
> > > > > --- a/security/integrity/ima/ima_appraise.c
> > > > > +++ b/security/integrity/ima/ima_apprais
On Mon, Apr 01, 2013 at 01:47:58PM -0700, H. Peter Anvin wrote:
[..]
> > All this will only address the issue of where to reserve memory. It will
> > still not solve the issue of how much memory to reserve. We have no way
> > to know. It is all heuristics.
>
> At least heuristics in a script is b
On Mon, Apr 01, 2013 at 06:11:38PM -0700, Yinghai Lu wrote:
> On Mon, Apr 1, 2013 at 3:40 PM, Yinghai Lu wrote:
> > On Mon, Apr 1, 2013 at 3:20 PM, H. Peter Anvin wrote:
> >> On 04/01/2013 03:17 PM, Yinghai Lu wrote:
> >>>
> >>> And his last suggestion is just as his old second suggestion.
> >>>
On Tue, Apr 02, 2013 at 09:50:01AM -0400, Vivek Goyal wrote:
[..]
> To achieve the behavior where we want to enforce that memory either
> comes from low or high area only otherwise allocation fails, we could
> probably use.
>
> crashkernel=X,high_only
> crashkernel=X,low_o
On Tue, Apr 02, 2013 at 07:45:36AM -0700, Yinghai Lu wrote:
[..]
> No, that make the logic too complicated.
>
> After those four patches:
> if the user still use old kexec-tools, they are still with
> crashkernel=X, nothing is changed.
> if the user want to use crashkernel=X,high, they should upd
On Tue, Apr 02, 2013 at 07:45:36AM -0700, Yinghai Lu wrote:
[..]
> 2. keep thing unified when new kexec-tools is used: always high.
I think this is wrong. What if system does not have more than 4G of
memory. crashkernel=x,high will fail. So just because we have new version
of kexec-tools, it does
On Tue, Apr 02, 2013 at 08:46:16AM -0700, Yinghai Lu wrote:
> On Tue, Apr 2, 2013 at 8:39 AM, Vivek Goyal wrote:
> > On Tue, Apr 02, 2013 at 07:45:36AM -0700, Yinghai Lu wrote:
> >
> > [..]
> >> 2. keep thing unified when new kexec-tools is used: always high.
>
On Tue, Apr 02, 2013 at 10:19:42AM -0700, Yinghai Lu wrote:
[..]
> Index: linux-2.6/Documentation/kernel-parameters.txt
> ===
> --- linux-2.6.orig/Documentation/kernel-parameters.txt
> +++ linux-2.6/Documentation/kernel-parameters.txt
On Tue, Apr 02, 2013 at 11:42:09AM -0700, Yinghai Lu wrote:
> On Tue, Apr 2, 2013 at 11:06 AM, Vivek Goyal wrote:
> > On Tue, Apr 02, 2013 at 10:19:42AM -0700, Yinghai Lu wrote:
> >
> > [..]
> >> Index: linux-2.6/Docum
On Tue, Apr 02, 2013 at 11:49:13AM -0700, Yinghai Lu wrote:
> On Tue, Apr 2, 2013 at 11:42 AM, Yinghai Lu wrote:
> > aka:
> > old kexec-tools stay with "crashkernel=X"
> > new kexec-tools stay with
> > 1. like old kexec tools
> > 2. or "crashkernel=X,high" or "crashkernel=X,high crashkernel=Y,low"
On Tue, Apr 02, 2013 at 01:00:46PM -0700, Yinghai Lu wrote:
> On Tue, Apr 2, 2013 at 12:11 PM, Vivek Goyal wrote:
> > On Tue, Apr 02, 2013 at 11:49:13AM -0700, Yinghai Lu wrote:
> >> On Tue, Apr 2, 2013 at 11:42 AM, Yinghai Lu wrote:
> >> > aka:
> >> >
On Tue, Apr 02, 2013 at 04:11:48PM -0400, Vivek Goyal wrote:
[..]
> > No, that is not just disable. User could want more like 128M instead of 72M.
So apart from swiotlb, are there other scenarios where we need to reserve
low memory (With main memory reserved high).
Thanks
Vivek
On Tue, Apr 02, 2013 at 01:36:02PM -0700, Yinghai Lu wrote:
[..]
> > You are just describing what your code does. There is no theme or
> > justification behind this behavior. There is no uniformity. A user can
> > question that so far you used to honor last crashkernel= parameter and
> > suddenly
On Wed, Apr 03, 2013 at 10:12:46AM -0700, Yinghai Lu wrote:
[..]
> >> Can we just keep it separated?
> >
> > Kernel does not know about old kexec-tools or new kexec-tools. Neither
> > kernel can enforce what command line options are passed by user. So
> > kernel needs to define a clean interface h
On Wed, Apr 03, 2013 at 10:32:23AM -0700, Yinghai Lu wrote:
> On Wed, Apr 3, 2013 at 10:12 AM, Yinghai Lu wrote:
> > On Wed, Apr 3, 2013 at 6:18 AM, Vivek Goyal wrote:
> >
> >> - implement crashkernel_no_auto_low option to opt out of auto reserved
> >> lo
On Wed, Apr 03, 2013 at 01:38:56PM -0700, Yinghai Lu wrote:
> On Wed, Apr 3, 2013 at 10:47 AM, Vivek Goyal wrote:
> > So what I am saying that all our code is written assuming there is one
> > single reserved range. Now if we need to reserve two ranges, then let
> > us make i
On Wed, Apr 03, 2013 at 05:56:00PM -0700, Yinghai Lu wrote:
> On Wed, Apr 3, 2013 at 2:00 PM, Vivek Goyal wrote:
> > On Wed, Apr 03, 2013 at 01:38:56PM -0700, Yinghai Lu wrote:
> >> On Wed, Apr 3, 2013 at 10:47 AM, Vivek Goyal wrote:
> >> > So what I am sayin
On Wed, Apr 03, 2013 at 05:56:00PM -0700, Yinghai Lu wrote:
[..]
>
> One big rang under 4G is working well till second kernel need more than 512M
> on bigger system with more memory.
Currently one range is allocated below 896MB (and not 4G). So if we extend
crashkernel=X to first try below 896MB
On Wed, Apr 03, 2013 at 05:38:23PM -0700, Yinghai Lu wrote:
[..]
> + if (ret != 0) {
> + /*
> + * two parts from lib/swiotlb.c:
> + * swiotlb size: user specified with swiotlb= or default.
> + * swiotlb overflow buffer: now is hardco
On Wed, Apr 03, 2013 at 05:38:25PM -0700, Yinghai Lu wrote:
> Vivek found old kexec-tools does not work new kernel anymore.
>
> So change back crashkernel= back to old behavoir, and add crashkernel_high=
> to let user decide if buffer could be above 4G, and also new kexec-tools will
> be needed.
>
On Tue, Feb 05, 2013 at 11:55:09PM +0200, Kasatkin, Dmitry wrote:
[..]
> > Also I am assuming that from signed initramfs, keys will be loaded in
> > appropriate keyrings and then keyring will be locked so that any
> > tools from unsigned initramfs can not load additional keys.
> >
>
> Exactly lik
On Mon, Jan 28, 2013 at 07:14:02PM -0500, Mimi Zohar wrote:
[..]
> The 'trusted' keyring is a solution for installing only distro or third
> party signed packages. How would a developer, for instance, create,
> sign, and install his own package and add his public key safely?
Hi Mimi,
I guess us
On Mon, Jan 28, 2013 at 08:48:55PM -0500, Mimi Zohar wrote:
[..]
> > Also given the fact that we allow loading policy from initramfs, root
> > can rebuild initramfs and change the policy which takes effect over next
> > reboot. So in priciple this works only when we are trying to impose some
> > p
On Mon, Jan 28, 2013 at 08:48:55PM -0500, Mimi Zohar wrote:
[..]
> > Hi Mimi,
> >
> > By policy you mean ima rules here? So I can either enable default rules
> > (tcb default rules for appraisal and measurement) by using kernel command
> > line options or dynamically configure my own rules using
On Tue, Jan 29, 2013 at 10:48:00AM +0200, Kasatkin, Dmitry wrote:
> On Mon, Jan 28, 2013 at 8:52 PM, Vivek Goyal wrote:
> > On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:
> >
> > [..]
> >> > Ok. I am hoping that it will be more than the kernel c
On Tue, Jan 29, 2013 at 03:01:13PM -0500, Mimi Zohar wrote:
[..]
> > Hi Mimi,
> >
> > Can we add another field to ima_rule_entry, say .enforcement to control
> > the behavior of .action. Possible values of .enforcement could be, say.
> >
> > ALL
> > SIGNED_ONLY
> >
> > ALL will be default. And
On Tue, Jan 22, 2013 at 05:07:31PM -0500, Mimi Zohar wrote:
[..]
> /* iint cache flags */
> +#define IMA_ACTION_FLAGS 0xff00
> #define IMA_DIGSIG 0x0100
> +#define IMA_DIGSIG_REQUIRED 0x0200
Hi Mimi,
IMA_DIGSIG_REQUIRED state does not really have to be stored in iint I guess.
Th
On Wed, Jan 30, 2013 at 05:42:39PM -0500, Mimi Zohar wrote:
> On Wed, 2013-01-30 at 16:53 -0500, Vivek Goyal wrote:
> > On Tue, Jan 22, 2013 at 05:07:31PM -0500, Mimi Zohar wrote:
> >
> > [..]
> > > /* iint cache flags */
> > > +#define IMA_ACTION
overidded. As both IMA_DIGSIG_REQUIRED and
IMA_DIGSIG_SIGNED_ONLY flags will be set (one from mmap hook and
other from bprm_check hook).
I guess to support it we require hook specific flags.
Signed-off-by: Vivek Goyal
---
security/integrity/ima/ima_appraise.c | 32 +
Hi,
I am trying to read and understand IMA code. How does digital signature
mechanism work.
IIUC, evmctl will install a file's signature in security.ima. And later
process_measurement() will do following.
Calculate digest of file in ima_collect_measurement() and then
ima_appraise_measurement()
On Mon, Jan 28, 2013 at 04:54:06PM +0200, Kasatkin, Dmitry wrote:
> On Fri, Jan 25, 2013 at 11:01 PM, Vivek Goyal wrote:
> > Hi,
> >
> > I am trying to read and understand IMA code. How does digital signature
> > mechanism work.
> >
> > IIUC, evmctl will ins
On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:
[..]
> > Ok. I am hoping that it will be more than the kernel command line we
> > support. In the sense that for digital signatures one needs to parse
> > the signature, look at what hash algorithm has been used and then
> > collec
On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:
[..]
> > Ok. I am hoping that it will be more than the kernel command line we
> > support. In the sense that for digital signatures one needs to parse
> > the signature, look at what hash algorithm has been used and then
> > collec
On Mon, Jan 28, 2013 at 02:51:34PM -0500, Mimi Zohar wrote:
> On Mon, 2013-01-28 at 13:52 -0500, Vivek Goyal wrote:
> > On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:
> >
> > [..]
> > > > Ok. I am hoping that it will be more than the kernel co
On Mon, Jan 28, 2013 at 03:15:49PM -0500, Mimi Zohar wrote:
> On Mon, 2013-01-28 at 13:56 -0500, Vivek Goyal wrote:
> > On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote:
> >
> > [..]
> > > > Ok. I am hoping that it will be more than the kernel co
On Tue, Feb 26, 2013 at 04:57:47AM +, Matthew Garrett wrote:
[..]
> > - encourage things like per-host random keys - with the stupid UEFI
> > checks disabled entirely if required. They are almost certainly going
> > to be *more* secure than depending on some crazy root of trust based
> > on a
On Tue, Feb 26, 2013 at 10:30:45AM -0500, Vivek Goyal wrote:
> On Tue, Feb 26, 2013 at 04:57:47AM +, Matthew Garrett wrote:
>
> [..]
> > > - encourage things like per-host random keys - with the stupid UEFI
> > > checks disabled entirely if required. They are almo
Hi Mimi,
I am running into issues w.r.t IMA policy management and user space
signing. So thought of dropping a mail and gather some ideas.
Currently IMA seems to able to one policy only which does not contain
conflicting rules. We have tcb policies in-built and they don't have
conflicting rules.
On Thu, Feb 28, 2013 at 10:13:33AM -0500, Vivek Goyal wrote:
> Hi Mimi,
>
> I am running into issues w.r.t IMA policy management and user space
> signing. So thought of dropping a mail and gather some ideas.
>
> Currently IMA seems to able to one policy only which does not con
On Thu, Feb 28, 2013 at 02:23:39PM -0500, Mimi Zohar wrote:
> On Thu, 2013-02-28 at 10:13 -0500, Vivek Goyal wrote:
> > Hi Mimi,
> >
> > I am running into issues w.r.t IMA policy management and user space
> > signing. So thought of dropping a mail and gather some id
On Thu, Feb 28, 2013 at 03:30:01PM -0500, Mimi Zohar wrote:
[..]
> > So we need few more things from IMA for it to support the case of user
> > space signing.
> >
> > - Ability to make sure kernel specified rules can not be overridden.
>
> Our posts must have crossed -
> http://marc.info/?l=linu
On Thu, Feb 28, 2013 at 02:23:39PM -0500, Mimi Zohar wrote:
[..]
> I would suggest that the ima_appraise_tcb, which is more restrictive, be
> permitted to replace the secureboot policy.
Also ima_appraise_tcb is not necessarily more restrictive. It takes
appraises only for root user. Files for res
On Thu, Feb 14, 2013 at 10:30:15AM -0500, Mimi Zohar wrote:
> On Thu, 2013-02-14 at 10:03 -0500, Vivek Goyal wrote:
> > On Wed, Feb 13, 2013 at 05:27:01PM -0500, Mimi Zohar wrote:
> >
> > [..]
> > > > Yep, I got that. Default policy gets overruled wh
On Tue, Feb 19, 2013 at 02:02:34AM +0900, HATAYAMA Daisuke wrote:
[..]
> Anyway, what I'll do in the next version, are in summary:
>
> - append pad notes in each notes on the 1st kernel in every
> architectures, and
> - check if each note is in page-size boundary, and if not so, copy it
> in
On Tue, Feb 19, 2013 at 01:06:31AM +0900, HATAYAMA Daisuke wrote:
[..]
> This sounds strange to me. There has not been contents to be fetched
> from current kenrel so far. So, object with MEM_TYPE_OLDMEM seems more
> normal than without. Should we prepare special type for objects in 2nd
> kernel?
On Thu, Feb 21, 2013 at 08:32:54PM +, Matthew Garrett wrote:
> On Thu, Feb 21, 2013 at 03:31:19PM -0500, Vivek Goyal wrote:
> > On Thu, Feb 21, 2013 at 10:56:44AM -0800, Linus Torvalds wrote:
> >
> > [..]
> > > So no. The PE file thing makes no sense what-so-e
On Thu, Feb 21, 2013 at 10:56:44AM -0800, Linus Torvalds wrote:
[..]
> So no. The PE file thing makes no sense what-so-ever. What you mention
> we can already do, and we already do it *better*.
IIUC, PE/COFF signature verification bits can be useful for verifying
the signature of PE/COFF signed b
On Mon, Mar 11, 2013 at 02:06:57PM -0700, H. Peter Anvin wrote:
> On 03/11/2013 02:03 PM, Vivek Goyal wrote:
> >>
> >> And the solution to that isn't obvious?
> >
> > Sorry, I did not understand what do you mean by above.
> >
> > If you are sugge
On Wed, Mar 13, 2013 at 11:46:29AM +0400, Konstantin Khlebnikov wrote:
[..]
> >Ok, some more observation.
> >
> >- Problem seems to be in during shutdown path. Because older kernel 3.8
> > can kexec into newer kernel 3.9.rc1 but not vice-a-versa.
> >
> >I did git bisecting and following commit s
wn() device can
> be
> already disconnected from the bus and configuration space in no longer
> available
>
> Link: https://lkml.org/lkml/2013/3/12/529
> Signed-off-by: Konstantin Khlebnikov
> Reported-by: Vivek Goyal
> Cc: Bjorn Helgaas
> Cc: Rafael J. Wysoc
gone in just now. Before it becomes an ABI, it
might be worth to discuss it.
Yet-to-by-signed-off-by: Vivek Goyal
---
security/integrity/digsig.c | 11 +++
security/integrity/evm/evm_main.c |4 +++-
security/integrity/ima/ima_appraise.c |7 +--
security/integrity
On Thu, Mar 14, 2013 at 10:05:59PM +0200, Kasatkin, Dmitry wrote:
> On Thu, Mar 14, 2013 at 8:28 PM, Vivek Goyal wrote:
> > Hi Dmitry/Mimi,
> >
> > Here is an RFC patch. I am playing with exporting some functions from
> > ima/integrity and make reuse of IMA signatu
On Thu, Mar 14, 2013 at 04:30:28PM -0400, Vivek Goyal wrote:
[..]
> I thought explicitly using signature format is more intutive. Exporting
> signature version is not. I personally associate versioning with minor
> changes like addition of some fields etc.
For instance, you might wa
On Thu, Mar 14, 2013 at 11:08:45PM +0200, Kasatkin, Dmitry wrote:
> On Thu, Mar 14, 2013 at 10:37 PM, Vivek Goyal wrote:
> > On Thu, Mar 14, 2013 at 04:30:28PM -0400, Vivek Goyal wrote:
> >
> > [..]
> >> I thought explicitly using signature format is more intu
RFC to show how one
can go about making use of IMA APIs for executable signature
verification.
Signed-off-by: Vivek Goyal
---
fs/Kconfig.binfmt | 12
fs/binfmt_elf.c | 44
2 files changed, 56 insertions(+), 0 deletions(-)
diff --git a
Export IMA functions so that other subsystems can use IMA for file
signature verification.
Signed-off-by: Vivek Goyal
---
include/linux/ima.h | 24 +++-
include/linux/integrity.h |7 ++
security/integrity/ima/ima_api.c | 16
it out so that
we can start a discussion on whether exporting IMA functions makes sense
and if it does, then how those functions should look like.
Thanks
Vivek
Vivek Goyal (4):
integrity: Identify asymmetric digital signature using new type
ima: export new IMA functions for signature
1 - 100 of 2045 matches
Mail list logo
