On 14 Dec 2014 at 4:18, "Tóth Attila" wrote:

> I've made an observation long before, that although PT_PAX flags are
> properly handled on my systems, the installed binaries and libraries lack
> XATTR_PAX markings.

first, PaX flags don't matter on libraries at all as only the executable
is used to determine the runtime flags. second, lack of xattrs means that
the secure defaults will be used (modulo what other control methods are
in play of course, see below).

> I have both PT and XT present in my make.conf for markings. I was told
> before, that I should rather opt for only one of the two possibilities -
> kernel-option wise and make.conf-marking-selection wise. Kinda both PT and
> XT are not supported at the same time using the current utilities.

what particular issues do you still have?

> Moreover: there is the question if PT marking is present and XATTR is
> missing at the same time: which one takes precedence? I suspect the system
> tries to interpret the missing XATTR, falling back to apply the default
> flags, while paying no attention to the PT flags present. Additionally, I
> haven't mentioned any policy defined PAX flags.

the general rule is that if a marking is missing (either from the kernel
config or the executable) then it won't participate in the decision making
process.

if both marks are present then they must be the same, otherwise the existing
mark will be used as is.

if neither mark exists then defaults will be used whose value depends on
softmode. in practice you'll get secure defaults in !softmode (this hierarchy
was introduced earlier this year, the defaults used to be not secure before
due to compatibility concerns for unmarked binaries, but i finally made the
switch).

for this reason these days you should really only set marks when you actually
want to deviate from the (now) secure defaults.

note that PT_PAX_FLAGS is special in that it's easier to create it at link
time than afterwards, so its presence is ok even if you don't change its
default value (which has always been secure for !softmode).


Reply via email to