On Wed, 2007-03-07 at 16:07 -0800, David Miller wrote:
From: David Miller [EMAIL PROTECTED]
Date: Wed, 07 Mar 2007 15:43:16 -0800 (PST)
From: Eric Paris [EMAIL PROTECTED]
Date: Fri, 02 Mar 2007 13:51:24 -0500
pfkey_spdget neither had an LSM security hook nor auditing
the
initialization would cause err to be ENOENT. But since err has since
been used above when we don't get a policy back from the xfrm_policy_by*
function we would always return 0 instead of the intended ENOENT. Also
fixed some white space damage in the same area.
Signed-off-by: Eric Paris [EMAIL PROTECTED
pfkey_spdget neither had an LSM security hook nor auditing for the
removal of xfrm_policy structs. The security hook was added when it was
moved into xfrm_policy_byid instead of the callers to that function by
my earlier patch and this patch adds the auditing hooks as well.
Signed-off-by: Eric
(and successes) will actually get audited.
Signed-off-by: Eric Paris [EMAIL PROTECTED]
net/key/af_key.c |5 ++---
net/xfrm/xfrm_user.c |5 ++---
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 1c58204..d8fc88c 100644
--- a/net/key/af_key.c
On Mon, 2007-03-05 at 11:39 -0500, James Morris wrote:
On Mon, 5 Mar 2007, Venkat Yekkirala wrote:
Signed-off-by: Eric Paris [EMAIL PROTECTED]
Acked-by: Venkat Yekkirala [EMAIL PROTECTED]
What about your previous comment:
I guess you meant to do this here?
else if (err
[snip from fs/super.c:vfs_kern_mount() just for reference]
if (data) {
secdata = alloc_secdata();
if (!secdata)
goto out_mnt;
error = security_sb_copy_data(type, data, secdata);
if (error)
no matter
what. So we should not both compiling in this rounding if it is just a
waste of time.
Signed-off-by: Eric Paris [EMAIL PROTECTED]
---
mm/mmap.c | 10 ++
mm/nommu.c | 10 ++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index
that any process with this capability can harm the system a lot
more easily than writing some stuff on the zero page and then trying to
get the kernel to trip over itself. It also means that programs like X
on i686 which use vm86 emulation can work even with mmap_min_addr set.
Signed-off-by: Eric Paris
against this missed code path.
Signed-off-by: Eric Paris [EMAIL PROTECTED]
---
** Be very careful applying/rediffing this patch. Standard 3 lines of
context from git diff will misapply the first hunk to expand_upwards
instead of properly in expand_downwards. This patch was generated using
-U 4
On Sat, 2007-11-17 at 08:42 +1100, James Morris wrote:
On Fri, 16 Nov 2007, Eric Paris wrote:
+#ifdef CONFIG_SECURITY
+ /*
+* If a hint addr is less than mmap_min_addr change addr to be as
+* low as possible but still greater than mmap_min_addr
+*/
+ if (!(flags
On Sat, 2007-11-17 at 08:47 +1100, James Morris wrote:
On Fri, 16 Nov 2007, Eric Paris wrote:
On a kernel with CONFIG_SECURITY but without an LSM which implements
security_file_mmap it is impossible for an application to mmap addresses
lower than mmap_min_addr.
Actually, should we
On Sat, 2007-11-17 at 08:58 +1100, James Morris wrote:
On Fri, 16 Nov 2007, Eric Paris wrote:
On Sat, 2007-11-17 at 08:47 +1100, James Morris wrote:
On Fri, 16 Nov 2007, Eric Paris wrote:
On a kernel with CONFIG_SECURITY but without an LSM which implements
security_file_mmap
Since it was decided that low memory protection from userspace couldn't
be turned on by default add a Kconfig option to allow users/distros to
set a default at compile time. This value is still tunable after boot
in /proc/sys/vm/mmap_min_addr
Signed-off-by: Eric Paris [EMAIL PROTECTED
-off-by: James Morris [EMAIL PROTECTED]
Acked-by: Eric Paris [EMAIL PROTECTED]
---
mm.h |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 1b7b95c..02fbac7 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
On Thu, 2007-12-20 at 00:29 +0100, Jan Engelhardt wrote:
On Dec 19 2007 16:59, Eric Paris wrote:
+config SECURITY_DEFAULT_MMAP_MIN_ADDR
+int Low address space to protect from user allocation
Hm, should not this be 'hex'?
I guess it could be, but the input for /proc/sys/vm
Given a specifically crafted binary do_brk() can be used to get low
pages available in userspace virtually memory and can thus be used to
circumvent the mmap_min_addr low memory protection. Add security checks
in do_brk().
Signed-off-by: Eric Paris [EMAIL PROTECTED]
---
mm/mmap.c |4
On Sat, 2007-11-17 at 09:12 +1100, James Morris wrote:
On Fri, 16 Nov 2007, Eric Paris wrote:
When this protection was originally concieved it intentionally was
offing something even without an more 'full featured' LSM. That was the
whole reason I had to drop the secondary stacking hook
Add security checks to make sure we are not attempting to expand the
stack into memory protected by mmap_min_addr
Signed-off-by: Eric Paris [EMAIL PROTECTED]
---
** Be very careful applying/rediffing this patch. Standard 3 lines of
context from git diff will misapply the first hunk
no matter
what. So we should not bother compiling in this rounding if it is just a
waste of time.
Signed-off-by: Eric Paris [EMAIL PROTECTED]
---
include/linux/mm.h | 16
mm/mmap.c |3 +++
mm/nommu.c |3 +++
3 files changed, 22 insertions(+), 0 deletions
that any process with this capability can harm the system a lot
more easily than writing some stuff on the zero page and then trying to
get the kernel to trip over itself. It also means that programs like X
on i686 which use vm86 emulation can work even with mmap_min_addr set.
Signed-off-by: Eric Paris
On Fri, 2007-12-21 at 23:59 +0100, Jan Engelhardt wrote:
On Dec 21 2007 14:35, Greg KH wrote:
I guess it could be, but the input for /proc/sys/vm/mmap_min_addr is
base 10 as well
sysfs is autobase, i.e. echo 0xb000 /sys/foo will Do The Right Thing.
yes but if you cat
On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
But that doesn't really help me: untrusted root is an oxymoron.
Imagine you run windows and you've never heard of Linux. You like
that only windows kernels can boot on your box and not those mean
nasty
On Thu, Nov 1, 2012 at 10:42 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
On Thu, 2012-11-01 at 10:29 -0400, Eric Paris wrote:
On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
But that doesn't really help me: untrusted root
On Thu, Nov 1, 2012 at 10:46 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Imagine you run windows and you've never heard of Linux.
To those people I think you mean never heard of Ubuntu ;-)
:-)
With all the current posted RH patches I can still take over
the box as root trivially enough and
On Thu, Nov 1, 2012 at 11:06 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
But surely that's fanciful ... you've already compromised windows to get
access to the ESP. If you've done it once, you can do it again until
the exploit is patched.
You work under the assumption
On Thu, Nov 1, 2012 at 11:18 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
You're completely confusing two separate goals:
1. Is it possible to use secure boot to implement a security policy
on Linux
2. What do we have to do anything to prevent Linux
I know I started it, but Windows really isn't necessary to see value,
even if it is what pushed the timing.
A user installs a package as root. Absent any flaws in the Linux
kernel (cough) that should be all it can do in a Secure Boot world.
But if you can drop a small trusted Linux system in
On Sat, Nov 3, 2012 at 12:31 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
You're guaranteed to be able
to do this on any Windows 8 certified hardware.
Thats not my understanding of the situation.
Windows 8 certification has this as a requirement for x86 hardware. I
belied the opposite is a
It looks like smack_lsm.c includes linux/magic.h, but smackfs.c
doesn't... Seems like they should have included linux/magic.h in the
same header they removed the definition from
On Tue, Nov 6, 2012 at 4:59 PM, Casey Schaufler ca...@schaufler-ca.com wrote:
On 11/6/2012 12:17 AM, Jarkko
Then it only works by accident that magic.h is included by some random
path in smackfs.c. You really should be including it in smack.h (or
each .c file individually, up to casey)
On Thu, Nov 8, 2012 at 5:43 AM, Jarkko Sakkinen jarkko.sakki...@iki.fi wrote:
On Tue, Nov 6, 2012 at 11:59 PM, Casey
OMG this +1 -1 stuff is nuts...
iterate_fd passes fd+1 instead of the fd for the file? seriously?
e. I see how this patch fixes it, but still, wouldn't some magic
or negative value for no entries found be better than having to
understand the crazy logics?
/me pokes Al.
On Sun, Nov 11,
argument which
could
pretty easily oom.
a single argument larger than MAX_EXECVE_AUDIT_LEN is broken into multiple
records and have a format like a10[0] a10[1] a10[2] etc.
Signed-off-by: Eric Paris [EMAIL PROTECTED]
---
example audit log (about 50k long) for the whole
Break the auditing of a list of execve arguments into smaller records if
there
are a too many. The limit is currently around 7.5k of arguments as
userspace
has an 8k buffer limit and will drop messages which are longer.
Signed-off-by: Eric Paris [EMAIL PROTECTED
Remove the limitation on argv size. The audit system now logs arguments in
smaller chunks (currently about 8k due to userspace audit system buffer
sizes)
so this is no longer a requirement.
Signed-off-by: Eric Paris [EMAIL PROTECTED]
Acked-by: Peter Zijlstra [EMAIL PROTECTED
Patches 1 and 2 I applied for 3.10, but I'd really like to have someone who
knows PPC ack 3 and 4. Especially if there is a hope that it goes through my
tree...
Link to original messages for your ease of review...
http://marc.info/?l=linux-kernelm=135768892320439w=2
net/netlink.h includes linux/netlink.h but linux/netlink.h does not include
net/netlink.h
since the audit code uses the nlmsg_* functions provided in net/netlink.h it
seems we need this include.
since the audit code uses netlink_unicast provided in linux/netlink.h it seems
we need that
- Original Message -
__audit_socketcall is an extern function.
better to check its parameters by itself.
also can return error code, when fail (find invalid parameters).
also use macro instead of real hard code number
also give related comments for it.
We only allow one filter key per rule. So we should never be able to get into
this situation. See audit_data_to_entry()
-Eric
- Original Message -
in the 'fcount' looping,
if 'new-fields[*].type has 2 or more AUDIT_FILTERKEYs
need judge new-filterkey whether has value,
- Original Message -
in another function: audit_data_to_entry:
a. has the same issue for case AUDIT_WATCH.
You are saying if there were 2 of them it will leak the old one? No. If you
have 2 AUDIT_WATCH entries the first one will set entry-rule-watch and the
second will bomb
- Original Message -
b. has an new issue for AUDIT_DIR:
after AUDIT_DIR succeed, it will set rule-tree.
next, the other case fail, then will call audit_free_rule.
but audit_free_rule will not free rule-tree.
Definitely a couple of leaks here...
I'm seeing
- Original Message -
also for function audit_list:
when call audit_make_reply fails (will return NULL).
we need free all its related variables instead of only kfree rull.
(such as call autit_free_rule)
please help check, thanks.
audit_free_rule() takes a struct
- Original Message -
also for function audit_list_rules:
when call audit_make_reply fails (will return NULL).
we also need process data-buf, not only data itself.
please help check, thanks.
struct audit_rule_data {
[...]
charbuf[0]; /* string fields
- Original Message -
On 2013年04月11日 05:19, Eric Paris wrote:
- Original Message -
b. has an new issue for AUDIT_DIR:
after AUDIT_DIR succeed, it will set rule-tree.
next, the other case fail, then will call audit_free_rule
by this
file.
-Original Message-
From: Eric Paris [mailto:epa...@redhat.com]
Sent: 2013年4月11日 1:26
To: Wei Yongjun
Cc: v...@zeniv.linux.org.uk; Yongjun Wei (RD-CN);
linux-kernel@vger.kernel.org
Subject: Re: [PATCH -next] audit: remove duplicated include from audit.c
net/netlink.h includes
On Wed, Mar 27, 2013 at 12:49 PM, Hong Zhiguo honk...@gmail.com wrote:
Signed-off-by: Hong Zhiguo honk...@gmail.com
---
kernel/audit.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index d596e53..4dbb047 100644
---
On Fri, 2013-03-15 at 11:45 -0700, Kees Cook wrote:
On Fri, Mar 15, 2013 at 11:28 AM, Nicolas Schichan nschic...@freebox.fr
wrote:
diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index 6f19cfd..af27494 100644
--- a/include/linux/seccomp.h
+++ b/include/linux/seccomp.h
I think that is what he was suggesting. It reuses the integrity code
but it loses the integrity flexibility. I don't think it is a good
solution :-(
On Mon, Mar 4, 2013 at 1:59 PM, Mimi Zohar zo...@linux.vnet.ibm.com wrote:
On Mon, 2013-03-04 at 10:29 -0500, Vivek Goyal wrote:
[...]
Hi
Do other LSMs need this too Casey? I remember we mentioned how select
was dangerous :-(
On Fri, Nov 30, 2012 at 12:28 PM, Casey Schaufler
ca...@schaufler-ca.com wrote:
Because NETLABEL depends on INET SECURITY_SMACK
has to explicitly call out the dependency.
Signed-off-by: Casey Schaufler
On Mon, Dec 3, 2012 at 12:43 PM, Theodore Ts'o ty...@mit.edu wrote:
If you are seeing a large number of inodes still in the ext4 inode
cache after using drop_caches, then I'd look to see whether you have
something like SELinux or auditing enabled which is pinning a bunch of
dentries or inodes
On Tue, Dec 4, 2012 at 6:10 AM, Stanislav Kinsbursky
skinsbur...@parallels.com wrote:
But there should be noted, that such implementation introduces limitation
(Trond's quote):
That approach can fall afoul of the selinux restrictions on the process
context. Processes that are allowed to write
Fine Fine, I'll get off my lazy butt and look at this.
On Wed, 2013-02-27 at 10:14 -0800, Kees Cook wrote:
On Wed, Feb 27, 2013 at 10:01 AM, Josh Boyer jwbo...@redhat.com wrote:
On Wed, Feb 27, 2013 at 09:54:27AM -0800, Kees Cook wrote:
On Fri, Feb 22, 2013 at 01:18:57PM -0500, Josh Boyer
On Thu, Feb 28, 2013 at 4:35 PM, Vivek Goyal vgo...@redhat.com wrote:
On Thu, Feb 28, 2013 at 02:23:39PM -0500, Mimi Zohar wrote:
I think just a second for both of you to step back and see a slightly
larger picture/problem might help.
This is a weird case where Vivek does not trust root to make
SELinux has no maximum :-(
Realistically there are a couple of interfaces that limit things to
4k, but labels on files on disk could be even larger than that!
255 will fit most every label, but not necessarily all of them.
I know ext4 on Fedora allocates inodes which left about 255 bytes for
Reading /proc/sys/kernel/cap-bound requires CAP_SYS_MODULE. (see
proc_dointvec_bset in kernel/sysctl.c)
sysctl appears to drive all over proc reading everything it can get it's
hands on and is complaining when it is being denied access to read
cap-bound. Clearly writing to cap-bound should be a
and the s_root in the superblock struct is still 0 (since it was
initialized that way). Later when SELinux actually tries to use the
super block s_root we panic since we are trying to deference a null
pointer.
Signed-off-by: Eric Paris [EMAIL PROTECTED]
fs/hfs/super.c |1 +
1 files changed, 1
On Thu, 2006-11-16 at 17:18 -0500, Eric Paris wrote:
When an invalid hfs filesystem image is mounted it may cause a number of
different oops. One filesystem image which triggers this problem can be
found at:
Whoops, appears to be the same as the post from Eric Sandeen on tuesday
On Thu, Sep 6, 2012 at 11:16 AM, Dave Jones da...@redhat.com wrote:
On Thu, Sep 06, 2012 at 09:46:28AM -0400, Dave Jones wrote:
Hit this in overnight fuzz testing..
BUG: unable to handle kernel NULL pointer dereference at 0020
IP: [81103365]
On Thu, Sep 6, 2012 at 11:08 AM, Dave Jones da...@redhat.com wrote:
Following on from the previous patch that fixed an oops, these
are all the other similar code patterns in the tree with the same
checks added. I never saw these causing problems, but checking
this everywhere seems to make
Acked-by: Eric Paris epa...@redhat.com
On Fri, Sep 7, 2012 at 2:38 PM, Kees Cook keesc...@chromium.org wrote:
Now that kernel module origins can be reasoned about, provide a hook to
the LSMs to make policy decisions about the module file.
Signed-off-by: Kees Cook keesc...@chromium.org
Acked
cc'ing Jeff Layton who has recently done a lot of getname work and I
want to make sure he sees this.
On Wed, 19 Sep 2012 15:56:59 -0700
Arnaldo Carvalho de Melo a...@ghostprotocols.net wrote:
Al, Eric,
Was this considered before? Acceptable?
- Arnaldo
---
Instead of an
. No code from
the latter, but the only limitation he really mentioned today was that
two big guys with labels can't stack together. I don't know how/if
Dave's implementation wanted to handle that case.
I really think this patch is good.
Acked-by: Eric Paris epa...@redhat.com
I think I even want
On Fri, Aug 31, 2012 at 4:59 PM, Eric W. Biederman
ebied...@xmission.com wrote:
From a overal kernel maintenance and use perspective the unconditional
enablement is a pain.
We long ago established the principle that compiling additional code
into the kernel should not change the semenatics
a good alternative.
Signed-off-by: Kees Cook keesc...@chromium.org
Acked-by: Serge E. Hallyn serge.hal...@canonical.com
I said basically the same thing to Kees off list. But I don't have an
answer either.
Acked-by: Eric Paris epa...@redhat.com
--
To unsubscribe from this list: send the line
On Wed, Sep 5, 2012 at 5:41 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
Yeah, I think renaming the cap is a given.
CAP_RING_ZERO
Needed for any activity which would give root the ability to run code in ring 0?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Wed, Aug 8, 2012 at 3:38 PM, Eric Dumazet eric.duma...@gmail.com wrote:
On Wed, 2012-08-08 at 15:26 -0400, Paul Moore wrote:
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index ba39a52..027a331 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1524,6 +1524,10 @@
On Wed, Aug 8, 2012 at 4:35 PM, Paul Moore p...@paul-moore.com wrote:
On Wednesday, August 08, 2012 10:09:38 PM Eric Dumazet wrote:
Actually, the issue is that the shared socket doesn't have an init/alloc
function to do the LSM allocation like we do with other sockets so Eric's
patch does it
On Wed, Aug 8, 2012 at 5:03 PM, Paul Moore p...@paul-moore.com wrote:
On Wednesday, August 08, 2012 04:51:56 PM Eric Paris wrote:
Could we add a __init function which does the security_sk_alloc() in
the same file where we declared them?
Is it safe to call security_sk_alloc() from inside
On Thu, Aug 9, 2012 at 11:36 AM, Eric Dumazet eric.duma...@gmail.com wrote:
On Thu, 2012-08-09 at 11:07 -0400, Paul Moore wrote:
Is is possible to do the call to security_sk_alloc() in the ip_init()
function
or does the per-cpu nature of the socket make this a pain?
Its a pain, if we want
,
subsequent ones will reuse existing context.
Reported-by: John Stultz johns...@us.ibm.com
Bisected-by: John Stultz johns...@us.ibm.com
Signed-off-by: Eric Dumazet eduma...@google.com
Cc: Paul Moore p...@paul-moore.com
Cc: Eric Paris epa...@parisplace.org
Cc: Serge E. Hallyn se...@hallyn.com
I believe this was already found and fixed:
https://lkml.org/lkml/2012/7/25/259
Which was pulled by Linus in:
3134f37e931d75931bdf6d4eacd82a3fd26eca7c
-Eric
On Wed, 2012-08-01 at 18:11 +0200, Miklos Szeredi wrote:
Hi Peter,
Thanks for the report.
Here's a patch. I haven't tested it
I thought I HAD committed it months ago!
Man I suck at this
On Mon, Aug 6, 2012 at 3:10 PM, Paul Moore p...@paul-moore.com wrote:
On Mon, Aug 6, 2012 at 12:49 PM, Dave Jones da...@redhat.com wrote:
On Tue, Jun 05, 2012 at 01:12:39AM -0400, Dave Jones wrote:
I reported this a year ago
On Mon, 2012-06-25 at 19:46 +0200, Miklos Szeredi wrote:
From: Miklos Szeredi mszer...@suse.cz
Drop the initial reference by fsnotify_init_mark early instead of
audit_tree_freeing_mark() at destroy time.
In the cases we destroy the mark before we drop the initial reference we need
to
.
Reported-by: Valentin Avram ava...@gmail.com
Reported-by: Peter Moody pmo...@google.com
Partial-patch-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
Signed-off-by: Eric Paris epa...@redhat.com
Maybe you can use some of that changelog in your next post? (If you do
one?) The only reason you
...@vger.kernel.org
Al, can you send these along? I am not going to see a computer again
for a month. Hurray!
Acked-by: Eric Paris epa...@redhat.com
---
kernel/audit_tree.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/audit_tree.c b/kernel
It is inode oriented. Makes it a pain to work with, but that's how it
is. Sorry!
On Fri, Jun 29, 2012 at 10:06 AM, Pierre PEIFFER
pierre.peif...@stericsson.com wrote:
Hi,
By playing with inotify (on user side) to know whether the file I'm using is
deleted by someone else, I have noted that
On Tue, Dec 11, 2012 at 12:55 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
And your pseudo-filesystems argument is pretty stupid too, since WE
ALREADY HAVE A FLAG FOR THAT!
Guess where it is? Oh, it's in the place I already mentioned makes
more sense. Look for S_PRIVATE in
On Tue, Dec 11, 2012 at 1:18 PM, Mimi Zohar zo...@linux.vnet.ibm.com wrote:
The appraisal policy is based on the object metadata, such as the uid,
so the result is static and can be cached. The measurement policy, on
the other hand, is normally based on the subject (eg. who is
S_PRIVATE is totally unacceptable as it has a meaning across all LSMs,
not just IMA.
S_NOSEC means 'this is not setuid or setgid and we don't need to do
those checks on modify'
You are going to need to use a S_NOIMA.
Of Dmitry's 90,000 fewer policy lookups using the per sb flag, how
many of
On Tue, Dec 11, 2012 at 3:05 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
The IS_PRIVATE() thing is more a if you know a-priori that you
aren't interested in pseudo-filesystems, you can already check that
bit, because it will be set for things like /proc and shmem mappings
and
On Tue, 2012-11-27 at 08:43 -0800, Randy Dunlap wrote:
On 11/26/2012 10:25 PM, Stephen Rothwell wrote:
Hi all,
Changes since 20121126:
when CONFIG_PROC_FS is not enabled (also seen in mmotm):
fs/notify/fanotify/fanotify_user.c:436:17: error: 'fanotify_show_fdinfo'
undeclared
://git.infradead.org/users/eparis/notify.git for-next
for you to fetch changes up to 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06:
inotify: automatically restart syscalls (2012-12-11 13:44:37 -0500)
Eric Paris (2):
fsnotify: make fasync
On Thu, 2012-12-20 at 17:50 -0800, Linus Torvalds wrote:
On Thu, Dec 20, 2012 at 2:38 PM, Eric Paris epa...@redhat.com wrote:
I believe you would get a build failure after this pull due to the
addition of procfs information for *notify fds. The attached patch from
sfr should be applied
for?
-Eric
Cc: Andrew Morton a...@linux-foundation.org
Cc: Kees Cook keesc...@chromium.org
Cc: Cyrill Gorcunov gorcu...@openvz.org
Cc: Serge Hallyn serge.hal...@canonical.com
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Eric Paris epa...@redhat.com
Cc: James Morris jmor...@namei.org
Signed-off
On Mon, 2012-12-31 at 14:14 +0400, Andrew Vagin wrote:
On Sun, Dec 30, 2012 at 05:03:07PM -0500, Eric Paris wrote:
On Sat, 2012-12-29 at 15:00 +0400, Andrey Vagin wrote:
The address should be bigger than dac_mmap_min_addr, because
a process with CAP_RAWIO can map a vma bellow
On Mon, 2012-12-31 at 19:13 +0400, Cyrill Gorcunov wrote:
On Mon, Dec 31, 2012 at 09:27:14AM -0500, Eric Paris wrote:
On Mon, 2012-12-31 at 14:14 +0400, Andrew Vagin wrote:
On Sun, Dec 30, 2012 at 05:03:07PM -0500, Eric Paris wrote:
On Sat, 2012-12-29 at 15:00 +0400, Andrey Vagin wrote
On Wed, 2012-12-12 at 08:41 +1100, Stephen Rothwell wrote:
Hi Linus,
I am not sure how much you care about this, but here is a list of the
trees in linux-next that have been rebased in the last day (i.e. since I
fetched the trees for next-20121211):
fsnotify: rebased to v3.6(!) to resolve
have some facts...
On Tue, Dec 11, 2012 at 5:57 PM, Kasatkin, Dmitry
dmitry.kasat...@intel.com wrote:
On Tue, Dec 11, 2012 at 10:08 PM, Eric Paris epa...@parisplace.org wrote:
S_PRIVATE is totally unacceptable as it has a meaning across all LSMs,
not just IMA.
S_NOSEC means 'this is not setuid
On Wed, Dec 12, 2012 at 8:56 AM, Kasatkin, Dmitry
dmitry.kasat...@intel.com wrote:
I have done few tests.
Ratio between lookups is different, but I do not really remember what
exactly it was.
Probably I did measurement with directory integrity protection...
First test is done using upstream
On Mon, Nov 12, 2012 at 11:57 AM, Pavel Roskin pro...@gnu.org wrote:
Quoting Eric Paris epa...@parisplace.org:
OMG this +1 -1 stuff is nuts...
Ping, Al.
int iterate_fd(struct files_struct *files, unsigned n,
[snip]
while (!res n fdt-max_fds) {
file
On Fri, 2013-01-11 at 00:14 +0900, Tetsuo Handa wrote:
The reason I think is that people turn off LSMs because they are using LSMs
without understanding what the current configuration is and/or how to
change
configuration. People do not spend (or cannot afford spending) resources for
Getting an EPERM/EACCES in userspace really kinda blows. As a user you
don't have any idea why you got it. It could be SELinux, it could be
rwx bits on the file, it could be a missing capability, it could be an
ACL, it could be who knows what. We'd like to start figuring out the
who knows what
On Wed, 2013-01-09 at 11:04 -0500, Eric Paris wrote:
Getting an EPERM/EACCES in userspace really kinda blows. As a user you
don't have any idea why you got it.
Stephen Smalley wrote:
What if the denial was due to lacking sufficient permission to stat
the file (in which case you shouldn't
On Wed, 2013-01-09 at 12:14 -0800, Casey Schaufler wrote:
On 1/9/2013 11:43 AM, Eric Paris wrote:
I know many people are worried about information leaks, so I'll right up
front say lets add the sysctl to disable the interface for those who are
concerned about the metadata information leak
On Wed, 2013-01-09 at 12:53 -0800, Casey Schaufler wrote:
Let me try again, I think I didn't quite get the idea across.
I'm suggesting that the string returned by get_extended_error_info()
ought to be the audit record the system call would generate, regardless
of whether the audit system
On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
I'm suggesting that the string returned by get_extended_error_info()
ought to be the audit record the system call would generate, regardless
of whether the audit system
for us to move some of the other memory protect permissions out
of 'process' and into the new class next time we bump the policy version
number (which I also think is a good future idea)
-Eric
Signed-off-by: Eric Paris [EMAIL PROTECTED]
---
Documentation/sysctl/kernel.txt | 12
On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
This should be an unsigned long.
I wonder if the default should be for this value to be zero (i.e. preserve
existing behavior). It could break binaries, albeit potentially
insecure
Agreed - DOSemu type apps and lrmi need to map at zero for vm86
And so it shall be!
Signed-off-by: Eric Paris [EMAIL PROTECTED]
---
Documentation/sysctl/kernel.txt | 14 ++
include/linux/security.h | 17
On Thu, 2007-06-28 at 01:27 -0700, Andrew Morton wrote:
On Thu, 28 Jun 2007 00:12:21 -0700 Andrew Morton [EMAIL PROTECTED] wrote:
I can't start the X server any more, but that's probably unrelated ;)
goes back to yet another bisection search. sigh. you guys have
me hopelessly
The new protection to keep users from writing to the first couple of
pages of virtual memory also is stopping mmap operations which are only
giving a hint address greater than 0 but less than mmap_min_addr. This
patch should take the address given to mmap and move it up to
mmap_min_addr thus
1 - 100 of 532 matches
Mail list logo
