--- Kyle Moffett <[email protected]> wrote:
> <really big snip>
>
> If you have no interest in categorizing the SELinux access vectors,
> then how do you expect to categorize the LSM hooks, which are almost
> 1-to-1 mapped with the SELinux access vectors?
Those that refer to object accesses and those that do not. The former
are generally interesting, the latter are generally not. That's a
rule of thumb, mind you. Anyway, have a look at the hook table, it's
in smack_lsm.c
> > The point you make, that you need to have that in order to create a
> > policy description, is one of the reasons for Smack. Simplified.
>
> Well yes, but a simplified policy is useless if it uses no LSM
> hooks.
As above, that's smack_lsm.c, a little over 2000 lines of good old
fashioned C code.
> I will write you a Perl script which will generate a complete
> and functionally equivalent SELinux policy (assuming I have enough
> free time) given a file with your policy language. But I can do this
> if and only if you tell me which of the SELinux access vectors you
> care about (In other words, which of the LSM hooks you want to
> require "read", "write", or "execute" privileges for). With such a
> little script you could write all the "simplified" policy you want,
> without having to change the kernel code at all.
It's all spelled out in the module. Go wild.
> <another major snip>
>
> My point is your policy format is SO simple it doesn't even need the
> SELinux MLS code to handle it. From the way you've described it the
> base policy (~200 lines) would be *identical* regardless of the
> entries in your policy language, and the rest could be generated by a
> script directly from the "C Unclass rx"-type stuff.
Ok.
> >> Whoops, I think I must have smashed the delete key or something
> >> while sending. Here's the paragraphs which got elided:
> >>
> >> Well, yes, but a policy which completely ignores future
> >> expandability can't be expanded upon regardless. It would also be
> >> very hard to add new policy without a lot of duplication under
> >> your system. On the other hand, with SELinux you can very easily
> >> add attribute-based policy so adding new capabilities is as simple
> >> as sticking existing attributes on newly defined types. For example:
> >>
> >> type my_log_t, file_type, log_file;
> >> type my_log_daemon, daemon;
> >>
> >> Right there I just gave permission for the logrotate to recycle
> >> files labelled my_log_t, which the sysadmin and audit admin can
> >> also read (and the audit admin can delete). I also gave
> >> permission for my daemon to send SIGCHLD to init, and for init/
> >> initscripts to send it a SIGTERM/SIGQUIT. All without writing a
> >> SINGLE policy rule. Basically all of those existing behaviors are
> >> found in allow rules built on the "file_type", "log_file", and
> >> "daemon" attributes.
> >
> > Ah, now you're refering to the reference policy, right?
>
> Yes, precisely. For most of that functionality there are existing
> attributes and types defined in the reference policy to make custom
> policy much easier. Furthermore, there are interface files which
> allow me to say something like "Let this program spawn an Apache
> daemon in the right domain" with a single line. If I only want to do
> that when the "httpd" module is loaded I can put the line in an
> "optional" block. A policy for a basic network daemon with a couple
> log files, a config file, and a little database is all of 30 lines,
> maybe 50 if you throw in comments.
After you have the 400,000 lines of reference policy behind it.
> >>> They can be added or changed one by one as required while the
> >>> system is running, and there are uses that exploit that. One
> >>> example is to put the label "Game" on certain programs and:
> >>>
> >>> at 8:00am "Worker Game no"
> >>> at 5:00pm "Worker Game x"
> >>>
> >>> Thus Worker processes can access Game files only during off hours.
> >>
> >> This is fundamentally broken:
> >> [...]
> >> Secondly, you can already do the same thing with DAC and a PAM
> >> groups-from-time-of-day module, I don't see why such a thing is
> >> special enough to need MAC. Thirdly, I could do exactly the same
> >> thing with an SELinux boolean and a cronjob (once we get proper
> >> revoke support):
> >
> > There is usually a way to address any particular problem using DAC,
> > it's often sufficiently painful that MAC looks like a better approach.
>
> No, generally the only reason to use MAC is when it's security-
> critical (system compromise, classified data, critical
> infrastructure, etc). Denying users access to games during the
> workday is hardly "security-critical". If that system's CPU time was
> exclusively needed for a life support machine during the day then
> maybe, but that's what renice or realtime scheduling are for and why
> the hell are you installing games on a heart monitor?
HeeHee. Don't think heart monitor, think in-car trip recorder.
The games can only be used when the car's at rest. It's a strange
world we live in today.
> <Another big snip>
> > Yes. This is the way it should be. A small set of very carefully
> > analysed programs that change labels under carefully controlled
> > circumstances is what I want. login, sshd, cron, special purpose
> > launchers. Written with the assumption that they will be attacked.
>
> Well, under SELinux, all 3 of those processes go through the special
> purpose PAM module to get their labels changed. Are you planning to
> modify *every* daemon to have special type-changing code? Hell, most
> don't even have setuid/chroot support and that's all of 15 lines of
> code and is supported in every UNIX/Linux distro released in the last
> 10 years (or more). Besides, why allow the program (say, "ping") to
> change its own label when the policy could forcibly change it for
> you. The label change is NOT just to *give* permissions, it's also
> to take them away. For example, when I run "ping", the process gains
> raw network access but loses access to almost every user file and
> disables LD_PRELOAD, etc, making it a thousand times harder to
> compromise it from the inside too.
I don't think we're debating the same issues any more. I can see
that you are well versed in the nuances of SELinux behavior. I
understand what SELinux does, and the arguements in it's favor.
I don't see that the complexity it requires is necessary in many
cases.
> >> Unless you relabel the files and relaunch the daemon the system
> >> will have no idea how the system will change. And if you let
> >> arbitrary root processes relabel things on the fly then you've
> >> lost all the security advantages to a MAC system.
> >
> > MAC systems have been behaving this way for decades. SELinux is the
> > exception, not the rule on this.
>
> "People have been burning witches for decades, that must be the right
> thing to do"
>
> The fact that something is commonly done does not make it right,
> especially when there is a significantly more secure alternative
> available.
That sword cuts both ways, you know. And if a complex system
is intractable for an environment it cannot make you feel
more secure.
I think that below here it's all philosophical differences based
on significantly different experiance and goals. Can you run
SELinux successfully on an 2 megahertz ARM processor with 8 meg
of ram, and no labeled file systems? I don't know that Smack
will ever be as appropriate for an enterprise server as SELinux is
today, but time will tell.
Casey Schaufler
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
