5:45 a.m.
Following up discussion on Github issue #40 ("Backward compatibility with kernel
Smack interfaces is incomplete") I'd like to bring up some ideas that I still
have on this.
There are some kernel features that can be present on the kernel with Smack, but might be
missing. Some of them are detected at runtime by libsmack (i.e. long label support). Some
of them aren't. I'd like to propose an alternative approach for such detection.
Current approach chosen by Jarkko seem to be delaying the detection until it's really
needed. This means that until smackfs interfaces are actually opened, libsmack assumes
that all features are present. When actual interfacing when kernel is needed, libsmack
checks for support and fails if it's not
there. If it's possible, it tries to fall back to an older interface. Results of such
detection are not remembered and it will be repeated each time when needed.
My proposal is for complex detection of kernel features during library initialization with
result stored in an internal, global variable (e.g. feature bitmask). Later on run time
libsmack would be able to use that information to make decisions earlier. For example it
would be possible to fail right
away inside smack_accesses_add() when a long label is given and kernel doesn't support
it.
To allow policy preparation systems with no Smack support or simply with smackfs
temporarily unmounted, I suggest assumption that missing smackfs is equivalent to having
all features enabled. That would work on functions that don't need direct access to
Smack in kernel (smack_accesses_new =>
smack_accesses_add => smack_accesses_save).
I have prepared an initial patch moving existing runtime detection to init.c and using
this information in the library. With this infrastructure it would be possible to add
detection of several other features, that aren't detected right now.
I have however waited too long with my patch and Jarkko has moved in another direction. I
specifically mean patch d7319c7 ("libsmack: add a common function for opening long
and short label file"), which emphasizes late detection. Therefore I'd like to
ask for opinions on the mailing list and check
if I can still convince you to the alternative way.
Finally here are additional the kernel features that I'd like to detect. Checking for
these will require opening of smackfs files and reading/writing to them to make detection
possible. This in my opinion is an argument for running detection only once per process
run time.
* Lock access mode (kernel 3.13)
* Support for multi-rule write to load2 and change-rule (kernel 3.12)
* Maximum value for CIPSO category change from 63 to 184 (kernel 3.12)
* Transmute access mode (kernel 2.6.38)
Best regards,
Rafal Krypa
6:57 a.m.
Hi Rafal,
Sounds good, here is a wilder Idea :) What about calling this
functionality from init, i.e. during systemd setup and the resultant bit
mask could be stored in an extended attr of libsmack.so. Then for normal
processes during library init rather than having to run through the tests
again for each process, just read the extended attr.
Generally if you replace the kernel you will restart the init, so it will
always be in sync with the system that you are running. One issue might be
determining the .so path in a portable way. As I said wild idea ...
Br,
Brian
On Thu, Jan 23, 2014 at 8:45 PM, Rafał Krypa <r.krypa(a)samsung.com> wrote:
Following up discussion on Github issue #40 ("Backward
compatibility with
kernel Smack interfaces is incomplete") I'd like to bring up some ideas
that I still have on this.
There are some kernel features that can be present on the kernel with
Smack, but might be missing. Some of them are detected at runtime by
libsmack (i.e. long label support). Some of them aren't. I'd like to
propose an alternative approach for such detection.
Current approach chosen by Jarkko seem to be delaying the detection until
it's really needed. This means that until smackfs interfaces are actually
opened, libsmack assumes that all features are present. When actual
interfacing when kernel is needed, libsmack checks for support and fails if
it's not
there. If it's possible, it tries to fall back to an older interface.
Results of such detection are not remembered and it will be repeated each
time when needed.
My proposal is for complex detection of kernel features during library
initialization with result stored in an internal, global variable (e.g.
feature bitmask). Later on run time libsmack would be able to use that
information to make decisions earlier. For example it would be possible to
fail right
away inside smack_accesses_add() when a long label is given and kernel
doesn't support it.
To allow policy preparation systems with no Smack support or simply with
smackfs temporarily unmounted, I suggest assumption that missing smackfs is
equivalent to having all features enabled. That would work on functions
that don't need direct access to Smack in kernel (smack_accesses_new =>
smack_accesses_add => smack_accesses_save).
I have prepared an initial patch moving existing runtime detection to
init.c and using this information in the library. With this infrastructure
it would be possible to add detection of several other features, that
aren't detected right now.
I have however waited too long with my patch and Jarkko has moved in
another direction. I specifically mean patch d7319c7 ("libsmack: add a
common function for opening long and short label file"), which emphasizes
late detection. Therefore I'd like to ask for opinions on the mailing list
and check
if I can still convince you to the alternative way.
Finally here are additional the kernel features that I'd like to detect.
Checking for these will require opening of smackfs files and
reading/writing to them to make detection possible. This in my opinion is
an argument for running detection only once per process run time.
* Lock access mode (kernel 3.13)
* Support for multi-rule write to load2 and change-rule (kernel 3.12)
* Maximum value for CIPSO category change from 63 to 184 (kernel 3.12)
* Transmute access mode (kernel 2.6.38)
Best regards,
Rafal Krypa
_______________________________________________
SMACK-discuss mailing list
SMACK-discuss(a)lists.01.org
https://lists.01.org/mailman/listinfo/smack-discuss
6:45 p.m.
On Thu, Jan 23, 2014 at 09:57:38PM +0200, Mcgillion, Brian wrote:
Hi Rafal,
Sounds good, here is a wilder Idea :) Â What about calling this
functionality from init, i.e. during systemd setup and the resultant bit
mask could be stored in an extended attr of libsmack.so. Â Then for normal
processes during library init rather than having to run through the tests
again for each process, just read the extended attr.
I don't want to mix up extended attributes in to equation in order to
get a minor performance benefit or add any depedency to systemd.
/Jarkko
10:07 a.m.
On 1/23/2014 10:45 AM, Rafał Krypa wrote:
Following up discussion on Github issue #40 ("Backward
compatibility with kernel Smack interfaces is incomplete") I'd like to bring up
some ideas that I still have on this.
There are some kernel features that can be present on the kernel with Smack, but might be
missing. Some of them are detected at runtime by libsmack (i.e. long label support). Some
of them aren't. I'd like to propose an alternative approach for such detection.
Current approach chosen by Jarkko seem to be delaying the detection until it's really
needed. This means that until smackfs interfaces are actually opened, libsmack assumes
that all features are present. When actual interfacing when kernel is needed, libsmack
checks for support and fails if it's not
there. If it's possible, it tries to fall back to an older interface. Results of such
detection are not remembered and it will be repeated each time when needed.
This is actually the most efficient approach in most cases.
Most programs that use libsmack use it to get or set one value.
Why bother to remember state that you will never care about again?
I can see some value in remembering fall-back behavior for those
few interfaces that:
1. get called repeatedly in a program (/sys/fs/smackfs/access2)
and
2. have alternative interfaces (/smack/load, /sys/fs/smackfs/load2)
My proposal is for complex detection of kernel features during
library initialization with result stored in an internal, global variable (e.g. feature
bitmask).
This would introduce unnecessary overhead for programs like id.
Later on run time libsmack would be able to use that information to
make decisions earlier. For example it would be possible to fail right
away inside smack_accesses_add() when a long label is given and kernel doesn't
support it.
This would be simple to optimize. Keep track of whichever path open succeeds
and on subsequent opens go directly to the one known to exist. If that fails
you can bet there has been an inappropriate unmount.
This optimization would speed up the backward compatibility case without
impacting programs that don't use this function. It won't impact the common
case, which is that the kernel is up to date, either.
To allow policy preparation systems with no Smack support or simply
with smackfs temporarily unmounted, I suggest assumption that missing smackfs is
equivalent to having all features enabled. That would work on functions that don't
need direct access to Smack in kernel (smack_accesses_new =>
smack_accesses_add => smack_accesses_save).
That is not the assumption i would expect. I don't see a lot of value
in having libsmack on a system without Smack, and the few things that
could work would have to be used in a contrived way.
I have prepared an initial patch moving existing runtime detection to
init.c and using this information in the library. With this infrastructure it would be
possible to add detection of several other features, that aren't detected right now.
I have however waited too long with my patch and Jarkko has moved in another direction. I
specifically mean patch d7319c7 ("libsmack: add a common function for opening long
and short label file"), which emphasizes late detection. Therefore I'd like to
ask for opinions on the mailing list and check
if I can still convince you to the alternative way.
I don't think that optimization of libsmack in support of
deployment on older kernel versions is worth putting any effort
into. The functions in libsmack just don't get called that
often.
Finally here are additional the kernel features that I'd like to
detect. Checking for these will require opening of smackfs files and reading/writing to
them to make detection possible. This in my opinion is an argument for running detection
only once per process run time.
* Lock access mode (kernel 3.13)
How will you detect this without creating a potentially harmful access rule?
* Support for multi-rule write to load2 and change-rule (kernel
3.12)
How will you detect this without creating a potentially harmful access rule?
* Maximum value for CIPSO category change from 63 to 184 (kernel
3.12)
How will you detect this?
* Transmute access mode (kernel 2.6.38)
How will you detect this without creating a potentially harmful access rule?
Best regards,
Rafal Krypa
_______________________________________________
SMACK-discuss mailing list
SMACK-discuss(a)lists.01.org
https://lists.01.org/mailman/listinfo/smack-discuss
6:49 p.m.
On Thu, Jan 23, 2014 at 03:07:52PM -0800, Casey Schaufler wrote:
On 1/23/2014 10:45 AM, Rafał Krypa wrote:
> Following up discussion on Github issue #40 ("Backward compatibility with
kernel Smack interfaces is incomplete") I'd like to bring up some ideas that I
still have on this.
>
This is actually the most efficient approach in most cases.
Most programs that use libsmack use it to get or set one value.
Why bother to remember state that you will never care about again?
This is ad valid point. I really want some performance figures to I
doubt there's too much to gain here.
/Jarkko
6:43 p.m.
On Thu, Jan 23, 2014 at 07:45:23PM +0100, Rafał Krypa wrote:
I have prepared an initial patch moving existing runtime detection
to init.c and using this information in the library. With this
infrastructure it would be possible to add detection of several
other features, that aren't detected right now. I have however
waited too long with my patch and Jarkko has moved in another
direction. I specifically mean patch d7319c7 ("libsmack: add a
common function for opening long and short label file"), which
emphasizes late detection. Therefore I'd like to ask for opinions on
the mailing list and check if I can still convince you to the
alternative way.
I would not say that I've moved to the other direction. I've just
fixed things so that they fit into current framework. I'm all for
early detection features in the library initializer for example.
I don't think the mentioned patch would be a major blocker for doing a
design change here.
/Jarkko
6:57 p.m.
On Fri, Jan 24, 2014 at 09:43:13AM +0200, Jarkko Sakkinen wrote:
On Thu, Jan 23, 2014 at 07:45:23PM +0100, Rafał Krypa wrote:
> I have prepared an initial patch moving existing runtime detection
> to init.c and using this information in the library. With this
> infrastructure it would be possible to add detection of several
> other features, that aren't detected right now. I have however
> waited too long with my patch and Jarkko has moved in another
> direction. I specifically mean patch d7319c7 ("libsmack: add a
> common function for opening long and short label file"), which
> emphasizes late detection. Therefore I'd like to ask for opinions on
> the mailing list and check if I can still convince you to the
> alternative way.
I would not say that I've moved to the other direction. I've just
fixed things so that they fit into current framework. I'm all for
early detection features in the library initializer for example.
I have to take my words back here a bit.
I'm not terribly enthusiastic to change things in this area if they
don't provably bring some significant value and for me it is hard to
see the value here.
What would bring value for the library would be actually make things
even more lazy and move smackfs detection from library initializer to
a separate function that would be called when some SmackFS-dependent
function is first called.
/Jarkko
8:35 p.m.
On gio, 2014-01-23 at 19:45 +0100, Rafał Krypa wrote:
Finally here are additional the kernel features that I'd like to
detect. Checking for these will require opening of smackfs files and reading/writing to
them to make detection possible. This in my opinion is an argument for running detection
only once per process run time.
* Lock access mode (kernel 3.13)
* Support for multi-rule write to load2 and change-rule (kernel 3.12)
* Maximum value for CIPSO category change from 63 to 184 (kernel 3.12)
* Transmute access mode (kernel 2.6.38)
What about using the 'uname' syscall to identify the kernel version?
Joint to some knowledge(*) of smack availabilities depending of the
kernel, it may provide a good estimation of the current capabilities.
It has the minor benefit to be independent of the mounting status of
smackfs but does it really care?
On the choice of the detection policy (at init or at need), I don't have
a clear-cut opinion. Both have advantages and drawbacks.
Best regards
José
(*) Is there a kind of matrix for that knowledge? I'm, currently,
digging logs and change logs what is painful.
2:50 a.m.
-----Original Message-----
From: SMACK-discuss [mailto:smack-discuss-bounces@lists.01.org] On
Behalf Of José Bollo
Sent: Friday, January 24, 2014 1:36 AM
To: smack-discuss(a)lists.01.org
Subject: Re: [SMACK-discuss] Detecting kernel Smack features in libsmack
On gio, 2014-01-23 at 19:45 +0100, Rafał Krypa wrote:
> Finally here are additional the kernel features that I'd like to detect.
Checking for these will require opening of smackfs files and reading/writing
to them to make detection possible. This in my opinion is an argument for
running detection only once per process run time.
>
> * Lock access mode (kernel 3.13)
> * Support for multi-rule write to load2 and change-rule (kernel 3.12)
> * Maximum value for CIPSO category change from 63 to 184 (kernel 3.12)
> * Transmute access mode (kernel 2.6.38)
>
What about using the 'uname' syscall to identify the kernel version?
That will give you a good hint, but won't be definitive.
An old kernel may have new behavior backported.
The smackfs may be mounted anywhere.
While new kernels provide the /sys/fs/smackfs mount point
there is nothing to enforce that smackfs get mounted
there.
Joint to some knowledge(*) of smack availabilities depending of the
kernel, it
may provide a good estimation of the current capabilities.
It has the minor benefit to be independent of the mounting status of
smackfs but does it really care?
The uname call won't tell you if Smack is enabled.
On the choice of the detection policy (at init or at need), I
don't have a clear-
cut opinion. Both have advantages and drawbacks.
Best regards
José
(*) Is there a kind of matrix for that knowledge? I'm, currently, digging logs
and change logs what is painful.
_______________________________________________
SMACK-discuss mailing list
SMACK-discuss(a)lists.01.org
https://lists.01.org/mailman/listinfo/smack-discuss
8:11 p.m.
On Fri, Jan 24, 2014 at 03:50:07PM +0000, Schaufler, Casey wrote:
> -----Original Message-----
> From: SMACK-discuss [mailto:smack-discuss-bounces@lists.01.org] On
> Behalf Of José Bollo
> Sent: Friday, January 24, 2014 1:36 AM
> To: smack-discuss(a)lists.01.org
> Subject: Re: [SMACK-discuss] Detecting kernel Smack features in libsmack
>
> On gio, 2014-01-23 at 19:45 +0100, Rafał Krypa wrote:
>
> > Finally here are additional the kernel features that I'd like to detect.
> Checking for these will require opening of smackfs files and reading/writing
> to them to make detection possible. This in my opinion is an argument for
> running detection only once per process run time.
> >
> > * Lock access mode (kernel 3.13)
> > * Support for multi-rule write to load2 and change-rule (kernel 3.12)
> > * Maximum value for CIPSO category change from 63 to 184 (kernel 3.12)
> > * Transmute access mode (kernel 2.6.38)
> >
>
> What about using the 'uname' syscall to identify the kernel version?
That will give you a good hint, but won't be definitive.
An old kernel may have new behavior backported.
The smackfs may be mounted anywhere.
While new kernels provide the /sys/fs/smackfs mount point
there is nothing to enforce that smackfs get mounted
there.
Casey, there's code that finds the right mount point in libsmack
and keeps fd open through the life-cycle of the process.
/Jarkko
8:10 p.m.
Hi
On Fri, Jan 24, 2014 at 10:35:53AM +0100, José Bollo wrote:
On gio, 2014-01-23 at 19:45 +0100, Rafał Krypa wrote:
> Finally here are additional the kernel features that I'd like to detect.
Checking for these will require opening of smackfs files and reading/writing to them to
make detection possible. This in my opinion is an argument for running detection only once
per process run time.
>
> * Lock access mode (kernel 3.13)
> * Support for multi-rule write to load2 and change-rule (kernel 3.12)
> * Maximum value for CIPSO category change from 63 to 184 (kernel 3.12)
> * Transmute access mode (kernel 2.6.38)
>
What about using the 'uname' syscall to identify the kernel version?
Joint to some knowledge(*) of smack availabilities depending of the
kernel, it may provide a good estimation of the current capabilities.
It has the minor benefit to be independent of the mounting status of
smackfs but does it really care?
On the choice of the detection policy (at init or at need), I don't have
a clear-cut opinion. Both have advantages and drawbacks.
Putting those four items in the same discussion is too abstract. I'm
willing to review patch for multi-rule support as a separate
item. Other than that I'm participating to this discussion because
there's not chance to form a single yes/no opinion of multiple
separate aspects.
I'm quite resistant to change the code that opens either long or short
label file to something else because it is working and tested code
that has been existing for a long time.
Best regards
José
/Jarkko
5:09 p.m.
On Mon, Jan 27, 2014 at 11:10:03AM +0200, Jarkko Sakkinen wrote:
Hi
On Fri, Jan 24, 2014 at 10:35:53AM +0100, José Bollo wrote:
> On gio, 2014-01-23 at 19:45 +0100, Rafał Krypa wrote:
>
> > Finally here are additional the kernel features that I'd like to detect.
Checking for these will require opening of smackfs files and reading/writing to them to
make detection possible. This in my opinion is an argument for running detection only once
per process run time.
> >
> > * Lock access mode (kernel 3.13)
> > * Support for multi-rule write to load2 and change-rule (kernel 3.12)
> > * Maximum value for CIPSO category change from 63 to 184 (kernel 3.12)
> > * Transmute access mode (kernel 2.6.38)
> >
>
> What about using the 'uname' syscall to identify the kernel version?
> Joint to some knowledge(*) of smack availabilities depending of the
> kernel, it may provide a good estimation of the current capabilities.
>
> It has the minor benefit to be independent of the mounting status of
> smackfs but does it really care?
>
> On the choice of the detection policy (at init or at need), I don't have
> a clear-cut opinion. Both have advantages and drawbacks.
Putting those four items in the same discussion is too abstract. I'm
willing to review patch for multi-rule support as a separate
item. Other than that I'm participating to this discussion because
Shouldn't write emails in hurry. s/participating/parting/.
/Jarkko
3155
days inactive
3160
days old
11 comments
6 participants
participants (6)
-
Casey Schaufler -
Jarkko Sakkinen -
José Bollo -
Mcgillion, Brian -
Rafał Krypa -
Schaufler, Casey