Re: Making SELinux standard for etch
On Thu, 12 Oct 2006 14:12:54 +0100, Ian Jackson <ian@davenant.greenend.org.uk> said:
> Mr Yan writes ("Re: Making SELinux standard for etch"):
>> Ian Jackson wrote:
>> > if (selinux_enabled > 0)
>> > if(setfscreatecon(NULL) < 0)
>> > perror("Error restoring default security context:");
>> >
>> > Error checking ? We don't need no steenking error checking, this
>> > is SECURITY software ! Quick, dump your brains and deploy it !
>>
>> Without checking these functions for what they return its hard to
>> say how bad this is, but it does look like its checking the return
>> values for an error (albeit not doing anything other than printing
>> a message). Without more context its impossible to say whether not
>> resetting the default security context is bad or not.
> Having the program carry on after it has failed to restore the
> default security context is definitely bad.
And you base this statement on? Why are you disallowing the
use cases where policy is allowed to temporarily go to seed and the
ones where the system is not in enforcing mode? It is not dpkg's job
to tell me in what mode I must run my machine.
The default policy being deny by default means we allow the
install to go on, despite the installed program not working in an
enforcing context. This allows the software to be installed; and at a
later stage the security
> Manoj Srivastava writes ("Re: Making SELinux standard for etch"):
>> Assuming for an instant Ian may know what he is talking about,
>> could an example be given about what the so called missing error
>> checks are, by him or anyone else who knows what he is referring
>> to? How would people code this differently?
> if (selinux_enabled > 0)
> if(setfscreatecon(NULL) < 0)
> ohshite(_("Error restoring default security context"));
> (I haven't read the manpage for setfscreatecon to check whether the
> `< 0' is right; I'll charitably assume it.)
> But the answer here isn't to go through all of the selinux patches
> to all of our programs and try to fix the bugs in them. If the code
> is buggy the concepts are likely to be buggy too.
Strawman. You haven't yet uncovered a bug; you are going off
based on self admitted incomplete information of what is going on
based on faulty assumptions.
> Indeed, if you're willing to take my word as a computer security
> expert[1] for it, I can say with confidence that selinux is not the
> right approach to fixing the security problems with our systems. It
> probably does more harm than good.
That, based on me being a security expert and all, as well,
and being around other security experts and all, sounds more
like ignorance, really. So, no, I guess I am not going to just take
your word for it.
> ([1] I have a PhD in computer security from Cambridge University, 8
> years' practical experience in the computer security industry, and a
> similar period of experience as an author of Free security
> software.)
I am sorry to hear that. This means that credentials like you
are presenting don't mean squat when it comes to asserting knowledge
about cutting edge security implementations. This seems mostly hand
waving and intimidating people by the letters after your name;
unfortunately, it also shows that you have nothing concrete to back
up your assertions. Show me a information flow analysis where you can
demonstrate information leakage or a MLS constraint violation, and
I'll listen to you. So far, every flow analysis I have run about
installing some of the packages without the proper initial file
That it has failed to show leaks; all that happens is that the
program does not run in enforcing mode.
Frankly, if you are coming out saying that mandatory access
controls, type enforcement, and multi-level security are useless, I
have trouble taking you seriously.
>> So far, I think the criticism reflect more of a lack of
>> understanding of SELinux trhan anything else, but I would be happy
>> if someone could show me the error of my ways.
> The selinux patch to dpkg contains several calls to setfscreatecon,
> and in each case, if setfscreatecon fails, the code uses perror to
> print a message to stderr and then carries on anyway.
Right. That is the design. as I have explained.
>> Since the default permissions are to deny all access, all it means
>> is that any special permissions accorded by policy to the package
>> being installed would not be set by dpkg. So the package may not
>> work in enforcing mode until the file system is relabelled; but
>> that is failing safe;
> Not at all! The package will be broken and the system unuseable.
In enforcing mode. The situations where setfscreatecon fails
if that the system is not running in enforcing mode, and/or the file
system is not relabeled correctly. It is my opinion that since
security s not compromised by the install going forward, we go ahead
(allowing users to run their machine in permissive mode), and then
to relabel at their leisure.
This is also important while policies gaps are being filled
in, and people may not have the proper policy modules installed when
running apt-get. Allowing the isntall to go ahead, but spitting out
AVC errors, allows people to update policy or run in permissive mode
without being anal retentive about it.
> Furthermore, the error abort is missing after _both_ the calls to
> set file-specific contexts, and the calls to restore the default.
> If these calls fail, files in general might be created by dpkg or
> even by its callees (postinst scripts, etc.) with inappropriate
> security labels.
No. the files are created with no specific security contexts,
which means no special privileges are accorded. This is the dafault
action from the kernel, You are speculating incorrectly.
>> if there are things wrong in the system that dpkg can't set the
>> initial file contexts for the packages being installed, it is
>> reasonable to assume that you might have to relable your file
>> system to recover from the error condition.
> No, it is reasonable to assume that dpkg would fail during the
> installation/upgrade so that you can correct the problem.
Your opinion, with which I disagree. I think it is better to
install, correct policy issues, and _then_ relabel. This is more
user friendly, and far kinder to people just dabbling with
SELinux. It is not as if there is a security hole (unlike the people
criticizing it, I have done information flow analysis on the security
policies and have tested a few packages [apache,bind,coreutils,make]
to see that is the case).
> dpkg (unlike rpm!) doesn't carry on blithely when your disk is full
> or when your filesystem is readonly; nor should it carry on blithely
> if it can't set the security context in the way intended.
Doing so allows people to run the system in permissive mode
without a properly labelled file system -- and I see no reason to
prevent that.
> Unless, of course, this whose security context palaver isn't really
> important. In which case why are we contorting our code and
> introducing dodgy and unstable libraries right at the bottom of our
> software stack ?
Because not all systems run permissively. At this point in
the game, I think it is better to allow the install to go
ahead, and then do the relabelling _once_, Relabelling can be an
expensive operation. It is often acceptable behaviour on development
systems, for example, to allow the policy to go rusty for a while,
and just install packages without specialized policy, slipping into
enforcing mode once the policy has been updated. dpkg should not make
that use case impossible.
manoj
--
Envy is a pain of mind that successful men cause their
neighbors. Onasander
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: