Re: Vixie/ISC Cron group crontab to root escalation

[Fiedler Roman <Roman.Fiedler () ait ac at>]

> From: Casper.Dik () oracle com [mailto:Casper.Dik () oracle com]
>
>
> > On Jun 9,  6:27pm, solar () openwall 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.

Attachment: smime.p7s
Description: