1 |
On 2020.06.26 16:03, james wrote: |
2 |
> On 6/26/20 12:38 PM, Daniel Frey wrote: |
3 |
>> On 6/20/20 7:04 PM, William Kenworthy wrote: |
4 |
>>> Thanks for filing the bug. |
5 |
>> |
6 |
>> Gah! I forgot about this! |
7 |
>> |
8 |
>> I filed a bug now, I hope I made it clear enough. Others can pipe in |
9 |
>> there with comments if they like. |
10 |
>> |
11 |
>> I did indicate the two potential proposals to correct the issue in |
12 |
>> the bug itself. |
13 |
>> |
14 |
>> https://bugs.gentoo.org/729752 |
15 |
>> |
16 |
>> Dan |
17 |
> |
18 |
> BEFORE I contribute to this bug, I'm posting here to see if others |
19 |
> are or have interest, in my thoughts on this issue and my related |
20 |
> needs for extreme security, via Gentoo. Below is far from complete, |
21 |
> but it only provides a very snippets of my (secure) pathway forward |
22 |
> with Gentoo. |
23 |
> |
24 |
> Interesting thread, thanks to all contributors. I'd like to add 'my |
25 |
> selfish' interest, as they also be espoused by other, more focused, |
26 |
> gentoo users. |
27 |
> |
28 |
> INTRO: |
29 |
> |
30 |
> I rarely build gentoo systems, for many reasons, that are not pretty |
31 |
> singularly focused. It drastically reduces security, performance and |
32 |
> upgrade issues. For me, the days of a any system, having groups or |
33 |
> users, are in the history books of very bad ideas. uP are so cheap |
34 |
> and less than $100, gets you a very 'bad ass' computer (Rasp. Pi 4+) |
35 |
> 16 G map-able ram. Furthermore, SOON, usb_4 devices are going to |
36 |
> obsolete the entire concept of a 'hard drive'; hence the death (my |
37 |
> prediction) of groups and users on multi-USER systems, albeit slowly. |
38 |
> |
39 |
> Multi-function, Multi-tasking, and light weight, focused transient |
40 |
> clusters are the future. YMMV. |
41 |
> |
42 |
> |
43 |
> So solving a problem, that was real and big, decades ago, fails to |
44 |
> look at the future. For me, Gentoo is future proof. I suggest a well |
45 |
> documented pathway forward; totally without the concept of groups and |
46 |
> users, on a typical, highly secure system. Which is now the baseline |
47 |
> for real systems, particularly with a ipv4 or ipv6 static ip, that |
48 |
> provide focused and highly restricted functionalities. CA servers are |
49 |
> going private, as the public and root CA servers, are suspect, at |
50 |
> best, as to being pristinely secure. Yes boys and girls most |
51 |
> Certificate Authorities are HACK! Even the main root CAs. |
52 |
> |
53 |
> The F. Feds are the original culprits, but now it is a feeding |
54 |
> frenzy. The planet is now hacked, and groups and users concepts are |
55 |
> the past. imho! Danger Will Robinson Danger! |
56 |
> |
57 |
> So can some of the smarter (gentoo) folks illuminate how to totally |
58 |
> avoid groups and users, except for the minimum required, application |
59 |
> specific? For example like serial line tools, or outline a set of |
60 |
> tweaks/setting to avoid these altogether? |
61 |
> |
62 |
> I build embedded G. systems. I build single purpose G systems. I |
63 |
> build security G. systems (often with the ethernet, in only listen |
64 |
> mode. I build G. Firewalls. |
65 |
> I build G. highly restricted/filtered servers. NONE of those need |
66 |
> users or groups. And if they do, I can obfuscate codes to provide |
67 |
> that need, to where filters and focused software gets what it needs |
68 |
> to provide functions. |
69 |
> |
70 |
> Yep, I'm moving to a total 'State_Machine_design' for critical |
71 |
> services. Strip out every thing else..... |
72 |
> |
73 |
> Am I alone, or have/are others contemplating such high secure |
74 |
> pathways? I'd be fantastic to find a kernel hacker that is on the |
75 |
> pathway of extreme minimization too; private email is fine; if that |
76 |
> is in your wheel_house. |
77 |
> |
78 |
> |
79 |
> curiously alone?, |
80 |
> James |
81 |
While you may not be alone, I do believe you're in a rather small |
82 |
group. There are probably more who are interested in watching it |
83 |
progress than who can actually participate and contribute. And while |
84 |
what you propose may well be part of the future, and it may even be a |
85 |
large part of it, it won't be so anywhere near soon enough to avoid the |
86 |
need to continue to improve current systems, even if the improvements |
87 |
are only usability related, and not directly related to security. This |
88 |
current issue is nothing more than an annoyance, but it's a major |
89 |
annoyance for many Gentoo users, possibly more-so for the more casual |
90 |
users. (Is "casual Gentoo user" an oxymoron?) As the bug proposes, |
91 |
there are ways of solving it without decreasing security. |
92 |
|
93 |
Jack |