On Thursday, August 13, 2015 04:40:52 PM Steve Grubb wrote:
> On Wednesday, August 12, 2015 10:48:10 PM Paul Moore wrote:
> > On Wednesday, August 12, 2015 05:38:14 PM Steve Grubb wrote:
> > > On Wednesday, August 12, 2015 08:40:34 AM Paul Moore wrote:
> > > > Hello all,
> > > >
> > > > I'm curren
From: Sven Vermeulen
As per the discussion on the selinux development mailinglist, the tmux
application expects the stdin to be writeable. Although perhaps not the most
proper way, having newrole opening the descriptor in read/write keeps the
behaviour in line with what applications expect.
See
Set the "keep capabilities" flag around the setresuid() calls in
drop_capabilities() so that we do not simultaneously drop all
capabilities (when newrole is setuid).
Signed-off-by: Stephen Smalley
---
policycoreutils/newrole/newrole.c | 22 ++
1 file changed, 22 insertions(+)
From: Dan Walsh
Stop dropping capabilities from its children.
Add better error messages.
Signed-off-by: Dan Walsh
---
policycoreutils/newrole/newrole.c | 60 +--
1 file changed, 39 insertions(+), 21 deletions(-)
diff --git a/policycoreutils/newrole/newrole.
On 10/01/2015 03:51 AM, Laurent Bigonville wrote:
Le 29/09/15 21:35, Stephen Smalley a écrit :
On 09/26/2015 09:10 PM, Laurent Bigonville wrote:
[...]
The patch seems to break an other thing, it Fedora the newrole
executable is not setuid root, but it is granted a bunch of capabilities
expli
Mike Snitzer writes:
> What layer establishes access rights to historically root-only
> priviledged block devices? Is it user namespaces?
Block devices are weird.
Mounts historically have not checked the permissions on the block
devices because a mounter has CAP_SYS_ADMIN.
Unprivileged users
On Thu, Oct 01, 2015 at 10:40:08AM -0500, Eric W. Biederman wrote:
> Seth Forshee writes:
>
> > When mounting a filesystem on a block device there is currently
> > no verification that the user has appropriate access to the
> > device file passed to mount. This has not been an issue so far
> > si
Seth Forshee writes:
> When mounting a filesystem on a block device there is currently
> no verification that the user has appropriate access to the
> device file passed to mount. This has not been an issue so far
> since the user in question has always been root, but this must
> be changed befor
On Thu, Oct 01, 2015 at 09:40:52AM -0400, Mike Snitzer wrote:
> On Thu, Oct 01 2015 at 8:55am -0400,
> Seth Forshee wrote:
>
> > On Wed, Sep 30, 2015 at 07:42:15PM -0400, Mike Snitzer wrote:
> > > On Wed, Sep 30 2015 at 4:15pm -0400,
> > > Seth Forshee wrote:
> > >
> > > > When mounting a fil
> On Tuesday, 29 September 2015, 21:25, Stephen Smalley
> wrote:
> > On 09/27/2015 08:06 AM, Richard Haines wrote:
>> The selinux_restorecon(3) man page details this function that relies
>> on the selabel_digest(3) function available from [1] (as not yet
>> part of upstream libselinux).
>
On Thu, Oct 01 2015 at 8:55am -0400,
Seth Forshee wrote:
> On Wed, Sep 30, 2015 at 07:42:15PM -0400, Mike Snitzer wrote:
> > On Wed, Sep 30 2015 at 4:15pm -0400,
> > Seth Forshee wrote:
> >
> > > When mounting a filesystem on a block device there is currently
> > > no verification that the us
On Wed, Sep 30, 2015 at 07:42:15PM -0400, Mike Snitzer wrote:
> On Wed, Sep 30 2015 at 4:15pm -0400,
> Seth Forshee wrote:
>
> > When mounting a filesystem on a block device there is currently
> > no verification that the user has appropriate access to the
> > device file passed to mount. This h
On Wed, Sep 30 2015 at 4:15pm -0400,
Seth Forshee wrote:
> When mounting a filesystem on a block device there is currently
> no verification that the user has appropriate access to the
> device file passed to mount. This has not been an issue so far
> since the user in question has always been r
On Thu, Sep 03, 2015 at 02:14:18PM -0700, Kees Cook wrote:
> [removed bounced email addresses]
>
> On Wed, Sep 2, 2015 at 2:37 PM, Luis R. Rodriguez wrote:
> > On Wed, Sep 02, 2015 at 01:54:43PM -0700, Kees Cook wrote:
> >> On Wed, Sep 2, 2015 at 11:46 AM, Luis R. Rodriguez wrote:
> >> > On Tue,
Le 29/09/15 21:35, Stephen Smalley a écrit :
On 09/26/2015 09:10 PM, Laurent Bigonville wrote:
[...]
The patch seems to break an other thing, it Fedora the newrole
executable is not setuid root, but it is granted a bunch of capabilities
explicitly, if I setuid this executable instead of grant
15 matches
Mail list logo