[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

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: