linux-kernel - Re: [RFC][PATCH 1/1] support optional non-VFS capability inheritance without disabling file caps

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]

Date:	Sun, 16 Aug 2009 21:50:34 -0700
From:	"Andrew G. Morgan" <morgan@...nel.org>
To:	Will Drewry <redpig@...aspill.org>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>, linux-kernel@...r.kernel.org,
	James Morris <jmorris@...ei.org>,
	linux-security-module@...r.kernel.org,
	David Howells <dhowells@...hat.com>
Subject: Re: [RFC][PATCH 1/1] support optional non-VFS capability inheritance 
	without disabling file caps

Will,

I've read this over a few times, but the in-lining is confusing me.
The idea of tying privilege only to 'anointed' binaries is the "POSIX"
capabilities model.

If you are willing to concede that one can always arrange xattrs to be
convenient with various filesystem mounting techniques, are you saying
you would like all executables to be able to wield privilege if their
parent wants to give it to them?

Thanks

Andrew

On Sat, Aug 15, 2009 at 9:24 PM, Will Drewry<redpig@...aspill.org> wrote:
> On Sat, Aug 15, 2009 at 12:22 PM, Andrew G. Morgan<morgan@...nel.org> wrote:
>> Naive process inheritance of privilege is one of the things this whole
>> infrastructure is trying to discourage...
>
> Hrm I know that was more of the intent of POSIX file capabilities
> (AFAICT), but I was under the impression that the full picture of
> capabilities in linux were more about moving away from a default-on,
> binary superuser privilege policy.  But you'd know what your intentions
> were better than me :)
>
> I was hoping that a process inheritance approach wouldn't be considered
> the same as root inheritance is now.  It operates with the same
> granularity as the file-based approach except that it allows these
> lesser privilege sets to be limited in time for a binary. E.g.,
> it'd be nice if pulseaudio could be started with privileges only at,
> let's say, login-time for a user and not when a remote attacker needs to
> bypass mmap_min_addr.
>
>> Overlays aside, is there some limit on the sophistication of your
>> filesystem setup? Presumably, one could create a small filesystem in a
>> file and, using the loopback device, mount it. Such a filesystem could
>> have xattrs ACLs and filecaps and give you all the specificity you
>> need for this purpose. /chroot/mnt/sbin/ etc.
>
> That's a perfectly nice workaround (especially since it'd be easy enough
> to pair with some symlinks), but I am interested in both issues --
> xattr-less filesystems and the inflexibility of filesystem-based
> security policy.
>
> If the patch (and my intentions) are irreconcilably at odds with the
> capability system (and securebits) goals, then I can definitely evaluate
> other avenues as well as revisit the underpinnings of my plans.  I was
> just hoping that this would fit in under the current umbrella (e.g., like
> the other root-to-capability-mode transition fixups).
>
> If it's a hopeless case, please let me know!  However, I'm happy to
> make any number of changes if something like this is feasible.
>
> thanks!
> will
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
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/