From: Tejun Heo <tj@kernel.org>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: CHANDAN VN <chandan.vn@samsung.com>,
gregkh@linuxfoundation.org, bfields@fieldses.org,
jlayton@kernel.org, linux-kernel@vger.kernel.org,
linux-nfs@vger.kernel.org, cpgs@samsung.com,
sireesha.t@samsung.com, Chris Wright <chrisw@sous-sol.org>,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH 1/1] Fix memory leak in kernfs_security_xattr_set and kernfs_security_xattr_set
Date: Thu, 31 May 2018 09:11:07 -0700 [thread overview]
Message-ID: <20180531161107.GV1351649@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <4f00f9ae-3302-83b9-c083-d21ade380eb2@schaufler-ca.com>
On Thu, May 31, 2018 at 09:04:25AM -0700, Casey Schaufler wrote:
> On 5/31/2018 8:39 AM, Tejun Heo wrote:
> > (cc'ing more security folks and copying whole body)
> >
> > So, I'm sure the patch fixes the memory leak but API wise it looks
> > super confusing. Can security folks chime in here? Is this the right
> > fix?
>
> security_inode_getsecctx() provides a security context. Technically,
> this is a data blob, although both provider provide a null terminated
> string. security_inode_getsecurity(), on the other hand, provides a
> string to match an attribute name. The former releases the security
> context with security_release_secctx(), where the later releases the
> string with kfree().
>
> When the Smack hook smack_inode_getsecctx() was added in 2009
> for use by labeled NFS the alloc value passed to
> smack_inode_getsecurity() was set incorrectly. This wasn't a
> major issue, since labeled NFS is a fringe case. When kernfs
> started using the hook, it became the issue you discovered.
>
> The reason that we have all this confusion is that SELinux
> generates security contexts as needed, while Smack keeps them
> around all the time. Releasing an SELinux context frees memory,
> while releasing a Smack context is a null operation.
Any chance this detail can be hidden behind security api? This looks
pretty error-prone, no?
Thanks.
--
tejun
WARNING: multiple messages have this Message-ID (diff)
From: tj@kernel.org (Tejun Heo)
To: linux-security-module@vger.kernel.org
Subject: [PATCH 1/1] Fix memory leak in kernfs_security_xattr_set and kernfs_security_xattr_set
Date: Thu, 31 May 2018 09:11:07 -0700 [thread overview]
Message-ID: <20180531161107.GV1351649@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <4f00f9ae-3302-83b9-c083-d21ade380eb2@schaufler-ca.com>
On Thu, May 31, 2018 at 09:04:25AM -0700, Casey Schaufler wrote:
> On 5/31/2018 8:39 AM, Tejun Heo wrote:
> > (cc'ing more security folks and copying whole body)
> >
> > So, I'm sure the patch fixes the memory leak but API wise it looks
> > super confusing. Can security folks chime in here? Is this the right
> > fix?
>
> security_inode_getsecctx() provides a security context. Technically,
> this is a data blob, although both provider provide a null terminated
> string. security_inode_getsecurity(), on the other hand, provides a
> string to match an attribute name. The former releases the security
> context with security_release_secctx(), where the later releases the
> string with kfree().
>
> When the Smack hook smack_inode_getsecctx() was added in 2009
> for use by labeled NFS the alloc value passed to
> smack_inode_getsecurity() was set incorrectly. This wasn't a
> major issue, since labeled NFS is a fringe case. When kernfs
> started using the hook, it became the issue you discovered.
>
> The reason that we have all this confusion is that SELinux
> generates security contexts as needed, while Smack keeps them
> around all the time. Releasing an SELinux context frees memory,
> while releasing a Smack context is a null operation.
Any chance this detail can be hidden behind security api? This looks
pretty error-prone, no?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-05-31 16:11 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20180531092848epcas1p24b638ccd6da00f1e039bdb64de7e1a5b@epcas1p2.samsung.com>
2018-05-31 9:28 ` [PATCH 1/1] Fix memory leak in kernfs_security_xattr_set and kernfs_security_xattr_set CHANDAN VN
2018-05-31 15:26 ` Casey Schaufler
2018-05-31 20:57 ` Eric W. Biederman
2018-05-31 21:08 ` Casey Schaufler
2018-05-31 15:39 ` Tejun Heo
2018-05-31 15:39 ` Tejun Heo
2018-05-31 16:04 ` Casey Schaufler
2018-05-31 16:04 ` Casey Schaufler
2018-05-31 16:11 ` Tejun Heo [this message]
2018-05-31 16:11 ` Tejun Heo
2018-05-31 16:22 ` Casey Schaufler
2018-05-31 16:22 ` Casey Schaufler
2018-06-01 8:56 ` CHANDAN VN
2018-06-01 8:56 ` CHANDAN VN
2018-06-01 8:56 ` CHANDAN VN
2018-06-01 16:22 ` Casey Schaufler
2018-06-01 16:22 ` Casey Schaufler
2018-06-01 16:29 ` CHANDAN VN
2018-06-01 16:29 ` CHANDAN VN
2018-06-01 16:29 ` CHANDAN VN
2018-06-01 16:41 ` Casey Schaufler
2018-06-01 16:41 ` Casey Schaufler
2018-06-01 17:45 ` [PATCH] Smack: Fix memory leak in smack_inode_getsecctx Casey Schaufler
2018-06-01 17:45 ` Casey Schaufler
2018-06-04 21:01 ` Casey Schaufler
2018-06-04 21:01 ` Casey Schaufler
2018-06-04 21:27 ` Tejun Heo
2018-06-04 21:27 ` Tejun Heo
2018-06-05 7:04 ` CHANDAN VN
2018-06-05 7:04 ` CHANDAN VN
2018-06-05 7:04 ` CHANDAN VN
2018-06-05 14:29 ` Casey Schaufler
2018-06-05 14:46 ` CHANDAN VN
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180531161107.GV1351649@devbig577.frc2.facebook.com \
--to=tj@kernel.org \
--cc=bfields@fieldses.org \
--cc=casey@schaufler-ca.com \
--cc=chandan.vn@samsung.com \
--cc=chrisw@sous-sol.org \
--cc=cpgs@samsung.com \
--cc=gregkh@linuxfoundation.org \
--cc=jlayton@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sireesha.t@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.