If you use it, what is your experience? Why do you use it, and what do you use it for mostly/exactly?
If NOT, then, why do so few people here use Tomoyo? Why do you not use it?

I'm asking because I see very few topics on Linuxquestions about Tomoyo, and I'm kind of wondering why that is. And, if you don't use Tomoyo, do you use another LSM. If not, why? And I don't mean those that just got Selinux/Apparmor with their distro without actively using it themselves. So don't say yes if you're one of them, then specify that you use it for that reason.

I'm just generally curious. I do understand peoples aversion to using SELinux, for being complicated to set up and manage and taking alot of effort. But I also appreciate that people do use SELinux despite that. But other than that, I think both Apparmor and Tomoyo are "easy" alternatives to SELinux, and should not have such a high treshhold for using.

In particular I think Tomoyo is something alot of people could use quite easily. So I don't understand why so few people on Linuxquestions do, or talk about it. I guess one reason might be that you don't have control of what is included in the Kernel of your distro, and don't have the ability to include Tomoyo. That's a valid argument. But other than that, Tomoyo is extremely easy to implement if you have any knowledge of how to deal with the Kernel. User tools are very easy to install and generally easy to use. Tomoyo don't even have to be intrusive if you "enable" it, you can just install it and let it sit there and analyze your system. From there on you can scale your use of Tomoyo from locking almost nothing, to locking almost everything. And doing so is easy and efficient.

Tomoyo is probably the easiest of the LSM to use and manage, which makes me curious as to why the usage among Linuxquestions folks is not more active. It's not perfect security, and even the creators say a more "ideal" solution is to use both Tomoyo and SELinux together. But, it is alot more than nothing, and it can easily restrict some questionable default behaviours and access on any regular distro and "easily" add a substantial layer of security with very light effort. Including webservers!! It even has a specific module to extrend special security for Apache (more easily). Why don't the "apache tribe" here use Tomoyo?

This leads me back to the original question..

And yes, I do want to promote Tomoyo and encourage people to try it and use it. It is extremely light/minimalistic and fairly easy to implement and use. It's actually highly impressive. So if you haven't tried, then give it a try!

Really? Well, if that is the case, that is ofcourse an issue. But I actually thought/assumed most people at least know or have an idea what Tomoyo Linux is. My bad! You might be very right! I should do what you said. So, here we go.

- Tomoyo Linux is an implementation of Linux MAC (Mandatory Access Control) through LSM (Linux Security Modules). It is part of the Linux Kernel that you can use and activate if you want.
- LSM is a Linux Kernel Framework to support various Kernel based security models.
- MAC is a security model that locks down all system access which is not specified to be allowed (access policies)

And in other words and further information:
https://en.wikipedia.org/wiki/Tomoyo_Linux
https://tomoyo.osdn.jp/

Ok, so, why people should use it, ehm, I think other people could come up with alot better reason than I can. But, basically to secure their system further than what default security does. And one of the reasons people SHOULD use it in my opinion, is because alot of people talk about security around here, but they don't really DO something substantial about it. Tomoyo CAN do something substantial about it, and might be a replacement for YOUR non MAC based security solutions. That includes alot of talk on these forums about among others Apache/webserver and things like openSSH. It's also good to use to understand what your system and software is actually doing. It's good to further learn about your system.

Alot of perceived security issues discussed around here can be solved by implementing MAC on your system. Tomoyo is one of those MAC solutions.

All of that without saying what it is, what it does or why we should use it.

1 members found this post helpful.

Actually, one of the reasons I'm talking about this is because I think in the context of Slackware, Tomoyo is a very good analyzes and security solution. I'm looking at Slackware 15 currently, and looking into making it my default distro (I'm an old Slackware user, returning).

Anyways, I think Tomoyo is in harmony with the Slackware philosophy, simple and good. I was actually even considering asking in the Slackware "request" thread to add Tomoyo as a standard MAC solution for Slackware, by adding a "slackware-generic-tomoyo" Kernel alongside the other options, to allow people to easily implement Tomoyo from the getgo. I dropped that as unrealistic, although I think Slackware and Tomoyo is a perfect match. And I don't mean by default, but as an option. "slackware-generic-tomoyo" kernel would just be the same slackware-generic kernel with tomoyo activated, and would be very easy to add as an option.

Anyways, I will implement Tomoyo on my Slackware on my own, it's not difficult.

But I think it would be nice if Slackware added Tomoyo as the default Slackware MAC, by that I mean, not activate by default, but making it the default MAC solution for Slackware.

1 members found this post helpful.

Meh. Personally, I've never had the need for such things, but perhaps my use case is too narrow to include the problem that they try to solve... Which, I'll openly admit is beyond my understanding at this point.

You've done a good job of selling it, so I'll try it in a VM and find out exactly how it works and if I would have a use for it.

Yeah, I guess it depends from person to person, but I've been interested in MAC for quite awhile before I started using it. I just found Tomoyo to be such a good MAC tool for it's simplicity and ease of use, which started making me enthusiastic

It was shockingly easy to use, which made me wonder why more people don't use it, since an argument against Linux MAC is often "it's too difficult/complicated".

It's a little bit difficult to come up with practical real life examples, since it depends on the user system and preferences etc. But say I have an IRC (internet relay chat) client installed (or even Mozilla Firefox), then why should this client be allowed to read files in my /home/user folder? Let's say that could potentially be a security/privacy issue. But how do you prevent such undesirable behaviours? I don't know how you do it with normal GNU/Linux tools, but with MAC you just don't allow it. In fact, with MAC you can allow your IRC client very little access to the rest of the system. You can allow it only to do what it needs to do to start and run and do what it is suppose to do, and deny it everything else. This would mean it cannot read /home/user folder and files or execute another program for example.

For alot of programs this is the case. How can I prevent them from doing anything? Unless I read the code and knows what they can do and can't, then is there anything else I can do? And I can't read all the code of everything on my system. I know others do that and mostly programs don't do what they are not suppose to do. But I don't know what those people think the red line is for what a program should and should not do, when they review the code. So I just have to trust their judgement. The USER solution to this problem is MAC. With MAC you don't have to read the code and know the details of the program, you can just decide what it is allowed to do and not allowed to do(by effect of not allowing it).

I add it every time I compile my Kernel. I like it but only been utilizing it about 6 months on/off. It can be time consuming when configuring software but once it's all setup its a breeze. Using Slackware BTW.... Glad you are showing interest and like to work with you if you decide to pursue it.

One of the interesting things now is that Slackware (15) is finally on Python 3 as main, which means it should be fairly simple to get SELinux working. Since Tomoyo 2.6, it can be used together with SELinux, which sounds somewhat interesting too.

Although Tomoyo is and will be my goto solution, I think it might be interesting to experiment with SELinux on Slackware 15 as well, perhaps see if it is possible to build a policy, and how Tomoyo/SELinux works together.

It would be nice if someone forked this and updated it.

https://github.com/log69/tomld

I am currently looking to implement an LSM with Slackware 15.0. Your posts and howto have been helpful indeed.

In order to clarify the above quoted, and what I am planning to try is SELinux or SMACK LSM + Akari.

AKARI is a loadable module forked from the feature-wise larger to the TOMOYO Linux 1.x branch. This version is implemented as a loadable kernel module (LKM) using the LSM interface that can be applied to the Linux 2.6.0 and later kernels. - see here.

Major LSMs are not stackable as on date, can choose one only, per the kernel.org documentation.

I will post my progress in a few weeks time.

Thanks!

from huge.s config


# CONFIG_SECURITY_SELINUX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_LOADPIN is not set
# CONFIG_SECURITY_YAMA is not set
# CONFIG_SECURITY_SAFESETID is not set
# CONFIG_SECURITY_LOCKDOWN_LSM is not set
# CONFIG_SECURITY_LANDLOCK is not set
# CONFIG_INTEGRITY is not set
# CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity"


Can someone advise me whether ordering is important here? CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity"

And, if we are to add, say Tomoyo or SMACK from the kernel re-compile, will this be generated automatically?

Thanks!

I decided to go with Tomoyo 2.6.x LSM, and later play with what I said above.

Thanks!

First I've even heard of it, to be honest.

LSM? Logical Storage Manager?

Ah... there it is. Just a quirk of mine: expecting writers to define acronyms on their first use before they sprinkle them through a document.

I'm not worried so much about "perceived" security issues.

Maybe, with some work, this could be a blog post on LQ?

Advice noted . 'Your quirk' is a solid posting guidance for sure. I will work on it some more and then blog about it.

Thanks!

Why I am interested in a kernel space Mandatory Access Control (MAC) Linux Security Module like Tomoyo:-

1. Enforce security policies.
2. Follow least privilege rule for as many system processes as possible.
3. It is a requirement in data security certification with external audits.
4. In my case, we want to get formally compliant with PCI DSS (Payment Card Industry Data Security Standard) and as a part of that, we adopted other standards internally, such as CIS' benchmarks (Center for Internet Security). CIS provided a security benchmark for Slackware 10.4, which is now archived. The current document we follow is CIS_Distribution_Independent_Linux_Benchmark_v1.1.0-2019, which mandates an approved mainline LSM enforcement.
5. I want to use Slackware 15 in Linode.

Thanks!

Fairly sure it is just an include or not include. Like, include, yes/no? Yes being in that list. And no, it doesn't generate automatically, you will have to include it. Probably for the exact purpose of allowing you to compile the option, but not include it as a feature.

Say, for experimental use, those things can likely be adjusted in /sys and with bootloader flags.

But take it with a grain of salt, I haven't really tested those features myself.