[<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.
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4814 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
