linux-kernel - Re: [RFC] Privilege dropping security module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <h9jaar$url$1@taverner.cs.berkeley.edu>
Date:	Fri, 25 Sep 2009 20:48:27 +0000 (UTC)
From:	daw@...berkeley.edu (David Wagner)
To:	linux-kernel@...r.kernel.org
Subject: Re: [RFC] Privilege dropping security module

Andy Spencer  wrote:
>> If I understand correctly, this isn't sufficient to run untrusted code,
>> because it only restricts access to the filesystem.  You gotta restrict
>> access to the network, interaction with other processes, and so on.
>> (For instance, does dpriv let the untrusted process take over another of
>> your processes using ptrace?)
>
>Yes, currently dpriv allows a process to take over another process using
>ptrace. However, I plan on supporting limits on ptrace (and other
>things) in the future.

Ptrace is just one example: there is a non-trivial list of non-filesystem
resources that must be controlled, to run untrusted code safely.

>> I suspect making all permissions recursive is going to lead to overly
>> permissive policies.  Suppose I want to allow read access to everything
>> under /lib and /usr/lib, read-execute access to everything under /bin
>> and /usr/bin, and read-write access to everything under /tmp.  (But I
>> do not want to allow any access to any other directories.)  How do I
>> do it?
>
>The important thing is that limits can be overridden while they are
>still in the stage. This allows you to deny access to a directory, but
>still allow access to specific subdirectories.
>
>  $ echo -----X /        > /sys/kernel/security/dpriv/stage
>  $ echo r--R-X /lib     > /sys/kernel/security/dpriv/stage
>  $ echo r--R-X /usr/lib > /sys/kernel/security/dpriv/stage
>  $ echo r-xR-X /bin     > /sys/kernel/security/dpriv/stage
>  $ echo r-xR-X /usr/bin > /sys/kernel/security/dpriv/stage
>  $ echo rw-RWX /tmp     > /sys/kernel/security/dpriv/stage
>  $ echo commit          > /sys/kernel/security/dpriv/control
>
>Does this answer your question?

Unfortunately it does not, because as you note:

>It should be noted that you can still
>walk to any directory because X is allowed on /.

Which contradicts the goal of not allowing access to any other
directories.  In other words, the implementation above of my desired
policy is overly permissive.  This illustrates my more general point:
the dpriv policy specification language seems likely to lead to overly
permissive policies -- policies that are more permissive than what was
really desired.

>To prevent this you
>would have to allow X on / and then specifically deny X on /*/, but
>expanding * is something that I would rather have done in userspace.

In principle a user of dpriv could do that, to be sure, but in practice
this becomes unwieldy, so I suspect few will.  As a result, in practice
this interface to dpriv probably means that most implemented policies
will be more permissive than intended/desired.  I consider that a defect
in the design of the specification language.  It seems like it would
be preferable to have a specification language that better facilitates
secure use of dpriv.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/