[tomoyo-users-en 626] Re: Editor not launching; setting trigger with systemd; USRLIBDIR; etc.

Back to archive index
Tetsuo Handa from-****@I-lov*****
Sun May 24 15:56:41 JST 2015


Jose Jurado wrote:
> 
> Tomoyo 1.8.4 was installed on an Arch distro (Antergos) with the download of
> the Linux kernel 4.0.4 and tomoyo-tools following Tomoyo 1.8's documentation.
> There were eight passages during the installation that I may have misunderstood,
> and I hope that this list is not overwhelming, but I would be very grateful
> for your suggestions or for clarifications in the documentation:-  
> 
> (1) During the first session after rebooting, I could access the graphical
>     interface with the command "/usr/bin/ccs-editpolicy /etc/ccs/".  Running
>     "/usr/bin/ccs-editpolicy" however generated an error message.  I can't
>     remember what the error message was, but it sounded similar or identical
>     to the one I get for that command today:
>     "You can't use this editor for this kernel."  
> 
>     On rebooting today, I get error messages as well for: 
> 
>     $ /usr/bin/ccs-editpolicy /etc/ccs/
>     Directory /etc/ccs//policy/current/ doesn't exist.
> 
>     $ /usr/bin/ccs-editpolicy /etc/ccs
>     Directory /etc/ccs/policy/current/ doesn't exist.
> 
>     I note the documentation for the previous version (Tomoyo 1.7), which advises
>     that "You need to register either "the domainname that this editor belongs to"
>     or "the pathname of this editor (usually /usr/sbin/ccs-editpolicy)" with
>     /proc/ccs/manager before you use this editor."  Would this be required for
>     Tomoyo 1.8?  If that is why the above error messages are appearing, could you
>     kindly list what command(s) would register this?

"You can't use this editor for this kernel." is emitted when /proc/ccs/
directory does not exist (i.e. when you did not boot with TOMOYO 1.8 kernel).

"Directory /etc/ccs//policy/current/ doesn't exist." is emitted when you
tried to run /usr/bin/ccs-editpolicy as non-root user. (By default,
permissions are set in a way that only root user can use tools which touch
/proc/ccs/ and/or /etc/ccs/ directory.)

> 
> (2) My Arch installation already had packages installed for: wget patch gcc make;
>     but ncurses-devel nor libncurses-dev were not available on Arch/AUR repositories.
>     If they are required for Arch, where can they be downloaded from please?

Did you get error message shown below while compiling ccs-tools?

    /usr/include/curses.h is missing.
    Run 'yum install ncurses-devel' or 'apt-get install libncurses-dev'

If no, you don't need to install ncurses-devel or libncurses-dev because
a package that provides /usr/include/curses.h is already installed on your
system.

If yes, I don't know name of package that provides /usr/include/curses.h .
But according to https://bbs.archlinux.org/viewtopic.php?id=117029 , it is
included in ncurses package.

> 
> (3) The linux 4.0.4 kernel was downloaded from the offered location, but
>     I'm afraid I couldn't work out from the documentation nor from certain
>     other websites where to "Extract the kernel source and go to the
>     extracted directory", so the following was executed at the home folder:
> 
>     tar -zxf linux-4.0.4.tar.gz 
>     cd linux-4.0.4/
> 
>     The remainder of the operations in Section "3.3.2. Download and patch
>     the kernel" were performed within the /linux-4.0.4 folder:
> 
>     wget -O ccs-patch-1.8.4-20150505.tar.gz  [etc]
>     wget -O ccs-patch-1.8.4-20150505.tar.gz.asc [etc]
>     gpg ccs-patch-1.8.4-20150505.tar.gz.asc   #Note: no public key was available
>     tar -zxf ccs-patch-1.8.4-20150505.tar.gz
>     patch -sp1  [etc]
> 
>     Was that ok?

No problem. You can extract anywhere, home directory is fine.

My public key is at http://I-love.SAKURA.ne.jp/kumaneko-key but you may check
md5sum instead.

    MD5                               Filename
    555594888ff3d50154878e5b8fdbc05f  ccs-patch-1.8.4-20150505.tar.gz
    eeee8eb96a7680bfa9c8f6de55502c44  ccs-tools-1.8.4-20150505.tar.gz

> 
> (4) The "Security Options" for the 4.0.4 kernel include an option to select
>     "Tools for Tomoyo users" or something like that, but maybe the Tomoyo
>     installation documentation does not mention this.  Should this option
>     be selected? 

Options for TOMOYO 2.5 in vanilla kernel are

    [*] TOMOYO Linux Support
    (2048) Default maximal count for learning mode
    (1024) Default maximal count for audit log
    [ ]   Activate without calling userspace policy loader.
    (/sbin/tomoyo-init) Location of userspace policy loader
    (/sbin/init) Trigger for calling userspace policy loader

and options for TOMOYO 1.8 patched kernels are

    [*] CCSecurity support
    [ ]   Compile as loadable kernel module
    [ ]   Disable by default
    [ ]   Do not modify 'struct task_struct' in order to keep KABI
    (2048) Default maximal count for learning mode
    (1024) Default maximal count for audit log
    [ ]   Activate without calling userspace policy loader.
    (/sbin/ccs-init) Location of userspace policy loader
    (/sbin/init) Trigger for calling userspace policy loader
    [*]   Enable readdir operation restriction.
    [*]   Enable getattr operation restriction.
    [*]   Enable socket operation restriction.
    [*]   Enable non-POSIX capability operation restriction.
    [*]   Enable IPC operation restriction.
    [*]   Enable environment variable names restriction.
    [*]   Enable execute handler functionality.
    [*]   Enable domain transition without program execution request.
    [*]   Enable local port reserver.

but I don't know options like "Tools for Tomoyo users".
Maybe that option is specific to Antergos distributions.
https://wiki.archlinux.org/index.php/TOMOYO_Linux

> 
> (5) When configuring the kernel, the documentation's recommended settings
>     for "Security Options" were already set by default by the kernel, including
>     "(/sbin/init) Trigger for calling userspace policy loader".  Should the
>     documentation here recommend systemd users (Arch, RHEL 7, etc) to replace
>     this with (/usr/lib/systemd/systemd) as the Trigger?  I haven't tried
>     changing this yet.

Yes if /usr/lib/systemd/systemd is executed from your initramfs. The program
executed from initramfs depends on distributions and their versions.
Older distributions execute /sbin/init . Some distributions execute
/bin/systemd . Other distributions execute /usr/lib/systemd/systemd .
There would be distributions which execute none of above.

> 
> (6) I understand that "CCS_trigger=/usr/lib/systemd/systemd" should be stated
>     in the bootloader for systemd users if kernel entry "(/sbin/init) Trigger
>     for calling userspace policy loader" is not modified and if "Activate
>     without calling userspace policy loader" is not selected.  However, when
>     using Grub Customizer tool as someone who isn't used to modifying GRUB,
>     I assumed that "ccsecurity=on" (without quotes) should be added at the
>     end of the GRUB_CMDLINE_LINUX line.  Perhaps following this on that line
>     should be "CCS_trigger=/usr/lib/systemd/systemd" in my case (also without
>     quotes), is that correct?  "CCS_trigger=/usr/lib/systemd/systemd" has not
>     been entered in GRUB, even since error (1) above occurred (i.e. since
>     first run).

ccsecurity=on is needed only if you chose "Disable by default" when compiling
TOMOYO 1.8 patched kernels.

CCS_trigger=/usr/lib/systemd/systemd is needed only if you didn't set
/usr/lib/systemd/systemd to "Trigger for calling userspace policy loader"
when compiling TOMOYO 1.8 patched kernels.

You can use CCS_trigger= option for trying to find a correct pathname to
specify. When you specified a correct pathname, you will get

    Calling %s to load policy. Please wait.

in your dmesg where %s is the pathname you specified.

After you found the correct pathname to specify, you can recompile your kernel
with the correct pathname specified at "Trigger for calling userspace policy
loader" and remove CCS_trigger= option.

> 
> (7) Were the warnings obtained when compiling and installing the kernel
>     relevant: http://pastebin.com/nCN27zUq ?

Warnings in that URL are irrelevant to TOMOYO, except
non-warning messages shown below are emitted by TOMOYO.

    Creating an empty policy/profile.conf
    Creating a default policy/exception_policy.conf
    Creating an empty policy/domain_policy.conf
    Creating an empty policy/manager.conf
    Creating an empty policy/stat.conf
    Generating built-in policy for TOMOYO 1.8.x.

> 
> (8) During the installation of userspace tools several warnings appeared,
>     beginning as follows:-
> 
>     make -s USRLIBDIR=/usr/lib
> 
>     [Warnings appeared here, starting by:]
>     ccs-init.c:93:9: warning: variable 喪et_ignored・set but not used [-Wunused-but-set-variable]
>         char *ret_ignored;
>              ^
>     ccs-init.c: In function 祖opy_files・
>     ccs-init.c:173:8: warning: variable 喪et_ignored・set but not used [-Wunused-but-set-variable]
>         int ret_ignored;
>         ^
>     [...]
> 
>     There were more warnings, but they weren't recorded, unfortunately.
>     I note the following instruction:  "Please change USRLIBDIR=/usr/lib to
>     USRLIBDIR=/usr/lib64 (for 64bits userspace) or USRLIBDIR=/usr/lib32 (for
>     32bits userspace) if needed".  However, I didn't know whether this was
>     required on my 64-bit machine so those lines were not modified.
>     Was that ok, or is there an explanation or a webpage that could be
>     looked at that which might address when USRLIBDIR needs to be set as 32
>     or 64-bit please?

You can ignore all of

   warning: variable $name_of_variable set but not used [-Wunused-but-set-variable]

warning messages emitted during the compilation of ccs-tools.

In principle, you can specify the directory which exists in your system to
USRLIBDIR . I've heard that some distribution switches /usr/lib64 and
/usr/lib32 using a symlink named /usr/lib .

If your system has /usr/lib64 , you can change USRLIBDIR=/usr/lib to
USRLIBDIR=/usr/lib64 because you are trying to build ccs-tools for 64-bits
machine (assuming that you built your kernel for 64-bits machine as well).

If your system does not have /usr/lib64 but has /usr/lib , you won't need to
change USRLIBDIR= setting.

> 
> I hope that this list is not off-putting, but I hope also that the list of error
> and warning messages may be of interest to keep improving your helpful
> documentation and your excellent application. 

The list of error and warning messages varies depending on distributions and
their configurations. I can't catch up to distribution specific differences.

This ML is for Q&A about TOMOYO/AKARI/CaitSith users. Your questions are
welcomed.

By the way, Arch Linux provides plenty amount of documentation. You could find
some regarding TOMOYO.




More information about the tomoyo-users-en mailing list
Back to archive index