On Tue, Sep 17, 2013 at 6:10 PM, Kurt Seifried <kurt@xxxxxxxxxxxx> wrote:
> On Tue, Sep 17, 2013 at 8:01 AM, Miloslav Trmač <mitr@xxxxxxxx> wrote:
>>
>> On Fri, Sep 6, 2013 at 3:04 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx>
>> wrote:
>> 2) A typical "application separation container" should, IMHO, not even
>> have a password database used for management, let alone a login shell.
>> (Just launch a shell process and attach it into the container.) So,
>> in that case, the database should be removed, not made smaller. Right
>> now that would mean removing all of PAM, which is somewhat problematic
>> (if the application uses PAM to authenticate access to the
>> application.).
>
> Well there's the world we should have, and the world we actually have.
Well, sure.
>> 3) For both virtualization and virt-like containers that accept
>> authentication by "keys or kerberos", wouldn't it make most sense to
>> disable password authentication altogether, then?
>
> See above answer.
>
>> If 1) is false, 2) and 3) suggest to me that this might be best solved
>> by packaging the "password creation/change functionality" as an
>> optional component (encompassing libpwquality+cracklib*+perhaps some
>> parts of PAM), installed by default in @core, that the ultra-small
>> setups could just remove (and if they were missing, creating/changing
>> passwords would have to fail).
>
> How does one log into the image to make changes?
See 2) above - create a process, attach it into the container, then
exec a shell. This requires privileges on the server, but not within
the container.
> not everyone will be able
> to easily manage/modify the JEOS images using tools, so again you just
> excluded a large chunk of people from using them. I think logging into an
> image via SSH is a pretty common feature/requirement and we should continue
> to support it.
Yes, definitely - for the distribution default. The JEOS case is
already deviating from defaults, by definition.
> I'm not sure having the dictionaries at all really helps, and the people
> using JEOS are (hopfully) a bit more clued in than the average user who pops
> a Linux CD into the laptop to install and see what it's all about =).
Right, but we are not _yet_ in the multi-product world where we can
easily tailor the cloud image for a different user audience to this
extent.
Mirek
--
security mailing list
security@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/security
