1. You must have good systems understanding, and I assume you already know basic computer organization/architecture. Read Robert Love's Linux Kernel Development to begin with.
2. Start dabbling with small device drivers. Use Linux Driver Development, or other such books.
3. Pick a small subsystem within Linux (say, a specific driver, or filesystem, or PCI, etc) and start reading it's mailing list like a religion. Initially, it wont make sense but keep pushing - whatever you don't understand, read about it, find it's code, ask questions (usually on IRC, avoid mailing list for asking introductory questions).
There are many resources these days about kernel in general and not necessarily Linux kernel. You can read/use those. Best way, as with any other field, is to get involved - either by getting into a kernel dev team or taking up a small project.
Be aware that unlike other domains, in kernel development, significant time is spent in learning/understanding underlying system (hardware, system architecture, etc) and amount of code written in comparison to learning, is very less. Also, a decade ago, kernel team was considered as elite team in company. These days they are just sustenance team in most companies (exception may be Intel, AMD, 1 or 2 teams in Google/FB/Apple and few other companies). Also, I feel being kernel domain reduces your scope in corporate world (it's a separate topic). However, kernel devs are still quite paid well due to shortage of expertise in this domain.
For Security analyst, just like kernel dev, one needs to understand system very well. Having good grasp of system, underlying architecture in hardware or in memory, does help significantly but I dont think kernel development background is necessary.
I got in to kernel development by basically being the only person willing to do it when it was needed. But I'd already done a heap of kernel work as side projects, and was already working as an embedded developer.
I know some people get in to security by breaking systems, but I don't know enough to say any more.
For one you need minimal communication and interpersonal skills as a ker el dev,it's the opposite as a Security Analyst.
Security Analysts do different things based on the company. This can include SOC work,vulnerability management,incident response and threat hunting. It all depends on the size and scope of the security departments.
Let me give you two analysts at different companies for an example:
Bob spends 40% of his time responding to SIEM events which include IDS alerts,firewall alerts,AV and endpoint ATP solution detections as well as suspect windows or linux system events. He knows some malware and network traffic analysis to do his job but most importantly he understands the various paid and free tools needed to do his event analysis work. 30% of his time is spent on reviewing suspect phishing emails and reported security issues. The rest of his time is down time or he processes and documents indicators of compromise for known current threats. He does little to no coding. The security department is well resourced and matured so he does not need to manage vulns, do incident response or other pesky tasks.
Enter Analyst 2,Alice. Alice also handles some SIEM events but maybe 20% of her time. The company is either too small or has too much of an immature security department to have 24/7 monitoring,they either outsource SIEM monitoring to a MSP and only look at confirmed true positives or they just don't see enough SIEM events to care for 24/7 human eyes. Alice attends a lot of meetings with security vendors and internal teams. She works on various projects but also handles threat intelligence,vulnerability scans and incident response which all takes up 70% of her time. Phishing emails,threat intel and hunting are all done on left over time. Alice might do coding but only as a last resort.
These are just very vague examples but even if you work for a security vendor,the work in some shape or form involves these types of tasks. Now, A dedicated malware analyst for a security company can reverse engineer malware all he wants and do write ups. A security engineer might do sysadmin-ish work and integration coding. A pentester or red teamer might do presentations and occasionally pentest but these are not typically described as a "Security Analyst" roles,they are more or less infosec roles one gets after getting their feet wet elsewhere in infosec(Like with alice and bob).
To answer your question: there are generally two paths you can take. The traditional path, where your passion for infosec and a well rounded IT experience is valued above all else or the latest trend which is to recruit people with a formal infosec degree. Either way works at least for now. If you have any kind of a technology degree you're fine,else one never hurts.
A few years of working in IT ops is generally recommended before an infosec role.This isn't because you can't learn stuff in a lab but having context around events and knowing how IT is operated is very important for analyzing a security event or when responding to an incident.
I went on longer than I should have but I figured someone else might read this and find it helpful.
Helpful links:
Att&Ck framework: https://attack.mitre.org/wiki/Main_Page
NIST pubs (there are a few more out there if you care to duckduckgo): https://www.nist.gov/publications/computer-security-incident...
https://csrc.nist.gov/publications/detail/sp/800-40/version-...
Traffic analysis excercises:
http://malware-traffic-analysis.net/training-exercises.html
A good awesome list that does a good job of what I'd say a security anaylst needs to know;
https://github.com/0x4D31/awesome-threat-detection/blob/mast...
Others here can probably answer the kernel dev part better than myself. Although,the Linux kernel newbies(janitors) site and mailing list might be a good place to start asking. I liked the linux device drivers book as well(http://www.makelinux.net/ldd3/)
Last word - evaluate your life goals carefully and rationally. Happiness isn't everything. It's nice to pursue what makes you happy and passionate now but finances,responsibilities and other life factors should be considered. I am not saying this as a discouragement but as a practical advice. The person who loves tearing apart malware or writing a kernel patch on his free time might some day start thinking family time and time spent taking care of one's self is more desirable and this might conflict with career goals and make hiring managers think "Oh,he doesn't have a malware analysis lab at home and I don't see him posting malware write-ups done on free time. He/She doesn't have passion for the work." -- tangentially, maybe this is why you don't see as many women in infosec as other IT sectors? Might get me downvotes but like it or not, women who choose to have a family have a harder time "Breathing,eating and drinking security" (or as I say, maintain an unhealthy work-life balance that benefits employers)
Hope I helped.