All of lore.kernel.org
 help / color / mirror / Atom feed
* Landlock and O_PATH
@ 2022-02-21 20:16 S.M Mukarram Nainar
  2022-02-21 21:47 ` Mickaël Salaün
  0 siblings, 1 reply; 9+ messages in thread
From: S.M Mukarram Nainar @ 2022-02-21 20:16 UTC (permalink / raw)
  To: landlock; +Cc: TaylorPhebillo

Hi! First I want to say that I'm happy landlock exists, its featureset
was dearly missed for a while, so thanks for that.

I was recently experimenting with Landlock to see how it works, and I
had a question.

Following the example, I locked the program down as follows:

```c
  struct landlock_ruleset_attr ruleset_attr = {
    .handled_access_fs =
    /* Files */
    LANDLOCK_ACCESS_FS_EXECUTE |
    LANDLOCK_ACCESS_FS_WRITE_FILE |
    LANDLOCK_ACCESS_FS_READ_FILE |

    /* the directory */
    LANDLOCK_ACCESS_FS_READ_DIR |

    /* inside the directory */
    LANDLOCK_ACCESS_FS_REMOVE_DIR |
    LANDLOCK_ACCESS_FS_REMOVE_FILE |
    LANDLOCK_ACCESS_FS_MAKE_CHAR |
    LANDLOCK_ACCESS_FS_MAKE_DIR |
    LANDLOCK_ACCESS_FS_MAKE_REG |
    LANDLOCK_ACCESS_FS_MAKE_SOCK |
    LANDLOCK_ACCESS_FS_MAKE_FIFO |
    LANDLOCK_ACCESS_FS_MAKE_BLOCK |
    LANDLOCK_ACCESS_FS_MAKE_SYM,
  };
  int ruleset_fd = landlock_create_ruleset(&ruleset_attr, sizeof(ruleset_attr), 0);
  if (ruleset_fd < 0) {
    perror("no");
    return 1;
  }
  if ((prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0))) {
    perror("prctl error");
    close(ruleset_fd);
    return 1;
  }
  if (landlock_restrict_self(ruleset_fd, 0) != 0) {
    perror("can't do it");
    close(ruleset_fd);
    return 1;
  }
  int fd_dir = open("/home/asdasda/", O_PATH);
  if (fd_dir < 0) {
    perror("open dir fail");
  }
```

However, open(2) with O_PATH still works. For example:

```c
  int fd_dir = open("/home/asdasda/", O_PATH);
  if (fd_dir < 0) {
    perror("open dir fail");
  }
```
This does not fail, and can basically be used as a directory oracle. Is
  this the desired behaviour? I found it surprising and expected
  FS_READ_DIR to block this as well.

Thanks,
Mukarram

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Landlock and O_PATH
  2022-02-21 20:16 Landlock and O_PATH S.M Mukarram Nainar
@ 2022-02-21 21:47 ` Mickaël Salaün
  2022-02-21 23:04   ` S.M Mukarram Nainar
  0 siblings, 1 reply; 9+ messages in thread
From: Mickaël Salaün @ 2022-02-21 21:47 UTC (permalink / raw)
  To: S.M Mukarram Nainar, landlock; +Cc: TaylorPhebillo

Hi!

On 21/02/2022 21:16, S.M Mukarram Nainar wrote:
> Hi! First I want to say that I'm happy landlock exists, its featureset
> was dearly missed for a while, so thanks for that.

Thanks!

> 
> I was recently experimenting with Landlock to see how it works, and I
> had a question.
> 
> Following the example, I locked the program down as follows:
> 
> ```c
>    struct landlock_ruleset_attr ruleset_attr = {
>      .handled_access_fs =
>      /* Files */
>      LANDLOCK_ACCESS_FS_EXECUTE |
>      LANDLOCK_ACCESS_FS_WRITE_FILE |
>      LANDLOCK_ACCESS_FS_READ_FILE |
> 
>      /* the directory */
>      LANDLOCK_ACCESS_FS_READ_DIR |
> 
>      /* inside the directory */
>      LANDLOCK_ACCESS_FS_REMOVE_DIR |
>      LANDLOCK_ACCESS_FS_REMOVE_FILE |
>      LANDLOCK_ACCESS_FS_MAKE_CHAR |
>      LANDLOCK_ACCESS_FS_MAKE_DIR |
>      LANDLOCK_ACCESS_FS_MAKE_REG |
>      LANDLOCK_ACCESS_FS_MAKE_SOCK |
>      LANDLOCK_ACCESS_FS_MAKE_FIFO |
>      LANDLOCK_ACCESS_FS_MAKE_BLOCK |
>      LANDLOCK_ACCESS_FS_MAKE_SYM,
>    };
>    int ruleset_fd = landlock_create_ruleset(&ruleset_attr, sizeof(ruleset_attr), 0);
>    if (ruleset_fd < 0) {
>      perror("no");
>      return 1;
>    }
>    if ((prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0))) {
>      perror("prctl error");
>      close(ruleset_fd);
>      return 1;
>    }
>    if (landlock_restrict_self(ruleset_fd, 0) != 0) {
>      perror("can't do it");
>      close(ruleset_fd);
>      return 1;
>    }
>    int fd_dir = open("/home/asdasda/", O_PATH);
>    if (fd_dir < 0) {
>      perror("open dir fail");
>    }
> ```
> 
> However, open(2) with O_PATH still works. For example:
> 
> ```c
>    int fd_dir = open("/home/asdasda/", O_PATH);
>    if (fd_dir < 0) {
>      perror("open dir fail");
>    }
> ```
> This does not fail, and can basically be used as a directory oracle. Is
>    this the desired behaviour? I found it surprising and expected
>    FS_READ_DIR to block this as well.

That is correct, the current Landlock implementation relies on the LSM 
path hooks, and some filesystem actions are not handled. See the warning 
section in 
https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags
Opening a file or a directory with O_PATH cannot currently be denied 
with Landlock and it is the same with AppArmor and Tomoyo. It may sound 
scary but a file descriptor opened with O_PATH can only be used to refer 
to a path (with *at syscalls), it does not give access to the underlying 
file or directory content.

You're right that it may be used as an oracle to find file or 
directories, and this can also be done with syscalls such as chdir, 
access or stat. The current goal of Landlock is to protect access to 
data, which are in files, but it would be nice to also protect metadata 
such as path existence.

I plan to fill this gap with new versions of Landlock, but I'll have to 
patch the existing LSM framework.

Regards,
  Mickaël

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Landlock and O_PATH
  2022-02-21 21:47 ` Mickaël Salaün
@ 2022-02-21 23:04   ` S.M Mukarram Nainar
  2022-02-22  9:57     ` Mickaël Salaün
  0 siblings, 1 reply; 9+ messages in thread
From: S.M Mukarram Nainar @ 2022-02-21 23:04 UTC (permalink / raw)
  To: Mickaël Salaün, landlock; +Cc: TaylorPhebillo

> That is correct, the current Landlock implementation relies on the LSM 
> path hooks, and some filesystem actions are not handled. See the warning 
> section in 
> https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags
> Opening a file or a directory with O_PATH cannot currently be denied 
> with Landlock and it is the same with AppArmor and Tomoyo. It may sound 
> scary but a file descriptor opened with O_PATH can only be used to refer 
> to a path (with *at syscalls), it does not give access to the underlying 
> file or directory content.
>
> You're right that it may be used as an oracle to find file or 
> directories, and this can also be done with syscalls such as chdir, 
> access or stat. The current goal of Landlock is to protect access to 
> data, which are in files, but it would be nice to also protect metadata 
> such as path existence.

Right, I see. That makes sense.

> I plan to fill this gap with new versions of Landlock, but I'll have to 
> patch the existing LSM framework.

Looking forward to this! I think it may be useful (considering Hyrum's
law) to document what is planned to be blocked in the future so that
application developers can use landlock safely now without worrying
about incompatibilities. It would kind of suck if applications would
break on newer kernels. That's my two cents anyway, I know you must
already be very busy.

Thanks,
Mukarram

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Landlock and O_PATH
  2022-02-21 23:04   ` S.M Mukarram Nainar
@ 2022-02-22  9:57     ` Mickaël Salaün
  2022-02-22 21:28       ` S.M Mukarram Nainar
  0 siblings, 1 reply; 9+ messages in thread
From: Mickaël Salaün @ 2022-02-22  9:57 UTC (permalink / raw)
  To: S.M Mukarram Nainar, landlock; +Cc: TaylorPhebillo


On 22/02/2022 00:04, S.M Mukarram Nainar wrote:
>> That is correct, the current Landlock implementation relies on the LSM
>> path hooks, and some filesystem actions are not handled. See the warning
>> section in
>> https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags
>> Opening a file or a directory with O_PATH cannot currently be denied
>> with Landlock and it is the same with AppArmor and Tomoyo. It may sound
>> scary but a file descriptor opened with O_PATH can only be used to refer
>> to a path (with *at syscalls), it does not give access to the underlying
>> file or directory content.
>>
>> You're right that it may be used as an oracle to find file or
>> directories, and this can also be done with syscalls such as chdir,
>> access or stat. The current goal of Landlock is to protect access to
>> data, which are in files, but it would be nice to also protect metadata
>> such as path existence.
> 
> Right, I see. That makes sense.
> 
>> I plan to fill this gap with new versions of Landlock, but I'll have to
>> patch the existing LSM framework.
> 
> Looking forward to this! I think it may be useful (considering Hyrum's
> law) to document what is planned to be blocked in the future so that
> application developers can use landlock safely now without worrying
> about incompatibilities. It would kind of suck if applications would
> break on newer kernels. That's my two cents anyway, I know you must
> already be very busy.

Landlock is designed to be backward and forward compatible just to avoid 
this kind of issue. An application being restricted with a set of access 
right will not automatically get new ones with a newer kernel: action 
handling is explicit (see ruleset's handled_access_fs). I'm extending 
the documentation with this specific subject: 
https://lore.kernel.org/r/20220221212522.320243-10-mic@digikod.net

> 
> Thanks,
> Mukarram

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Landlock and O_PATH
  2022-02-22  9:57     ` Mickaël Salaün
@ 2022-02-22 21:28       ` S.M Mukarram Nainar
  2022-02-23  7:48         ` Mickaël Salaün
  0 siblings, 1 reply; 9+ messages in thread
From: S.M Mukarram Nainar @ 2022-02-22 21:28 UTC (permalink / raw)
  To: Mickaël Salaün, landlock; +Cc: TaylorPhebillo

> Landlock is designed to be backward and forward compatible just to avoid 
> this kind of issue. An application being restricted with a set of access 
> right will not automatically get new ones with a newer kernel: action 
> handling is explicit (see ruleset's handled_access_fs). I'm extending 
> the documentation with this specific subject: 
> https://lore.kernel.org/r/20220221212522.320243-10-mic@digikod.net

Yeah, I understand that. Thanks for clarifying the documentation. But I
guess my question is then: Can it be assumed that the behavior of any
given flag will never change? I think that earlier I was assuming that
O_PATH would go under FS_READ_DIR in the future, but I guess that is not
the case?

Thanks,
Mukarram

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Landlock and O_PATH
  2022-02-22 21:28       ` S.M Mukarram Nainar
@ 2022-02-23  7:48         ` Mickaël Salaün
  2022-02-24 21:11           ` S.M Mukarram Nainar
  0 siblings, 1 reply; 9+ messages in thread
From: Mickaël Salaün @ 2022-02-23  7:48 UTC (permalink / raw)
  To: S.M Mukarram Nainar, landlock; +Cc: TaylorPhebillo


On 22/02/2022 22:28, S.M Mukarram Nainar wrote:
>> Landlock is designed to be backward and forward compatible just to avoid
>> this kind of issue. An application being restricted with a set of access
>> right will not automatically get new ones with a newer kernel: action
>> handling is explicit (see ruleset's handled_access_fs). I'm extending
>> the documentation with this specific subject:
>> https://lore.kernel.org/r/20220221212522.320243-10-mic@digikod.net
> 
> Yeah, I understand that. Thanks for clarifying the documentation. But I
> guess my question is then: Can it be assumed that the behavior of any
> given flag will never change? I think that earlier I was assuming that
> O_PATH would go under FS_READ_DIR in the future, but I guess that is not
> the case?

Correct, a given Landlock flag/command/attribute will not change 
behavior over time, as (in theory) all Linux interfaces. If a flag is 
not enough, extensible structs used by the Landlock syscalls can be 
used: 
https://lpc.events/event/7/contributions/657/attachments/639/1159/extensible_syscalls.pdf

For instance, I'm adding a LANDLOCK_ACCESS_FS_REFER to get rid of the 
rename and link limitations. The current behavior (i.e. a ruleset not 
handling this new access right) doesn't change. Taking the O_PATH 
example, I think a new access right like LANDLOCK_ACCESS_FS_WALK could 
be created to cover O_PATH, chdir and other ways to do path traversals.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Landlock and O_PATH
  2022-02-23  7:48         ` Mickaël Salaün
@ 2022-02-24 21:11           ` S.M Mukarram Nainar
  2022-02-25  9:22             ` Mickaël Salaün
  0 siblings, 1 reply; 9+ messages in thread
From: S.M Mukarram Nainar @ 2022-02-24 21:11 UTC (permalink / raw)
  To: Mickaël Salaün, landlock; +Cc: TaylorPhebillo

> Correct, a given Landlock flag/command/attribute will not change 
> behavior over time, as (in theory) all Linux interfaces. If a flag is 
> not enough, extensible structs used by the Landlock syscalls can be 
> used: 
> https://lpc.events/event/7/contributions/657/attachments/639/1159/extensible_syscalls.pdf

That makes sense. One (hopefully) final question: What is Landlock's
policy around future changes in the kernel? Taking the earlier example,
O_PATH was apparently added in Linux 2.6.39. If Landlock had existed
prior to that, and LANDLOCK_ACCESS_FS_WALK as well, would the flag have
been extended to cover that usecase? To be maybe more clear, I'm
wondering if I can trust Landlock policies to always restrict a given
action, irrespective of what new ways to do it may be introduced in
the future?

Thanks,
Mukarram

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Landlock and O_PATH
  2022-02-24 21:11           ` S.M Mukarram Nainar
@ 2022-02-25  9:22             ` Mickaël Salaün
  2022-05-13 10:31               ` Mickaël Salaün
  0 siblings, 1 reply; 9+ messages in thread
From: Mickaël Salaün @ 2022-02-25  9:22 UTC (permalink / raw)
  To: S.M Mukarram Nainar, landlock; +Cc: TaylorPhebillo


On 24/02/2022 22:11, S.M Mukarram Nainar wrote:
>> Correct, a given Landlock flag/command/attribute will not change
>> behavior over time, as (in theory) all Linux interfaces. If a flag is
>> not enough, extensible structs used by the Landlock syscalls can be
>> used:
>> https://lpc.events/event/7/contributions/657/attachments/639/1159/extensible_syscalls.pdf
> 
> That makes sense. One (hopefully) final question: What is Landlock's
> policy around future changes in the kernel? Taking the earlier example,
> O_PATH was apparently added in Linux 2.6.39. If Landlock had existed
> prior to that, and LANDLOCK_ACCESS_FS_WALK as well, would the flag have
> been extended to cover that usecase? To be maybe more clear, I'm
> wondering if I can trust Landlock policies to always restrict a given
> action, irrespective of what new ways to do it may be introduced in
> the future?

Landlock uses the LSM framework, which defines a set of hooks according 
to access semantic. O_PATH and chdir is not currently supported for 
path-based LSMs but it is handled for inode-based LSMs such as SELinux 
and Smack. The underlying idea of these LSM hooks is that they should be 
used for every new Linux interfaces doing similar things, so that LSMs 
don't have to be updated specifically for new UAPI change. So yes, you 
can trust Landlock policies to always restrict a given action. If, for 
whatever reason, it happens that a new Linux interface is added without 
the appropriate LSM hook or if Landlock doesn't support it somehow, then 
we can define a new Landlock access right defining this new action. 
There is a bunch of tests covering the several actions (handled or not) 
and they must pass for every kernel releases: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/landlock

Regards,
  Mickaël

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Landlock and O_PATH
  2022-02-25  9:22             ` Mickaël Salaün
@ 2022-05-13 10:31               ` Mickaël Salaün
  0 siblings, 0 replies; 9+ messages in thread
From: Mickaël Salaün @ 2022-05-13 10:31 UTC (permalink / raw)
  To: S.M Mukarram Nainar, landlock; +Cc: TaylorPhebillo


On 25/02/2022 10:22, Mickaël Salaün wrote:
> 
> On 24/02/2022 22:11, S.M Mukarram Nainar wrote:
>>> Correct, a given Landlock flag/command/attribute will not change
>>> behavior over time, as (in theory) all Linux interfaces. If a flag is
>>> not enough, extensible structs used by the Landlock syscalls can be
>>> used:
>>> https://lpc.events/event/7/contributions/657/attachments/639/1159/extensible_syscalls.pdf 
>>>
>>
>> That makes sense. One (hopefully) final question: What is Landlock's
>> policy around future changes in the kernel? Taking the earlier example,
>> O_PATH was apparently added in Linux 2.6.39. If Landlock had existed
>> prior to that, and LANDLOCK_ACCESS_FS_WALK as well, would the flag have
>> been extended to cover that usecase? To be maybe more clear, I'm
>> wondering if I can trust Landlock policies to always restrict a given
>> action, irrespective of what new ways to do it may be introduced in
>> the future?
> 
> Landlock uses the LSM framework, which defines a set of hooks according 
> to access semantic. O_PATH and chdir is not currently supported for 
> path-based LSMs but it is handled for inode-based LSMs such as SELinux 
> and Smack. The underlying idea of these LSM hooks is that they should be 
> used for every new Linux interfaces doing similar things, so that LSMs 
> don't have to be updated specifically for new UAPI change. So yes, you 
> can trust Landlock policies to always restrict a given action. If, for 
> whatever reason, it happens that a new Linux interface is added without 
> the appropriate LSM hook or if Landlock doesn't support it somehow, then 
> we can define a new Landlock access right defining this new action. 
> There is a bunch of tests covering the several actions (handled or not) 
> and they must pass for every kernel releases: 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/landlock 

FYI, I added new tests to make sure the O_PATH handling will never 
change: https://lore.kernel.org/r/20220506160820.524344-8-mic@digikod.net


> Regards,
>   Mickaël

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2022-05-13 10:31 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-21 20:16 Landlock and O_PATH S.M Mukarram Nainar
2022-02-21 21:47 ` Mickaël Salaün
2022-02-21 23:04   ` S.M Mukarram Nainar
2022-02-22  9:57     ` Mickaël Salaün
2022-02-22 21:28       ` S.M Mukarram Nainar
2022-02-23  7:48         ` Mickaël Salaün
2022-02-24 21:11           ` S.M Mukarram Nainar
2022-02-25  9:22             ` Mickaël Salaün
2022-05-13 10:31               ` Mickaël Salaün

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.