<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/security/smack, branch v3.5-rc6</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>split -&gt;file_mmap() into -&gt;mmap_addr()/-&gt;mmap_file()</title>
<updated>2012-05-31T17:11:54+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2012-05-30T17:30:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e5467859f7f79b69fc49004403009dfdba3bec53'/>
<id>e5467859f7f79b69fc49004403009dfdba3bec53</id>
<content type='text'>
... i.e. file-dependent and address-dependent checks.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
... i.e. file-dependent and address-dependent checks.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>split cap_mmap_addr() out of cap_file_mmap()</title>
<updated>2012-05-31T17:10:54+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2012-05-30T17:11:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d007794a182bc072a7b7479909dbd0d67ba341be'/>
<id>d007794a182bc072a7b7479909dbd0d67ba341be</id>
<content type='text'>
... switch callers.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
... switch callers.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'master' of git://git.infradead.org/users/eparis/selinux into next</title>
<updated>2012-05-22T01:21:06+00:00</updated>
<author>
<name>James Morris</name>
<email>james.l.morris@oracle.com</email>
</author>
<published>2012-05-22T01:21:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ff2bb047c4bce9742e94911eeb44b4d6ff4734ab'/>
<id>ff2bb047c4bce9742e94911eeb44b4d6ff4734ab</id>
<content type='text'>
Per pull request, for 3.5.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Per pull request, for 3.5.
</pre>
</div>
</content>
</entry>
<entry>
<title>Smack: allow for significantly longer Smack labels v4</title>
<updated>2012-05-15T05:48:38+00:00</updated>
<author>
<name>Casey Schaufler</name>
<email>casey@schaufler-ca.com</email>
</author>
<published>2012-05-06T22:22:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f7112e6c9abf1c70f001dcf097c1d6e218a93f5c'/>
<id>f7112e6c9abf1c70f001dcf097c1d6e218a93f5c</id>
<content type='text'>
V4 updated to current linux-security#next
Targeted for git://gitorious.org/smack-next/kernel.git

Modern application runtime environments like to use
naming schemes that are structured and generated without
human intervention. Even though the Smack limit of 23
characters for a label name is perfectly rational for
human use there have been complaints that the limit is
a problem in environments where names are composed from
a set or sources, including vendor, author, distribution
channel and application name. Names like

	softwarehouse-pgwodehouse-coolappstore-mellowmuskrats

are becoming harder to avoid. This patch introduces long
label support in Smack. Labels are now limited to 255
characters instead of the old 23.

The primary reason for limiting the labels to 23 characters
was so they could be directly contained in CIPSO category sets.
This is still done were possible, but for labels that are too
large a mapping is required. This is perfectly safe for communication
that stays "on the box" and doesn't require much coordination
between boxes beyond what would have been required to keep label
names consistent.

The bulk of this patch is in smackfs, adding and updating
administrative interfaces. Because existing APIs can't be
changed new ones that do much the same things as old ones
have been introduced.

The Smack specific CIPSO data representation has been removed
and replaced with the data format used by netlabel. The CIPSO
header is now computed when a label is imported rather than
on use. This results in improved IP performance. The smack
label is now allocated separately from the containing structure,
allowing for larger strings.

Four new /smack interfaces have been introduced as four
of the old interfaces strictly required labels be specified
in fixed length arrays.

The access interface is supplemented with the check interface:
	access  "Subject                 Object                  rwxat"
	access2 "Subject Object rwaxt"

The load interface is supplemented with the rules interface:
	load   "Subject                 Object                  rwxat"
	load2  "Subject Object rwaxt"

The load-self interface is supplemented with the self-rules interface:
	load-self   "Subject                 Object                  rwxat"
	load-self2  "Subject Object rwaxt"

The cipso interface is supplemented with the wire interface:
	cipso  "Subject                  lvl cnt  c1  c2 ..."
	cipso2 "Subject lvl cnt  c1  c2 ..."

The old interfaces are maintained for compatibility.

Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
V4 updated to current linux-security#next
Targeted for git://gitorious.org/smack-next/kernel.git

Modern application runtime environments like to use
naming schemes that are structured and generated without
human intervention. Even though the Smack limit of 23
characters for a label name is perfectly rational for
human use there have been complaints that the limit is
a problem in environments where names are composed from
a set or sources, including vendor, author, distribution
channel and application name. Names like

	softwarehouse-pgwodehouse-coolappstore-mellowmuskrats

are becoming harder to avoid. This patch introduces long
label support in Smack. Labels are now limited to 255
characters instead of the old 23.

The primary reason for limiting the labels to 23 characters
was so they could be directly contained in CIPSO category sets.
This is still done were possible, but for labels that are too
large a mapping is required. This is perfectly safe for communication
that stays "on the box" and doesn't require much coordination
between boxes beyond what would have been required to keep label
names consistent.

The bulk of this patch is in smackfs, adding and updating
administrative interfaces. Because existing APIs can't be
changed new ones that do much the same things as old ones
have been introduced.

The Smack specific CIPSO data representation has been removed
and replaced with the data format used by netlabel. The CIPSO
header is now computed when a label is imported rather than
on use. This results in improved IP performance. The smack
label is now allocated separately from the containing structure,
allowing for larger strings.

Four new /smack interfaces have been introduced as four
of the old interfaces strictly required labels be specified
in fixed length arrays.

The access interface is supplemented with the check interface:
	access  "Subject                 Object                  rwxat"
	access2 "Subject Object rwaxt"

The load interface is supplemented with the rules interface:
	load   "Subject                 Object                  rwxat"
	load2  "Subject Object rwaxt"

The load-self interface is supplemented with the self-rules interface:
	load-self   "Subject                 Object                  rwxat"
	load-self2  "Subject Object rwaxt"

The cipso interface is supplemented with the wire interface:
	cipso  "Subject                  lvl cnt  c1  c2 ..."
	cipso2 "Subject lvl cnt  c1  c2 ..."

The old interfaces are maintained for compatibility.

Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>gfp flags for security_inode_alloc()?</title>
<updated>2012-05-15T05:47:44+00:00</updated>
<author>
<name>Tetsuo Handa</name>
<email>penguin-kernel@I-love.SAKURA.ne.jp</email>
</author>
<published>2012-03-29T07:19:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ceffec5541cc22486d3ff492e3d76a33a68fbfa3'/>
<id>ceffec5541cc22486d3ff492e3d76a33a68fbfa3</id>
<content type='text'>
Dave Chinner wrote:
&gt; Yes, because you have no idea what the calling context is except
&gt; for the fact that is from somewhere inside filesystem code and the
&gt; filesystem could be holding locks. Therefore, GFP_NOFS is really the
&gt; only really safe way to allocate memory here.

I see. Thank you.

I'm not sure, but can call trace happen where somewhere inside network
filesystem or stackable filesystem code with locks held invokes operations that
involves GFP_KENREL memory allocation outside that filesystem?
----------
[PATCH] SMACK: Fix incorrect GFP_KERNEL usage.

new_inode_smack() which can be called from smack_inode_alloc_security() needs
to use GFP_NOFS like SELinux's inode_alloc_security() does, for
security_inode_alloc() is called from inode_init_always() and
inode_init_always() is called from xfs_inode_alloc() which is using GFP_NOFS.

smack_inode_init_security() needs to use GFP_NOFS like
selinux_inode_init_security() does, for initxattrs() callback function (e.g.
btrfs_initxattrs()) which is called from security_inode_init_security() is
using GFP_NOFS.

smack_audit_rule_match() needs to use GFP_ATOMIC, for
security_audit_rule_match() can be called from audit_filter_user_rules() and
audit_filter_user_rules() is called from audit_filter_user() with RCU read lock
held.

Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: Casey Schaufler &lt;cschaufler@cschaufler-intel.(none)&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Dave Chinner wrote:
&gt; Yes, because you have no idea what the calling context is except
&gt; for the fact that is from somewhere inside filesystem code and the
&gt; filesystem could be holding locks. Therefore, GFP_NOFS is really the
&gt; only really safe way to allocate memory here.

I see. Thank you.

I'm not sure, but can call trace happen where somewhere inside network
filesystem or stackable filesystem code with locks held invokes operations that
involves GFP_KENREL memory allocation outside that filesystem?
----------
[PATCH] SMACK: Fix incorrect GFP_KERNEL usage.

new_inode_smack() which can be called from smack_inode_alloc_security() needs
to use GFP_NOFS like SELinux's inode_alloc_security() does, for
security_inode_alloc() is called from inode_init_always() and
inode_init_always() is called from xfs_inode_alloc() which is using GFP_NOFS.

smack_inode_init_security() needs to use GFP_NOFS like
selinux_inode_init_security() does, for initxattrs() callback function (e.g.
btrfs_initxattrs()) which is called from security_inode_init_security() is
using GFP_NOFS.

smack_audit_rule_match() needs to use GFP_ATOMIC, for
security_audit_rule_match() can be called from audit_filter_user_rules() and
audit_filter_user_rules() is called from audit_filter_user() with RCU read lock
held.

Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: Casey Schaufler &lt;cschaufler@cschaufler-intel.(none)&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Smack: recursive tramsmute</title>
<updated>2012-05-15T05:45:17+00:00</updated>
<author>
<name>Casey Schaufler</name>
<email>casey@schaufler-ca.com</email>
</author>
<published>2012-03-14T02:14:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2267b13a7cad1f9dfe0073c1f902d45953f9faff'/>
<id>2267b13a7cad1f9dfe0073c1f902d45953f9faff</id>
<content type='text'>
The transmuting directory feature of Smack requires that
the transmuting attribute be explicitly set in all cases.
It seems the users of this facility would expect that the
transmuting attribute be inherited by subdirectories that
are created in a transmuting directory. This does not seem
to add any additional complexity to the understanding of
how the system works.

Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The transmuting directory feature of Smack requires that
the transmuting attribute be explicitly set in all cases.
It seems the users of this facility would expect that the
transmuting attribute be inherited by subdirectories that
are created in a transmuting directory. This does not seem
to add any additional complexity to the understanding of
how the system works.

Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Smack: move label list initialization</title>
<updated>2012-04-18T02:02:28+00:00</updated>
<author>
<name>Casey Schaufler</name>
<email>casey@schaufler-ca.com</email>
</author>
<published>2012-04-18T01:55:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=86812bb0de1a3758dc6c7aa01a763158a7c0638a'/>
<id>86812bb0de1a3758dc6c7aa01a763158a7c0638a</id>
<content type='text'>
A kernel with Smack enabled will fail if tmpfs has xattr support.

Move the initialization of predefined Smack label
list entries to the LSM initialization from the
smackfs setup. This became an issue when tmpfs
acquired xattr support, but was never correct.

Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A kernel with Smack enabled will fail if tmpfs has xattr support.

Move the initialization of predefined Smack label
list entries to the LSM initialization from the
smackfs setup. This became an issue when tmpfs
acquired xattr support, but was never correct.

Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Smack: build when CONFIG_AUDIT not defined</title>
<updated>2012-04-10T23:14:40+00:00</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2012-04-10T20:26:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=923e9a1399b620d063cd88537c64561bc3d5f905'/>
<id>923e9a1399b620d063cd88537c64561bc3d5f905</id>
<content type='text'>
This fixes builds where CONFIG_AUDIT is not defined and
CONFIG_SECURITY_SMACK=y.

This got introduced by the stack-usage reducation commit 48c62af68a40
("LSM: shrink the common_audit_data data union").

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Acked-by: Eric Paris &lt;eparis@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes builds where CONFIG_AUDIT is not defined and
CONFIG_SECURITY_SMACK=y.

This got introduced by the stack-usage reducation commit 48c62af68a40
("LSM: shrink the common_audit_data data union").

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Acked-by: Eric Paris &lt;eparis@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>LSM: do not initialize common_audit_data to 0</title>
<updated>2012-04-09T16:23:04+00:00</updated>
<author>
<name>Eric Paris</name>
<email>eparis@redhat.com</email>
</author>
<published>2012-04-04T19:01:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=50c205f5e5c2e2af002fd4ef537ded79b90b1b56'/>
<id>50c205f5e5c2e2af002fd4ef537ded79b90b1b56</id>
<content type='text'>
It isn't needed.  If you don't set the type of the data associated with
that type it is a pretty obvious programming bug.  So why waste the cycles?

Signed-off-by: Eric Paris &lt;eparis@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It isn't needed.  If you don't set the type of the data associated with
that type it is a pretty obvious programming bug.  So why waste the cycles?

Signed-off-by: Eric Paris &lt;eparis@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>SELinux: rename dentry_open to file_open</title>
<updated>2012-04-09T16:22:50+00:00</updated>
<author>
<name>Eric Paris</name>
<email>eparis@redhat.com</email>
</author>
<published>2012-04-04T17:45:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=83d498569e9a7a4b92c4c5d3566f2d6a604f28c9'/>
<id>83d498569e9a7a4b92c4c5d3566f2d6a604f28c9</id>
<content type='text'>
dentry_open takes a file, rename it to file_open

Signed-off-by: Eric Paris &lt;eparis@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
dentry_open takes a file, rename it to file_open

Signed-off-by: Eric Paris &lt;eparis@redhat.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
