Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 13 Jun 2017 07:45:32 +0000
From: Fiedler Roman <Roman.Fiedler@....ac.at>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: Vixie/ISC Cron group crontab to root escalation 

> From: Casper.Dik@...cle.com [mailto:Casper.Dik@...cle.com]
>
>
> >On Jun 9,  6:27pm, solar@...nwall.com (Solar Designer) wrote:
> >-- Subject: Re: [oss-security] Vixie/ISC Cron group crontab to root
> escalatio
> >
> >| Oh, I did in fact mention this in the private discussion, so I'll
> quote:
> >|
> >| | Another detail: somehow in Owl we introduced lstat() prior to open,
> and
> >| | check lstat()'s struct for all the required properties before
> proceeding
> >| | with open() with O_NOFOLLOW.  Then we check that st_dev/st_ino
> stayed
> >| | the same.  We also kept the post-open() checks.  I don't recall
> exactly
> >| | why we added this, but maybe because of the possibility of side-
> effects
> >| | on open() for hard links to device files (like with tape drives).
> And
> >| | it looks like we neglected to add the same for at jobs (perhaps
> didn't
> >| | revisit this when support for at jobs appeared via our update to
> later
> >| | OpenBSD code) - maybe we should.
> >
> >Thanks, perhaps a comment in the code can't hurt...
> >Or even O_NODEV which does not exist, or O_PATH (linux only)..
>
> As there is a O_DIRECTORY it would be more orthogonal to have O_REGULAR
> (open only a regular file).  But that becomes more and more icky as
> we're
> running out of 32 bits of O_*)

Why not stop that at all and have an O_POLICY, that defines the filename 
pointer is pointing to a policy structure? The policy could then have all the 
very useful fields and flags for opening/creating files, e.g.

struct open_policy {

  int		policy_type = ..

POL_FILE_OWNER_SAME_AS_DIR_OWNER
POL_ON_SAME_FILESYSTEM_AS (plus additional reference-fd)
POL_XATTR_PRESENT (plus xattr definition)
POL_UID_PRESENT_IN_CURRENT_USERNS
POL_REGULAR_FILE
POL_FILE_IS_ON_NO_SUID_FILESYSTEM
POL_FILE_OWNER (uid)
POL_FILE_GROUP (group)
...

  void	*policy_data; // additional data, e.g. the reference-fd from above, the 
expected UID, ...
  char	*file_name; // ... and of course the pointer to the filename, we abuse
}

For simplicity, type/data was not repeated, which would make sense to have 
logical AND of multiple policies.

[ CONTENT OF TYPE application/pkcs7-signature SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ