lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e7d8f83e0808120141s4a0561fdw4919ce6f74d211af@mail.gmail.com>
Date:	Tue, 12 Aug 2008 18:41:16 +1000
From:	"Peter Dolding" <oiaohm@...il.com>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	"Mimi Zohar" <zohar@...ibm.com>, serue@...ux.vnet.ibm.com,
	"Christoph Hellwig" <hch@...radead.org>,
	"James Morris" <jmorris@...ei.org>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	"Randy Dunlap" <randy.dunlap@...cle.com>, safford@...son.ibm.com,
	sailer@...son.ibm.com, "Stephen Smalley" <sds@...ho.nsa.gov>,
	"Al Viro" <viro@...iv.linux.org.uk>,
	"Mimi Zohar" <zohar@...ux.vnet.ibm.com>
Subject: Re: [PATCH 3/4] integrity: Linux Integrity Module(LIM)

On Tue, Aug 12, 2008 at 5:56 AM, Serge E. Hallyn <serue@...ibm.com> wrote:
> Quoting Mimi Zohar (zohar@...ibm.com):
>> serue@...ux.vnet.ibm.com wrote on 08/11/2008 01:02:55 PM:
>>
>> > Quoting Mimi Zohar (zohar@...ibm.com):
>> > > Christoph Hellwig <hch@...radead.org> wrote on 08/09/2008 02:53:40 PM:
>> > > > >  int vfs_permission(struct nameidata *nd, int mask)
>> > > > >  {
>> > > > > -   return inode_permission(nd->path.dentry->d_inode, mask);
>> > > > > +   int retval;
>> > > > > +
>> > > > > +   retval = inode_permission(nd->path.dentry->d_inode, mask);
>> > > > > +   if (retval)
>> > > > > +      return retval;
>> > > > > +   return integrity_inode_permission(NULL, &nd->path,
>> > > > > +                 mask & (MAY_READ | MAY_WRITE |
>> > > > > +                    MAY_EXEC));
>> > > > >  }
>> > > > >
>> > > > >  /**
>> > > > > @@ -306,7 +314,14 @@ int vfs_permission(struct nameidata *nd,
>> > > > >   */
>> > > > >  int file_permission(struct file *file, int mask)
>> > > > >  {
>> > > > > -   return inode_permission(file->f_path.dentry->d_inode, mask);
>> > > > > +   int retval;
>> > > > > +
>> > > > > +   retval = inode_permission(file->f_path.dentry->d_inode, mask);
>> > > > > +   if (retval)
>> > > > > +      return retval;
>> > > > > +   return integrity_inode_permission(file, NULL,
>> > > > > +                 mask & (MAY_READ | MAY_WRITE |
>> > > > > +                    MAY_EXEC));
>> > > >
>> > > > Please put your hook into inode_permission.  Note that in inode
>> > > > permission and lots of callers there is no path available so don't
>> pass
>> > > > it.  Please pass the full MAY_FOO mask for new interfaces and do
>> > > > filtering that won't break if new ones are introduced.
>> > >
>> > > We started out with the integrity_inode_permission() hook call in
>> > > inode_permission(), but because of the removal of the nameidata
>> > > parameter in the last merge, based on discussions
>> > > http://marc.info/?l=linux-security-module&m=121797845308246&w=2,
>> > > the call to integrity_inode_permission() was moved up to the caller,
>> > > where either a file or path are available.  Any suggestions?
>> >
>> > Mimi, can you explain exactly (and concisely) what you are doing with
>> > the pathname?
>>
>> IMA maintains a list of hash values of system sensitive files loaded
>> into the run-time of the system and extends a PCR with the hash value.
>> In order to calculate this hash value, IMA requires access to either
>> the file or the path, which currently is not accessible in
>> inode_permission().
>
> So the usual question is, if I've done
>        ln -s /etc/shadow /tmp/shadow
> will IMA do the right thing if I'm opening /tmp/shadow?  Or will it only
> catch any writes I've done the next time someone (i.e. passwd) opens
> /etc/shadow?
>
> thanks,
> -serge

We really do need to get credentials patch in to common store all this
permission/secuirty data..  With a section for integrity related
entries.

Anti-Virus Passes and fails, signed running programs support and so on.

Lot of different things need ways of recording integrity status's.
Users also need to know if a application does not work is it TPM is it
Anti-virus is it lack of signature.

A common way of extracting what the blockage has to be the way
forward.  Since then this can be integrated into file managers and the
like.  Running like 12 different tools to find what blocked a program
is kinda wasteful.

 Sorting out this storage is kinda critical.  People could be running
a few different integrity systems side by side.

Peter Dolding
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ