--
> @@ -575,3 +609,6 @@ References and Sources
> - Recommendation from Linus Torvalds that x32 system calls should prefer
> compatibility with 64-bit versions rather than 32-bit versions:
> https://lkml.org/lkml/2011/8/31/244
> + - Linux Configuration section of the Open Co
user of openat2(2)
at the moment is LXC which doesn't specify both flags and so no
userspace programs will break as a result.
Cc: # v5.6+
Fixes: fddb5d430ad9 ("open: introduce openat2(2) syscall")
Acked-by: Christian Brauner
Signed-off-by: Aleksa Sarai
---
umode_t mode, int flags);
> asmlinkage long sys_fchownat(int dfd, const char __user *filename, uid_t
> user,
>gid_t group, int flag);
> asmlinkage long sys_fchown(unsigned int fd, uid_t user, gid_t group);
> diff --git a/include/uapi/asm-generic/unistd.h
> b/include/uapi/asm-generic/unistd.h
> index 995b36c2ea7d..ebf5cdb3f444 100644
> --- a/include/uapi/asm-generic/unistd.h
> +++ b/include/uapi/asm-generic/unistd.h
> @@ -859,9 +859,11 @@ __SYSCALL(__NR_openat2, sys_openat2)
> __SYSCALL(__NR_pidfd_getfd, sys_pidfd_getfd)
> #define __NR_faccessat2 439
> __SYSCALL(__NR_faccessat2, sys_faccessat2)
> +#define __NR_fchmodat2 440
> +__SYSCALL(__NR_fchmodat2, sys_fchmodat2)
>
> #undef __NR_syscalls
> -#define __NR_syscalls 440
> +#define __NR_syscalls 441
>
> /*
> * 32 bit systems traditionally used different
> --
> 2.21.0
>
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
t_flags makes more sense.
The restriction should apply in the context of whatever filesystem
contains the symlink, and that would matches FreeBSD's semantics (at
least as far as I can tell from a quick look at sys/kern/vfs_lookup.c).
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<
LR or other base-related randomisation. However it depends
on having CONFIG_GCC_PLUGIN_RANDSTRUCT=y and I believe (at least for
distribution kernels) this isn't a widely-used configuration.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
table way to talk about a
peer within the kernel community -- attributing malicious intent without
any justification other than "I feel this is the case" is little more
than a character assassination, and I don't see why you would feel that
such a statement is justified.
--
Aleksa Sarai
history and motivation for this patch can be
> found here:
>
> https://sites.google.com/a/chromium.org/dev/chromium-os/chromiumos-design-docs/hardening-against-malicious-stateful-data#TOC-Restricting-symlink-traversal
Looks good. Did you plan to add an in-tree test for this (you could
s
On 2020-08-04, Eric Biggers wrote:
> On Wed, Aug 05, 2020 at 01:47:58PM +1000, Aleksa Sarai wrote:
> > On 2020-08-04, Lokesh Gidra wrote:
> > > when get_unused_fd_flags returns error, ctx will be freed by
> > > userfaultfd's release function, which is indirectly c
> fput(file);
> - goto out;
> + return fd;
> }
>
> ctx->owner = file_inode(file);
> fd_install(fd, file);
> -
> -out:
> - if (fd < 0) {
> - mmdrop(ctx->mm);
> - kmem_cache_free(userfaultf
ll container workloads.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
ted, and we should get seccomp hooked
> up right away, and that might help us see how (if) ptrace should be
> attached.
We could just emulate the seccomp-bpf API with the pseudo-syscalls done
as a result of CQEs, though I'm not sure how happy folks will be with
this kind of glue code in "seccomp-uring" (though in theory it would
allow us to attach existing filters to io_uring...).
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
e patches were ever developed further. From reading the
> > discussion thread on that patch set it appears that I should be doing
> > some form of polling on the /proc files.
>
> Recently Christian Brauner implemented pidfd complete with a poll
> operation that reports when a process terminates.
>
> If you are willing to change your userspace code switching to pidfd
> should be all that you need.
While this does solve the problem of getting exit notifications in
general, you cannot get the exit code. But if they don't care about that
then we can solve that problem another time. :D
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
owever I'm pretty sure
(looking at the code now) that it wasn't true then and isn't true now
(Shepherd seems to just do basic pidfile liveliness checks). So even the
niche example I used then doesn't actually use cn_proc.
[1]: https://lore.kernel.org/lkml/a2fa1602-2280-c5e8-cac9-b718eaea5...@suse.de/
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
nat2.2.
Signed-off-by: Aleksa Sarai
---
man7/symlink.7 | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/man7/symlink.7 b/man7/symlink.7
index 07b1db3a3764..ed99bc4236f1 100644
--- a/man7/symlink.7
+++ b/man7/symlink.7
@@ -84,6
On 2020-05-19, Alexei Starovoitov wrote:
> On Wed, May 20, 2020 at 11:20:45AM +1000, Aleksa Sarai wrote:
> > No it won't become copy_from_user(), nor will there be a TOCTOU race.
> >
> > The idea is that seccomp will proactively copy the struct (and
> > recursively
On 2020-05-19, Alexei Starovoitov wrote:
> On Mon, May 18, 2020 at 7:53 PM Aleksa Sarai wrote:
> >
> > On 2020-05-19, Jann Horn wrote:
> > > On Mon, May 18, 2020 at 11:05 PM Kees Cook wrote:
> > > > ## deep argument inspection
> > > >
>
On 2020-05-19, Aleksa Sarai wrote:
> On 2020-05-19, Christian Brauner wrote:
> > On Tue, May 19, 2020 at 05:09:29PM +1000, Aleksa Sarai wrote:
> > > On 2020-05-18, Kees Cook wrote:
> > > > - the sizes of these EA structs are, by design, growable over time.
> &
On 2020-05-19, Christian Brauner wrote:
> On Tue, May 19, 2020 at 05:09:29PM +1000, Aleksa Sarai wrote:
> > On 2020-05-18, Kees Cook wrote:
> > > - the sizes of these EA structs are, by design, growable over time.
> > > seccomp and its users need to be handle thi
; BPF verifier do an analysis to determine if there are any static
> results, and set bits in the various bitmasks to represent it.
> i.e. when seccomp is first enabled on a thread, the "accept"
> bitmask is populated with all syscalls, and for each filter, do
> [math,
could just replace the loads with
> reads from the pt_regs, too.)
>
> > (However, this needs to be carefully considered given that seccomp_data
> > is embedded in user_notif... should the EA struct from userspace also be
> > copied into user_notif? More thoughts on this below...)
> >
> > For user_notif, I think we need something in and around these options:
> >
> > - make a new API that explicitly follows EA struct design
> > (and while read()/write() might be easier[4], I tend to agree with
> > Jann and we need to stick to ioctl(): as Tycho noted, "read/write is
> > for data". Though I wonder if read() could be used for the notifications,
> > which ARE data, and use ioctl() for the responses?)
>
> Just as a note: If we use read() there, we'll never be able to
> transfer things like FDs through that API.
And we run into the age-old "read() for management can be a bit hairy"
problem.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
nds on the distribution) but it means that any
program which uses O_MAYEXEC cannot rely on it to provide the security
guarantees they expect. Even if the program goes and reads the sysctl
value, it could change underneath them. If this is just meant to be a
best-effort protection then this doesn't ma
copy_struct_from_user(). I was a
little surprised when I found out that user_notif doesn't do it this
way a while ago (and although in theory it is userspace's fault, ideally
we could have an API that doesn't have built-in footguns).
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
t return EINVAL when
> VALID_OPEN_FLAGS check failed.
> Now it does, so I do not see a problem that interpreter will use
> simple open(), ( Although that path might be manipulated, but file
> contents will be verified by IMA)
You don't get -EINVAL from open() in the case of unknown flags, that's
something only openat2() does in the open*() family. Hence why it's only
introduced for openat2().
> 2. When you apply a new flag to mount, it means that IMA will check
> all files under this mount and it does not matter whether the file in
> question is a script or not.
> IMHO it is too hard overhead for performance reasons.
>
> Regards,
> LEv
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
vil's advocate -- pid1 has also always had a default-ignore
signal mask (which included SIGPWR), so any pid1 that obeyed SIGPWR
already had a non-default signal mask (and thus wouldn't be affected by
this patch).
But I do agree that this seems like a strange change to make (SIGPWR
seem
FD patchset does[1] and I
think it's a reasonable way of solving such problems.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
n the
> E2BIG we are testing for? Does the kernel export it somewhere?
No, you would have to effectively binary search on -E2BIG at the moment.
CHECK_FIELDS is a proposal I have which would allow you to get get the
size of the in-kernel struct, but it's still a proposal.
In theory you
Because pids->limit can be changed concurrently (but we don't want to
take a lock because it would be needlessly expensive), use atomic64_ts
instead.
Fixes: commit 49b786ea146f ("cgroup: implement the PIDs subsystem")
Cc: sta...@vger.kernel.org # v4.3+
Signed-off-by: Aleksa
On 2019-10-17, Aleksa Sarai wrote:
> On 2019-10-16, Tejun Heo wrote:
> > Hello, Aleksa.
> >
> > On Wed, Oct 16, 2019 at 07:32:19PM +1100, Aleksa Sarai wrote:
> > > Maybe I'm misunderstanding Documentation/atomic_t.txt, but it looks to
> > > me like it's
On 2019-10-16, Tejun Heo wrote:
> Hello, Aleksa.
>
> On Wed, Oct 16, 2019 at 07:32:19PM +1100, Aleksa Sarai wrote:
> > Maybe I'm misunderstanding Documentation/atomic_t.txt, but it looks to
> > me like it's explicitly saying that I shouldn't use atomic64_t if I'm
> >
a 4K PAGE_SIZE the test takes multiple seconds. Instead
> tweak it to only scan a 1024 byte region, but make it cross the
> page boundary.
>
> Fixes: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
> Suggested-by: Aleksa Sarai
> Signed-off-by: Michael
On 2019-10-14, Tejun Heo wrote:
> Hello, Aleksa.
>
> On Tue, Oct 15, 2019 at 02:59:31AM +1100, Aleksa Sarai wrote:
> > On 2019-10-14, Tejun Heo wrote:
> > > On Sat, Oct 12, 2019 at 12:05:39PM +1100, Aleksa Sarai wrote:
> > > > Because pids->limit can be
On 2019-10-14, Tejun Heo wrote:
> On Sat, Oct 12, 2019 at 12:05:39PM +1100, Aleksa Sarai wrote:
> > Because pids->limit can be changed concurrently (but we don't want to
> > take a lock because it would be needlessly expensive), use the
> > appropriate memory barriers.
On 2019-10-12, Michael Ellerman wrote:
> Aleksa Sarai writes:
> > On 2019-10-11, Michael Ellerman wrote:
> >> On a machine with a 64K PAGE_SIZE, the nested for loops in
> >> test_check_nonzero_user() can lead to soft lockups, eg:
> ...
> >>
Because pids->limit can be changed concurrently (but we don't want to
take a lock because it would be needlessly expensive), use the
appropriate memory barriers.
Fixes: commit 49b786ea146f ("cgroup: implement the PIDs subsystem")
Cc: sta...@vger.kernel.org # v4.3+
Signed-off-by:
On 2019-10-11, Michael Kerrisk wrote:
> Why CLONE3_CLEAR_SIGHAND rather than just CLONE_CLEAR_SIGHAND?
There are no more flag bits left for the classic clone()/clone2() (the
last one was used up by CLONE_PIDFD) -- thus this flag is clone3()-only.
--
Aleksa Sarai
Senior Software Engin
a 4K PAGE_SIZE the test takes multiple seconds. Instead
> tweak it to only scan a 1024 byte region, but make it cross the
> page boundary.
>
> Fixes: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
> Suggested-by: Aleksa Sarai
> Signed-off-by: Michael Ellerman
On 2019-10-10, Michael Ellerman wrote:
> Aleksa Sarai writes:
> > A common pattern for syscall extensions is increasing the size of a
> > struct passed from userspace, such that the zero-value of the new fields
> > result in the old kernel behaviour (allowing f
oing.
> Note that copy_struct_from_user() is calling min() already. So
> technically, the min_t() call could go. But the size is used further
> below so leave it.
>
> [1]: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
> Signed-off-by: Christian Brauner
r() is doing.
> Note that copy_struct_from_user() is calling min() already. So
> technically, the min_t() call could go. But the info_len is used further
> below so leave it.
>
> [1]: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
> Signed-off-by: Ch
lled version.
>
> [1]: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
> Signed-off-by: Christian Brauner
Acked-by: Aleksa Sarai
> ---
> kernel/bpf/syscall.c | 22 +++---
> 1 file changed, 7 insertions(+), 15 deletions(-)
>
>
On 2019-10-09, Michael Kerrisk (man-pages) wrote:
> Hello Aleksa,
>
> Thanks for this. It's a great piece of documentation work!
>
> I would prefer the path_resolution(7) piece as a separate patch.
Thanks, and will do.
> On 10/3/19 4:55 PM, Aleksa Sarai wrote:
> > Rat
the magic-link changes (plus
O_EMPTYPATH) will probably land after openat2(2) since there is some
remaining work to do.
> On 10/3/19 4:55 PM, Aleksa Sarai wrote:
> > Some of the wording around empty paths in path_resolution(7) also needed
> > to be reworked since it's now legal (if y
On 2019-10-09, Michael Kerrisk (man-pages) wrote:
> On 10/3/19 4:55 PM, Aleksa Sarai wrote:
> > Traditionally, magic-links have not been a well-understood topic in
> > Linux. Given the new changes in their semantics (related to the link
> > mode of trailing magic-links),
wrong position, fix it.
>
> Signed-off-by: Miaohe Lin
> Reviewed-by: Andrew Morton
> Cc: Alexey Dobriyan
> Signed-off-by: Andrew Morton
Looks reasonable.
Acked-by: Aleksa Sarai
> ---
>
> include/linux/proc_fs.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 dele
On 2019-10-07, Jann Horn wrote:
> On Thu, Oct 3, 2019 at 4:56 PM Aleksa Sarai wrote:
> > Traditionally, magic-links have not been a well-understood topic in
> > Linux. Given the new changes in their semantics (related to the link
> > mode of trailing magic-links),
On 2019-10-06, Christian Brauner wrote:
> On Sun, Oct 06, 2019 at 10:30:28AM +1100, Aleksa Sarai wrote:
> > While writing the tests for copy_struct_from_user(), I used a construct
> > that Linus doesn't appear to be too fond of:
> >
> > On 2019-10-04, Linus Torvalds
opy_struct_from_user")
Fixes: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
Signed-off-by: Aleksa Sarai
---
lib/test_user_copy.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/lib/test_user_copy.c b/lib/test_user_copy.c
index
layer of parentheses.
You're quite right -- I was mindlessly copying the "ret |=" logic the
rest of test_user_copy.c does without thinking about it. I'll include a
cleanup for it in the openat2(2) series.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
gt; Link: https://github.com/ClangBuiltLinux/linux/issues/731
> > Signed-off-by: Nathan Chancellor
> >
>
> I'll take this. Aleksa, can I get your ack too, please?
>
> Acked-by: Christian Brauner
Acked-by: Aleksa Sarai
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
rmation on how to ensure that syscalls with structure
> > arguments are extensible and add a section about naming conventions to
> > follow when adding revised versions of already existing syscalls.
> >
> > Co-Developed-by: Aleksa Sarai
> > Signed-off-
Ignore this one (it's an older version of the openat2.2 patch) -- I sent
it by accident.
On 2019-10-04, Aleksa Sarai wrote:
> Signed-off-by: Aleksa Sarai
> ---
> man2/open.2| 5 +
> man2/openat2.2 | 381 +
> man7/pa
...@cyphar.com/
Aleksa Sarai (3):
symlink.7: document magic-links more completely
open.2: add O_EMPTYPATH documentation
openat2.2: document new openat2(2) syscall
man2/open.2| 47 -
man2/openat2.2 | 381 +
man7/path_resolution.7
Signed-off-by: Aleksa Sarai
---
man2/open.2| 5 +
man2/openat2.2 | 381 +
man7/path_resolution.7 | 57 --
3 files changed, 426 insertions(+), 17 deletions(-)
create mode 100644 man2/openat2.2
diff --git a/man2/open.2 b/man2
or common errors.
Signed-off-by: Aleksa Sarai
---
man2/open.2| 5 +
man2/openat2.2 | 381 +
man7/path_resolution.7 | 57 --
3 files changed, 426 insertions(+), 17 deletions(-)
create mode 100644 man2/openat2.2
diff --git a/man2
Traditionally, magic-links have not been a well-understood topic in
Linux. Given the new changes in their semantics (related to the link
mode of trailing magic-links), it seems like a good opportunity to shine
more light on magic-links and their semantics.
Signed-off-by: Aleksa Sarai
---
man7
Some of the wording around empty paths in path_resolution(7) also needed
to be reworked since it's now legal (if you pass O_EMPTYPATH).
Signed-off-by: Aleksa Sarai
---
man2/open.2| 42 +-
man7/path_resolution.7 | 17 -
2 files
could come up with a more sane idea for how
the syscall interface should look.
[1]: commit 1251201c0d34 ("sched/core: Fix uclamp ABI bug, clean up and
robustify sched_read_attr() ABI logic and code")
Reviewed-by: Kees Cook
Signed-off-by: Aleksa Sarai
---
kernel/sched/c
The change is very straightforward, and helps unify the syscall
interface for struct-from-userspace syscalls.
Reviewed-by: Kees Cook
Signed-off-by: Aleksa Sarai
---
kernel/events/core.c | 47 +---
1 file changed, 9 insertions(+), 38 deletions(-)
diff
The change is very straightforward, and helps unify the syscall
interface for struct-from-userspace syscalls. Additionally, explicitly
define CLONE_ARGS_SIZE_VER0 to match the other users of the
struct-extension pattern.
Reviewed-by: Kees Cook
Signed-off-by: Aleksa Sarai
---
include/uapi/linux
Villemoes
Signed-off-by: Aleksa Sarai
---
include/linux/bitops.h | 7 +++
include/linux/uaccess.h | 70 +
lib/strnlen_user.c | 8 +--
lib/test_user_copy.c| 136 ++--
lib/usercopy.c | 55
5 files ch
s to copy_struct_from_user() while rt_sigprocmask(2)
always rejects differently-sized struct arguments.
Aleksa Sarai (4):
lib: introduce copy_struct_from_user() helper
clone3: switch to copy_struct_from_user()
sched_setattr: switch to copy_struct_from_user()
perf_event_open: switch to copy_
On 2019-09-30, Kees Cook wrote:
> On Tue, Oct 01, 2019 at 05:15:24AM +1000, Aleksa Sarai wrote:
> > From: Aleksa Sarai
> >
> > The change is very straightforward, and helps unify the syscall
> > interface for struct-from-userspace syscalls. Addition
On 2019-09-30, Kees Cook wrote:
> On Tue, Oct 01, 2019 at 05:15:23AM +1000, Aleksa Sarai wrote:
> > From: Aleksa Sarai
> >
> > A common pattern for syscall extensions is increasing the size of a
> > struct passed from userspace, such that the zero-value of the new f
ote to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see
> https://stackoverflow.com/a/37406982]
>
> url:
> https://github.com/0day-ci/linux/commits/Aleksa-Sarai/namei-openat2-2-path-resolution-restr
From: Aleksa Sarai
Patch changelog:
v3: [<https://lore.kernel.org/lkml/20190930182810.6090-1-cyp...@cyphar.com/>]
* Rename is_zeroed_user() to check_zeroed_user(). [Christian Brauner]
* Various minor cleanups. [Christian Brauner]
* Add copy_struct_from_user() tests.
v2:
From: Aleksa Sarai
The change is very straightforward, and helps unify the syscall
interface for struct-from-userspace syscalls.
Signed-off-by: Aleksa Sarai
---
kernel/events/core.c | 47 +---
1 file changed, 9 insertions(+), 38 deletions(-)
diff --git
From: Aleksa Sarai
A common pattern for syscall extensions is increasing the size of a
struct passed from userspace, such that the zero-value of the new fields
result in the old kernel behaviour (allowing for a mix of userspace and
kernel vintages to operate on one another in most cases).
While
From: Aleksa Sarai
The change is very straightforward, and helps unify the syscall
interface for struct-from-userspace syscalls. Additionally, explicitly
define CLONE_ARGS_SIZE_VER0 to match the other users of the
struct-extension pattern.
Signed-off-by: Aleksa Sarai
---
include/uapi/linux
From: Aleksa Sarai
The change is very straightforward, and helps unify the syscall
interface for struct-from-userspace syscalls. Ideally we could also
unify sched_getattr(2)-style syscalls as well, but unfortunately the
correct semantics for such syscalls are much less clear (see [1] for
more
Villemoes
Signed-off-by: Aleksa Sarai
---
include/linux/bitops.h | 7 +++
include/linux/uaccess.h | 4 ++
lib/strnlen_user.c | 8 +--
lib/test_user_copy.c| 133 ++--
lib/usercopy.c | 123 +
5 files ch
he
expense of further complicating O_PATH makes little sense. Ultimately,
if users ask for this we can always add RESOLVE_EMPTY_PATH to
resolveat(2) in the future.
Signed-off-by: Aleksa Sarai
---
arch/alpha/include/uapi/asm/fcntl.h | 1 +
arch/parisc/include/uapi/asm/fc
[1]: https://github.com/openSUSE/libpathrs
Suggested-by: Christian Brauner
Signed-off-by: Aleksa Sarai
---
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h
ase path
seems to be the most consistent behaviour (and also avoids foot-gunning
users who want to scope paths that are absolute).
[1]: https://github.com/cyphar/filepath-securejoin
Signed-off-by: Aleksa Sarai
---
fs/namei.c| 5 +
include/linux/namei.h | 3 ++-
2 files changed, 7
for
writing (because it is the current->mm of a live process).
With the new O_PATH restrictions, changing the default mode of these
magic-links allows us to avoid delayed-access attacks such as we saw in
CVE-2019-5736.
Signed-off-by: Aleksa Sarai
---
fs/proc/base.c |
truction.
[*] It may be acceptable in the future to do a path_is_under() check (as
with the alternative solution for "..") for magic-links after they
are resolved. However this seems unlikely to be a feature that
people *really* need -- it can be added later if it turns out a lot
of
We've introduced new (somewhat subtle) behaviour regarding trailing
magic-links, so it's best to make sure everyone can follow along with
the reasoning behind trailing_magiclink().
Signed-off-by: Aleksa Sarai
---
Documentation/filesystems/path-lookup.rst | 80 ++-
1 file
s g+rwx for ordinary
files, but for trailing magic-links the mode gets inherited).
Signed-off-by: Aleksa Sarai
---
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/memfd/memfd_test.c| 7 +-
tools/testing/selftests/openat2/.gitignore| 1 +
tools/testi
work/patch/784221/
[3]: https://lwn.net/Articles/619151/
[4]: https://lwn.net/Articles/603929/
[5]: https://lwn.net/Articles/723057/
[6]: https://github.com/cyphar/filepath-securejoin
[7]: https://github.com/openSUSE/libpathrs
Aleksa Sarai (9):
namei: obey trailing magic-link DAC permissions
The change is very straightforward, and helps unify the syscall
interface for struct-from-userspace syscalls. Additionally, explicitly
define CLONE_ARGS_SIZE_VER0 to match the other users of the
struct-extension pattern.
Signed-off-by: Aleksa Sarai
---
include/uapi/linux/sched.h | 2 ++
kernel
could come up with a more sane idea for how
the syscall interface should look.
[1]: commit 1251201c0d34 ("sched/core: Fix uclamp ABI bug, clean up and
robustify sched_read_attr() ABI logic and code")
Signed-off-by: Aleksa Sarai
---
kernel/sched/c
while rt_sigprocmask(2)
always rejects differently-sized struct arguments.
Aleksa Sarai (4):
lib: introduce copy_struct_from_user() helper
clone3: switch to copy_struct_from_user()
sched_setattr: switch to copy_struct_from_user()
perf_event_open: switch to copy_struct_from_user()
The change is very straightforward, and helps unify the syscall
interface for struct-from-userspace syscalls.
Signed-off-by: Aleksa Sarai
---
kernel/events/core.c | 47 +---
1 file changed, 9 insertions(+), 38 deletions(-)
diff --git a/kernel/events
On 2019-09-26, Christian Brauner wrote:
> On Thu, Sep 26, 2019 at 01:03:29AM +0200, Aleksa Sarai wrote:
> > +int is_zeroed_user(const void __user *from, size_t size)
> > +{
> > + unsigned long val;
> > + uintptr_t align = (uintptr_t) from % sizeof(unsigned long);
(Damn, I forgot to add Kees to Cc.)
On 2019-09-26, Aleksa Sarai wrote:
> A common pattern for syscall extensions is increasing the size of a
> struct passed from userspace, such that the zero-value of the new fields
> result in the old kernel behaviour (allowing for a mix of
The change is very straightforward, and helps unify the syscall
interface for struct-from-userspace syscalls.
Signed-off-by: Aleksa Sarai
---
kernel/events/core.c | 47 +---
1 file changed, 9 insertions(+), 38 deletions(-)
diff --git a/kernel/events
3]: For instance {sched_setattr,perf_event_open,clone3}(2) all do do
similar checks to copy_struct_from_user() while rt_sigprocmask(2)
always rejects differently-sized struct arguments.
Aleksa Sarai (4):
lib: introduce copy_struct_from_user() helper
clone3: switch to copy_
The change is very straightforward, and helps unify the syscall
interface for struct-from-userspace syscalls. Additionally, explicitly
define CLONE_ARGS_SIZE_VER0 to match the other users of the
struct-extension pattern.
Signed-off-by: Aleksa Sarai
---
include/uapi/linux/sched.h | 2 ++
kernel
Villemoes
Signed-off-by: Aleksa Sarai
---
include/linux/bitops.h | 7 +++
include/linux/uaccess.h | 4 ++
lib/strnlen_user.c | 8 +--
lib/test_user_copy.c| 59 ++---
lib/usercopy.c | 115
5 files changed, 180
could come up with a more sane idea for how
the syscall interface should look.
[1]: commit 1251201c0d34 ("sched/core: Fix uclamp ABI bug, clean up and
robustify sched_read_attr() ABI logic and code")
Signed-off-by: Aleksa Sarai
---
kernel/sched/c
On 2019-09-25, Linus Torvalds wrote:
> On Wed, Sep 25, 2019 at 10:00 AM Aleksa Sarai wrote:
> >
> > +int is_zeroed_user(const void __user *from, size_t size)
>
> I like how you've done this, but it's buggy and only works on 64-bit.
>
> All the "u64" an
all do do
similar checks to copy_struct_from_user() while rt_sigprocmask(2)
always rejects differently-sized struct arguments.
Suggested-by: Rasmus Villemoes
Signed-off-by: Aleksa Sarai
---
include/linux/uaccess.h | 4 +++
lib/Makefile| 2 +-
lib/strnlen_user.c
could come up with a more sane idea for how
the syscall interface should look.
[1]: commit 1251201c0d34 ("sched/core: Fix uclamp ABI bug, clean up and
robustify sched_read_attr() ABI logic and code")
Signed-off-by: Aleksa Sarai
---
kernel/sched/c
The change is very straightforward, and helps unify the syscall
interface for struct-from-userspace syscalls. Additionally, explicitly
define CLONE_ARGS_SIZE_VER0 to match the other users of the
struct-extension pattern.
Signed-off-by: Aleksa Sarai
---
include/uapi/linux/sched.h | 2 ++
kernel
_from_user() while rt_sigprocmask(2)
always rejects differently-sized struct arguments.
Aleksa Sarai (4):
lib: introduce copy_struct_from_user() helper
clone3: switch to copy_struct_from_user()
sched_setattr: switch to copy_struct_from_user()
perf_event_open: switch to copy_struct
The change is very straightforward, and helps unify the syscall
interface for struct-from-userspace syscalls.
Signed-off-by: Aleksa Sarai
---
kernel/events/core.c | 47 +---
1 file changed, 9 insertions(+), 38 deletions(-)
diff --git a/kernel/events
On 2019-09-17, Jann Horn wrote:
> On Wed, Sep 4, 2019 at 10:21 PM Aleksa Sarai wrote:
> > The ability for userspace to "re-open" file descriptors through
> > /proc/self/fd has been a very useful tool for all sorts of usecases
> > (container runtimes are one common
ue with the sysctl by clearing O_MAYEXEC from
f_flags if the sysctl is disabled. You could also avoid some of the
problems with it being a global setting by making it a prctl(2) which
processes can opt-in to (though this has its own major problems).
Sorry, but I'm just really not a f
However with -EINVAL, the programs doing "the right thing" get an easy
-EINVAL check. And programs that don't care can just un-set O_MAYEXEC
and retry. You should be forced to deal with the case where a flag is
not supported -- and this is doubly true of security flags!
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
etical FMODE_EXEC should be.
And of course we'd need to do FMODE_UPGRADE_EXEC (which would need to
also permit fexecve(2) though probably not PROT_EXEC -- I don't think
you can mmap() an O_PATH descriptor).
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
signature.asc
Description: PGP signature
On 2019-09-07, Aleksa Sarai wrote:
> On 2019-09-06, Jeff Layton wrote:
> > On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > > On 2019-09-06, Jeff Layton wrote:
> > > > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > > &
1 - 100 of 828 matches
Mail list logo
