2017-05-23 21:53 GMT+02:00 Stephen Smalley :
> On Tue, 2017-05-23 at 18:29 +0200, Sebastien Buisson wrote:
>> Hi,
>>
>> 2017-05-18 23:49 GMT+02:00 Paul Moore :
>> > My apologies to you and Sebastien for not reviewing these patches
>> > sooner.
>>
&
2017-05-23 21:11 GMT+02:00 Paul Moore :
> On Tue, May 23, 2017 at 12:29 PM, Sebastien Buisson
> wrote:
>> Another way could be to add another hook to check policy brief info
>> validity. It would take a string as an input parameter, and return 0
>> if it matches the c
Hi,
2017-05-18 23:49 GMT+02:00 Paul Moore :
> My apologies to you and Sebastien for not reviewing these patches sooner.
It is ok, no problem.
Thanks for all the advice from you and Stephen. I will try to take all
this into account.
As I understand it, I should not give the choice to allocate or
Expose policy brief via selinuxfs.
Signed-off-by: Sebastien Buisson
---
security/selinux/selinuxfs.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index e8fe914..2561f96 100644
--- a/security/selinux
information is used to detect changes
to the policy on file system client nodes, and can be forwarded
to file system server nodes. Depending on how the policy is
enforced on client side, server can refuse connection.
Signed-off-by: Sebastien Buisson
---
include/linux/lsm_hooks.h | 20
2017-05-17 18:04 GMT+02:00 William Roberts :
> I'm assuming in the Lustre code you're going to call security_policy_brief(),
> how would the caller know how big that buffer is going to be?
We can determine it at configure time for instance, given that len as
an output parameter would give the size
2017-05-17 17:34 GMT+02:00 William Roberts :
> Is there a particular reason to not just return policybrief_len here as
> well, for consistency in the interface? How do you intend to use this
> value in the caller?
As called in the other patch to expose policy brief via selinu
2017-05-17 17:09 GMT+02:00 William Roberts :
> On Wed, May 17, 2017 at 7:59 AM, Sebastien Buisson
> wrote:
>> 2017-05-16 22:40 GMT+02:00 Stephen Smalley :
>>>> + strcpy(*brief, policydb.policybrief);
>>>> + /* *len is the length of the output string
2017-05-16 22:40 GMT+02:00 Stephen Smalley :
>> + strcpy(*brief, policydb.policybrief);
>> + /* *len is the length of the output string */
>> + *len = policybrief_len - 1;
>
> Is there a particular reason to not just return policybrief_len here as
> well, for consistency in the interfac
Expose policy brief via selinuxfs.
Signed-off-by: Sebastien Buisson
---
security/selinux/selinuxfs.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index e8fe914..2561f96 100644
--- a/security/selinux
information is used to detect changes
to the policy on file system client nodes, and can be forwarded
to file system server nodes. Depending on how the policy is
enforced on client side, server can refuse connection.
Signed-off-by: Sebastien Buisson
---
include/linux/lsm_hooks.h | 20
policy is enforced on Lustre client side,
Lustre servers can refuse connection.
Signed-off-by: Sebastien Buisson
---
include/linux/lsm_hooks.h | 17 +++
include/linux/security.h| 7 +++
security/security.c | 8
security/selinux/hooks.c
Expose policy brief via selinuxfs.
Signed-off-by: Sebastien Buisson
---
security/selinux/selinuxfs.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index e8fe914..2561f96 100644
--- a/security/selinux
2017-05-05 20:33 GMT+02:00 Casey Schaufler :
> How do you see policy_brief being used by a modules
> with dynamic policy?
Policy's brief is computed on the binary representation every time the
policy is loaded, and when enforce or checkreqprot are changed. It
should not be a problem with a dynamic
Expose policy brief via selinuxfs.
Signed-off-by: Sebastien Buisson
---
security/selinux/selinuxfs.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index 8c9f5b7..50f69c5 100644
--- a/security/selinux
hook to give access to policy brief to
the rest of the kernel. Lustre client makes use of this information
to detect changes to the policy, and forward it to Lustre servers.
Depending on how the policy is enforced on Lustre client side,
Lustre servers can refuse connection.
Signed-off-by: Sebas
hook to give access to policy brief to
the rest of the kernel. Lustre client makes use of this information.
Signed-off-by: Sebastien Buisson
---
include/linux/lsm_hooks.h | 2 +
include/linux/security.h| 7
security/security.c | 6 +++
security/sel
Expose policy brief via selinuxfs.
Signed-off-by: Sebastien Buisson
---
security/selinux/selinuxfs.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index b959ee7..8782b79 100644
--- a/security/selinux
2017-04-28 17:50 GMT+02:00 Stephen Smalley :
> You seem to be conflating kernel policy with userspace policy.
> security_load_policy() is provided with the kernel policy image, which
> is the result of linking the kernel-relevant portions of all policy
> modules together. A hash of that image will
2017-04-27 20:47 GMT+02:00 Stephen Smalley :
>> I just checked, with the method of computing the checksum on a (data,
>> len) pair on entry to security_load_policy() the checksum does not
>> change after using setsebool. So it seems I would need to call
>> security_read_policy() to retrieve the bin
2017-04-27 17:18 GMT+02:00 Stephen Smalley :
> Ok, that should work as long as you just want to validate that all the
> clients loaded the same policy file, and aren't concerned about non-
> persistent policy boolean changes.
As far as I understand, non-persistent policy boolean changes can
affect
2017-04-26 20:30 GMT+02:00 Stephen Smalley :
> This seems like an odd place to trigger the computation.
I noticed that the policy as exposed via /sys/fs/selinux/policy can
also be modified in security_set_bools(). So in order to limit the
places from where to compute the policy checksum, I moved t
2017-04-26 17:48 GMT+02:00 Daniel Jurgens :
> This was part of a larger patch set that hasn't been accepted yet. SELinux
> support for Inifiniband. Subsequent patches in that patch set will use it as
> well.
I revived this patch following Stephen Smalley's suggestion to base
the policy checksu
.
Signed-off-by: Sebastien Buisson
---
include/linux/lsm_hooks.h | 2 +
include/linux/security.h| 7 +++
security/security.c | 6 +++
security/selinux/hooks.c| 12 -
security/selinux/include/security.h | 2 +
security/selinux/ss/policydb.h
Expose policy SHA256 checksum via selinuxfs.
Signed-off-by: Sebastien Buisson
---
security/selinux/selinuxfs.c | 20
1 file changed, 20 insertions(+)
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index ce71718..b2d5deb 100644
--- a/security
-by: Sebastien Buisson
---
include/linux/security.h | 23 +++
security/security.c | 20
security/selinux/hooks.c | 12
3 files changed, 55 insertions(+)
diff --git a/include/linux/security.h b/include/linux/security.h
index af675b5..73a9c93
2017-04-12 18:24 GMT+02:00 Stephen Smalley :
> Maybe you want to register a notifier callback on policy reload? See
> the archives for the SELinux support for Infiniband RDMA patches (which
> seem to have stalled), which included LSM hooks and SELinux
> implementation to support notifications on po
2017-04-12 15:58 GMT+02:00 Stephen Smalley :
> Even your usage of selinux_is_enabled() looks suspect; that should
> probably go away. Only other user of it seems to be some cred validity
> checking that could be dropped as well.
Well the main reason for calling selinux_is_enabled() is performance
2017-04-12 16:35 GMT+02:00 Stephen Smalley :
> How are you using this SELinux information in the kernel and/or in
> userspace? What's the purpose of it? What are you comparing it
> against? Why do you care if it changes?
Enforcement status and policy version are compared to their previously
sto
2017-04-12 13:55 GMT+02:00 Paul Moore :
> As currently written this code isn't something we would want to merge
> upstream for two important reasons:
>
> * No clear user of this functionality. There needs to be a well
> defined user of this functionality in the kernel.
The use case for this new f
2017-04-12 13:55 GMT+02:00 Paul Moore :
> As currently written this code isn't something we would want to merge
> upstream for two important reasons:
>
> * No abstraction layer at the LSM interface. The core kernel code
> should not call directly into any specific LSM, all interaction should
> go
Add selinux_status_get_seq() function to give access to sequence
number of current SELinux policy loaded to the rest of the kernel.
Signed-off-by: Sebastien Buisson
---
include/linux/selinux.h | 7 +++
security/selinux/ss/status.c | 21 +
2 files changed, 28
Add selinux_is_enforced() function to give access to SELinux
enforcement to the rest of the kernel.
Signed-off-by: Sebastien Buisson
---
include/linux/selinux.h | 5 +
security/selinux/exports.c | 6 ++
security/selinux/hooks.c| 2 ++
security/selinux
reused)
The buffer-head per-CPU LRU size is raised to 16, as it shows in
metadata performance benchmarks up to 10% gain for create,
4% for lookup and 7% for destroy.
Signed-off-by: Liang Zhen
Signed-off-by: Andreas Dilger
Signed-off-by: Sebastien Buisson
---
fs/buffer.c |2 +-
1 files
Le 10/07/2014 09:07, Andrew Morton a écrit :
This hardwires 16 if ext4"a and 8 otherwise. There's no way for
anyone to alter this decision if they think it will be helpful (or
harmful) in their setup.
In fact I do not know how to let experienced people alter the value
without confusing the o
Allow increasing the buffer-head per-CPU LRU size to allow efficient
filesystem operations that access many blocks for each transaction.
For example, creating a file in a large ext4 directory with quota
enabled will accesses multiple buffer heads and will overflow the LRU
at the default 8-block LR
Can anyone demonstrate why we shouldn't just do
I was assuming due to memory usage: with 4K blocks 32K->64K
Moreover, performance gain was not that satisfactory on ext4 when
increasing BH_LRU_SIZE to 16.
Here are the performances I got with:
(a) mdtest on ramdisk device, single shared dir
*/
-
-#define BH_LRU_SIZE8
+#define BH_LRU_SIZECONFIG_BH_LRU_SIZE
struct bh_lru {
struct buffer_head *bhs[BH_LRU_SIZE];
--
1.7.1
Le 06/07/2014 18:18, Andi Kleen a écrit :
Sebastien Buisson writes:
Allow increasing the buffer-head per-CPU LRU size to allow efficient
filesystem oper
Allow increasing the buffer-head per-CPU LRU size to allow efficient
filesystem operations that access many blocks for each transaction.
For example, creating a file in a large ext4 directory with quota
enabled will accesses multiple buffer heads and will overflow the LRU
at the default 8-block LR
Allow increasing the buffer-head per-CPU LRU size to allow efficient
filesystem operations that access many blocks for each transaction.
For example, creating a file in a large ext4 directory with quota
enabled will accesses multiple buffer heads and will overflow the LRU
at the default 8-block LR
Le 26/06/2014 00:16, Andrew Morton a écrit :
On Tue, 24 Jun 2014 17:52:00 +0200 Sebastien Buisson
wrote:
Allow increasing the buffer-head per-CPU LRU size to allow efficient
filesystem operations that access many blocks for each transaction.
For example, creating a file in a large ext4
one cache entry)
* 2 levels htree blocks (only one is reused, other pollutes cache)
* 2 levels indirect/index blocks (only one is reused)
Make this tuning be a kernel parameter 'bh_lru_size'.
Signed-off-by: Liang Zhen
Signed-off-by: Andreas Dilger
Signed-off-by: Sebastien Buisson
---
42 matches
Mail list logo
